Hacker News Reader

Comment by npongratz | Hacker News Reader

Do you trust that your data, that they fully control on their system, is actually deleted? Including their backups that reside elsewhere? I just assume they set your record's "delete" field to "true" when you press that button. No way for us plebs to be certain about what they do.

View on HN

Yeah, right. ANYTHING you put in the cloud or any other digital media no longer belongs to you. I suspect 23 sold this valuable data, that any insurance company would kill for, to the highest bidder. When will we learn we cannot trust any company with our info?!?

Making claims like this requires evidence. You can claim that they might mishandle your data due to incompetence, but claiming that they are illicitly selling it is a whole other thing.

They say they provide your data to (to various levels, not necessarily genetic data):

- Service providers (Fedex knows you receive a shipment from 23&me, physical storage of your sample, someone hosts their servers)

- Sharing to people/entities at the users direction

- Any future commonly owned entities (23&me goes through a merger, new org has your data)

- Valid court orders ("23andMe will not provide information to law enforcement unless required by law to comply with a valid court order, subpoena, or search warrant")

I'd be surprised to hear about anybody deleting records on backup systems (i.e., backups that exist for disaster recovery purposes). It would be pretty difficult to do that in a commercially viable way (but I'm open to hearing about some creative ideas).

There are methods of doing it, but it is complex.

Basically you either have hot backups you can delete from (this is bad for obvious reasons), or your backups expire in a given time (this is most common), or you have each record encrypted with an encryption key that is saved in other ways so you only have to destroy those to make the data irretrievable.

Of course, that system has to be backed up, etc, etc.

Isn't it required to be available by EU law?

Apparently GDPR doesn't cover this case specifically but several enforcement authorities have issued some guidance. The only reasonable approach that I've seen is to maintain a log of deletion requests and ensure that if a backup is used to restore operational data that the deletion request is applied against the restored system.

Ironically, I've responded to deletion requests made by email in which the person did not have any records in our systems, until receiving the deletion request containing their name and email address.

https://verasafe.com/blog/do-i-need-to-erase-personal-data-f...

If user data in backups is encrypted with a key kept in warm/hot storage, you can delete the key and effectively delete data in cold storage because it is unrecoverable. This obviously must be per-user keys and set up in advance so I doubt they have it available, but that's one potential method.

Where do the keys get backed up to? If nowhere: If the key system fails, do you just accept the loss of _all_ of your customer data? If somewhere: by what mechanism do you delete the key in a backup?

The keys dataset is going to be much smaller than everything else, and possibly immutable per customer. This in principle makes it much simpler and cheaper to handle, so it's easy to imagine how---depending on the scales and technologies involved---one could isolate it and achieve the desired redundancies and retention periods in ways that would be impractical with the full customer dataset.

That’s a long way to say “it’s definitely possible but I haven’t architected a sane solution yet.”

I find this comment rather baffling. Can you really not see what I'm talking about without having a concrete (and likely completely irrelevant to 23andMe's requirements) example spelled out for you in detail?

You didn’t even give vague details, let alone you giving a concrete example in detail. I asked a question and your previous comment answer boils down to basically, “it’s totally possible.”

My theory is that you’re making a concession somewhere in the backups to a separate keyring system. Either there is no cold backup, or you don’t do cold backups at all, or your cold backup is actually semi-warm and needs to be hooked up to a system intermittently to be reconciled against production (in which case, the backups need backups to protect against a failure on the reconciler system.) The onus is on the answerer to tell me how they would avoid one of those concessions. Respectfully, anything else/less is just fluff like, “it’s totally possible.”

The whole point of isolating the keys dataset is that you can reason about it differently. You frame these "concessions" as dealbreakers, but I don't think that's supported. Can you explain why this dataset would need cold snapshots retained past a period users would accept as a delay for guaranteed account deletion---say, two weeks? Replication already has you covered on acts of god, so we're worried about things like bad code pushes, "hackers", and so on.

> so we're worried about things like bad code pushes, "hackers", and so on.

I'm confused. Are you saying those are small concerns? Because I'm saying the backup mechanism for the keys surely need to be resilient to all of those.

No, they aren't small concerns, but you haven't shown that extended retention of cold snapshots (>2 weeks, to use my previously stated example) is necessary to satisfactorily mitigate them. What is the argument for needing a significantly longer retention period?

Not only is deleting user data hard, backups, snapshots, archives, when they build data fm your data, that isn't considered "your" data, that is their data. So even if they delete all of your data it's not really gone.

Reply on news.ycombinator.com