How to design user-to-user sharing to protect privacy and prevent breaches

Genetic information is pretty sensitive.  It can reveal a lot about you, and it can be used to target you racially or ethnically.  It can reveal health information.  And you can’t change it if it gets into the hands of bad actors.  

That’s why 23AndMe’s recent breach was scary and shocking to many of the users.  However, to add insult to injury, 23AndMe’s lawyers are saying it was the fault of the users themselves.  Sadly, I’ve seen a few people professionals stand behind this, but I strongly disagree.

Let me break down for you what 23andme failed to do, and what you should do if you have a user-to-user data-sharing function or product. 

Let’s talk about what 23andMe has said and put it in simple terms. First, they’re claiming

“unauthorized actors manage to access certain user accounts in instances where users recycle their login credentials.”

This means that people re-used passwords on 23andMe that they also used on other sites.

Second, 23andMe says users,

“negligently recycled and failed to update their passwords following the past privacy security incidents, which are unrelated to 23andMe.”

This means that when someone’s re-used password was involved in a data breach, they failed to go update 23andMe’s password.  

But let’s look at the numbers.

About 14,000 23andMe users were included in this set of people who had bad passwords or were involved in credential stuffing. However, the data breach has resulted in 1.4 million users leaking their family tree and 5.5 million with other forms of stolen data. To be clear, 14,000 users with bad passwords resulted in five and a half million users (who might have had fine passwords) having their data breached.

How did this happen?  It is because of a user-to-user sharing feature that doesn’t seem to be properly designed.  

The feature is called “DNA Relatives,” which you can opt into in which you can share your information with close relatives so other close relatives can log in and get information about you. I was unable to find exactly what a close relative means. Is it just first cousins, second cousins, fourth cousins? I did find an example where 23andMe shows that one person has over 1200 relatives. So by opting into this feature, you’re letting the closest 1000+ people who you don’t know, get access to some genetic information about you.  Oh, also your name and location. 

side note: Some folks out there hear that and think they would never opt-in to share genetic information with so many strangers.  However, this feature is really useful for many people.  In particular, I’m personally very sympathetic to the adoptees who want to learn more and find their biological family.  It’s important here not to blame the users for opting into this feature, but instead focus on how 23andMe could have made it better.  

There are four design decisions that 23andme should have made. They are important for any product that has a user-to-user sharing feature. I’ve seen these patterns time and again and they can expose your users and create a privacy breach.

User-to-user sharing needs to be designed with privacy in mind. That means it’s up to any company that allows this to design that feature well.  Don’t use deceptive patterns.  Also, user-to-user sharing should allow users to revoke, limit, and monitor access to their own data.  These are classic elements of user-to-user sharing that all products should include.

  1. The opt-in should not use deceptive patterns.  A deceptive pattern is any kind of user interface or nudge that tries to convince users to opt into data sharing when maybe it wouldn’t be their first choice.
  2. Revoke: Can the person turn off the sharing? Can they block people or remove people who had access? 
  3. Limit: Can you limit any of the data that is shared, or do you have to share everything (name, location, etc?) 
  4. Monitor:  Can you get a sense of how many people are looking at the data that you’ve shared?

In addition to the user controls, user data needs security protections. 23andMe should have been responsible for detecting and monitoring abuse.  Let’s go through a couple of examples of how to do this.

  1.  IP anomaly detection. If one person is always logging in from a certain IP or group of IPs and then it’s completely different one day, that rings alarm bells. That’s why sometimes your credit card is declined when you’re traveling. 23andMe could have also done this and blocked people with weird-looking IP addresses from accessing the DNA relatives feature and grabbing datasets.  
  2. Rate limit user-to-user sharing. For these kinds of attacks, the attacker is probably going to write some a script to automatically go in and collect data quickly and repetitively.  The frequency of their request and the speed of their request are going to look a lot different than if it’s just a normal  user who’s logging in and clicking through by hand. At 23andMe 14,000 people were making five and a half million requests within probably a few months. That should have been an anomaly, and detected.

These are commonly known methods to help with security, and there are plenty more. I’m not convinced that 23andMe has a lot of excuses for not doing this.  

To summarize, if you are someone who is building a user-to-user sharing product or feature, then please make sure that you don’t have deceptive patterns for trying to nudge or convince people to opt into sharing, allow users to revoke, limit, or monitor access, apply rate limiting, and monitor for fraud and abuse.  Avoid another data breach, and learn from the sad lessons of 23andMe.


About the author 


Dr. Rebecca Balebako is a certified privacy professional (CIPP/E, CIPT, Fellow of Information Privacy) who helped multiple organizations improve their privacy through research, analysis, and engineering. 

Our Vision

 We work together with companies to build data protection solutions that are lasting and valuable, thereby protecting privacy as a human right.  

Privacy by Default


Quality Process