Live data from Hacker News

Some discouraging anecdotes on how services handle account deletions

ctrl.blog

121–130 of 133 posts

Re: Some discouraging anecdotes on how services handle account deletions

#121
post #99

Earlier quoted context omitted.

> de-biasing ML models As exemplified by, for example, Google firing the two heads of their Ethical Artificial Intelligence Team...who had been researching bias? [1] [1] https://www.theverge.com/2021/4/13/22370158/google-ai-ethics...

Are these two the only people who study bias in the world?

Yes.

Re: Some discouraging anecdotes on how services handle account deletions

#122

> 2 services moved my account to a different email address instead of deleting it. I was only able to detect this because they changed the mailbox part (the bit in front of the @ sign) but left the domain unchanged. I capture all incoming emails to my domain, so I saw email-change confirmation emails and other emails arriving at the new unexpected addresses. That's sketchy, especially if you don't own the domain but…

I had this happen with Adobe

Re: Some discouraging anecdotes on how services handle account deletions

#123
post #6

I've worked for several companies and let me tell you the truth: * accounts are never deleted, period * At most there's a column in the table which specifies whether the account is alive or not. That's it.

Admittedly we're a two-person startup so not exactly the same as a big corporate, but at Supernotes[1] we actually delete you from the database when you delete your account.

[1] https://supernotes.app

Re: Some discouraging anecdotes on how services handle account deletions

#124
post #6

I've worked for several companies and let me tell you the truth: * accounts are never deleted, period * At most there's a column in the table which specifies whether the account is alive or not. That's it.

Ok, we all understand the idea of a tombstone (a "deleted" field in the record that is set on deletion). However, the article actually describes something much worse -- user deletes their account and subsequently the account is still active. Not "marked deleted but some data is still on the disk" but rather "completely active, works, can still log in". This is surprising to me. I would not expect to see that really ever. But the article claims that this occurred in some significant number of their tests. Not sure how to interpret that.

Re: Some discouraging anecdotes on how services handle account deletions

#125
post #6

I've worked for several companies and let me tell you the truth: * accounts are never deleted, period * At most there's a column in the table which specifies whether the account is alive or not. That's it.

At the company I work for we actually hard-delete all user/tenant data, when requested. The column you mention is used for soft-deletion, which is a transient state. Even when not explicitly requested by the customer, we still hard-delete soft-deleted data that has been stale for at least X months (6?). So yeah, some companies really delete customer data, by request or by policy.

Re: Some discouraging anecdotes on how services handle account deletions

#126

Earlier quoted context omitted.

How do you mean?

Let’s imagine you’re a modern bank and associate card transactions with the merchant. Even if you sanitize/delete the account holder record, you can’t delete the transactions themselves (as it would screw up your accounting) nor the merchant association. Now let’s say you have a very particular customer that always goes to a very specific restaurant at pretty much the same time every day consistently. That pattern al…

Ah yep, thought that was the case, thanks for clarifying :)

Re: Some discouraging anecdotes on how services handle account deletions

#127
post #99

Earlier quoted context omitted.

Are these two the only people who study bias in the world?

Yes.

You must be mistaken. There is an entire department focused just on that at my local university, at least over 100 people. Plenty of candidates to replace those 2.

Re: Some discouraging anecdotes on how services handle account deletions

#128

Earlier quoted context omitted.

I wonder if they also go through all of their backups and purge the PII. I would be willing to bet, they don't.

You only need to state to what extend and period the information is stored in backups, and have a process in place to purge it again in case of a restore.

I never realized that was the rule. I thought you had to go in and wipe the backups regularly.

Re: Some discouraging anecdotes on how services handle account deletions

#129

Earlier quoted context omitted.

One reason deletion may not be technically absolute is that tombstone records may be needed to gradually cull the data from things like backups and 3P systems. Usually though these should just be surrogate keys with no human significance. Then ultimately they get purged too.

The danger with surrogate keys and pseudonymization/tokenization is that the mere patterns in the data such as foreign key relationships may be enough to uniquely identify someone.

If the tombstones are barren enough there may not any/enough relations or metadata for that. And ideally even the tombstones get removed once related records and 3P copies have been wiped.

Re: Some discouraging anecdotes on how services handle account deletions

#130

The app I'm writing does this very well. That's because Apple requires it. They won't approve my app, unless there's a "full-fat delete" option. If a user of the app deletes, it completely nukes their entire account, down to the last byte.

> If a user of the app deletes, it completely nukes their entire account, down to the last byte.

Edit: This comment is in response to the suggestion that all apple apps delete all local data which after rereading the parent they were only suggesting for their app.

Are you sure about that?

I'm not an iOS developer but as a user I noticed a few years ago that deleting google apps, even all google apps, off my phone and from icloud still resulted in a freshly installed google app suggesting I log in using the account I was last using.

My best guess after doing some searching is re-identification was done using a "Keychain Access Group"[1] which does not automatically get deleted on app uninstall. Though it is stated [2][3] that this is an implementation detail and not a guaranteed behavior. If I recall correctly the only way to reset the Keychain Access Group if the app doesn't do it is to wipe the phone.

It is also possible to persist data if an app is part of an "Application Group" and one of the apps in that group is still installed on your device then data shared via that approach will not be automatically deleted unless all apps in that group are uninstalled (from what I have read).

Apple does have the "DeviceCheck"[4] framework which significantly limits the amount of bits which can persist across app reinstalls which prevents / severely limits an app's ability to reidentify users but still enable some useful use cases. However until "Keychain Access Group" persistence is removed there is not a lot motivating a developer to use this framework.

1: https://developer.apple.com/documentation/security/keychain_...

2: https://developer.apple.com/forums/thread/36442?page=2 and for some prior history see https://developer.apple.com/forums/thread/72271?page=2

3: https://stackoverflow.com/questions/60485419/ios-keychain-da...

4: https://developer.apple.com/documentation/devicecheck

Post reply on HN