[ManBlanket]

This policy seems purposefully vague.

"Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data."

My first question before looking into it was, "What an auth tenant or some other service that stores user data?" or, "what about like a banking or healthcare app that is just a portal for another system?" And, "What does deleted even mean? IsDeleted=1?"

It would appear Apple's stance on those answers is a shrug emoji. I'm no appstore developer but I got a kick out of reading a lot this for the first time. This rule bearing no exception to a trend that for most part seems intended to give Apple the license to eliminate bad actors.

I got a new one for Apple. "Like, do what you gotta do but don't be a jerk."

[debaserab2]

When did "deleted" become a vague term?

Deleted means removing as much PII as you reasonably have authority to do so. It means purging all that data from all databases with a guarantee that you will be removed completely from all snapshots in a reasonable amount of time.

This should be the default, normal understanding of what it means to delete your account.

It doesn't mean set a flag in a database so when your company gets acquired in a few years your new owner has a nice little trove of data to mine of people that explicitly opted out.

[greysphere]

I mean... There are a zillion reasons this isn't trivial. Imagine I have an app that pays you, and it has to report taxes on it. It can't just delete your info. Imagine an app that sells alcohol, maybe it needs to make sure it has confirmation of your age/info in case of legal action. Imagine a chat application, if you chatted with someone and they deleted their account, would you lose the chat information (or even the name/record of who you chatted with?), no, that's 'your' information too, somehow.

[Nextgrid]

A solution I use for this is to keep 2 sets of data, one operational for the application and one for legal/financial requirements.

When an action such as a payment is taken, or the customer provides certain info that needs to be kept for legal purposes, two records are created. The former can be deleted at will by the user, the latter is completely separate and is kept for as long as needed to comply with laws/regulations.

[debaserab2]

Didn't say it was trivial. But that's what users expect: a reasonable right to data privacy.

[tediousdemise]

The right to be forgotten is just that - the right to be forgotten. Your issues or needs, whatever they may be (tax info retention, age info retention, etc), take a backseat to the user's rights.

In other words: if there is overlap, the right of one person's data to be forgotten supersedes the right of the other person's data to be remembered.

[greysphere]

You should try that logic out come tax day, see how that goes.

[tediousdemise]

I invite you to read another comment I made here with this exact example: https://news.ycombinator.com/item?id=28779463

[ManBlanket]

I know you wrote this 8 days ago and I dunno if you'll even see my response but deleted has always been a vague term. There are a ton of reasons not to hard-delete data before you arrive at data mining. I know a lot of concerns regarding GDPR and data mining would contend for the hard delete, but a couple people gave you good examples. I just wanted to share one I am looking at right now. Our users have the ability to perform an action over a large set of their own data. Sometimes they do things like deleting relations they didn't realize would have a larger impact. Luckily the code in question doesn't hard-delete the entities, because I just got a ticket today asking if a huge list of IDs could be restored.

I think looking at deletion as the solution to privacy concerns is the wrong way to go about it. Really, the problem is app developers think, "possession is 9/10ths of the law" when it comes to data, when in reality their relationship with the user never captured use of that data for purposes not related to the application. Just because you give your data to the bank when you make an account doesn't mean you consent to them selling it on the dark web. The same concept applies but it is much harder to police and you can even say you're going to misuse the data in the EULAs that nobody reads. In my opinion using user data for purposes unrelated to the application should straight up require explicit consent from every user, lest the seller and recipient be subjected to a fine.

[itake]

One thing that is confusing about the concept of "deleted" is how do you minimize fraud on a social platform without retaining PII (indefinitely?) of your users.

If there is a known fraudster and you have their selfie image, email address, and ML face vectors, the fraudster requests their account to be deleted. What should the company delete? Maybe the company can keep a one-way hashed email and face vectors, but what about hash-collisions or false positives?

If there is a user that wants their account deleted, but then they come back to the platform (maybe abusing a referral bonus or first-time-only coupon), how do you stop this fraud?

[floatingatoll]

It sounds like you’d like to work at Apple and help them improve their guidelines process. They don’t offer what-if examples, and they note that it’s by design that the guidelines are not detailed to the level you’re asking, so that they have the flexibility to make judgment calls and prevent rules-lawyering problems that crop up with the more detailed approach you seek.

1. Auth tenant. Common sense says that if the auth provider is operated by you, it’s your problem to handle deletions appropriately, either by removing their account or by warning the user that you’re only deleting the specific site account and providing a link to delete the SSO account at your website or whatever. If you do not operate the identity provider, such as Facebook, then you need do nothing about it at deletion time. Apple would likely approve any of those paths without comment, but to defend against rules lawyering and loophole seeking, there’s no way to be perfectly certain until it’s approved.

2. Banking or healthcare app. If you can sign up in-app, you’ll need to let people close/delete in-app, except where prohibited by contract or law. For corporate healthcare, you would pop a dialog that says “This account can only be closed through your employer”, which would be absolutely sufficient. Ditto for a banking account with non-zero balances or a safety deposit box or whatever. It seems likely Apple will not have cause to enforce the deletion clause against brick and mortar banks, since they all have help/faqs on how to close accounts already. App-only banks will be held to the more strict standard of having some way to initiate deletion, being app-only, though of course they’ll retain financial audit records as required by law.

3. Deleted means that all information not essential to compliance with financial and other auditing laws has been removed from your systems. Exceptions are understood to exist for recording that someone requested deletion, but you can’t use those records for marketing or training AI or any other purpose beyond managing your deletions. If you can’t explain in plain simple English how you handle deletions, they’re likely to reject your submission until you can.

All of this is obvious. It isn’t comfortable to consider that you’re at the mercy of human beings to evaluate your compliance — human beings that see a thousand scams a minute trying to hack loopholes in the guidelines. But that’s how it is today.

[oauea]

The sad truth is you're at the whims of some random app store reviewer and it depends completely on their mood of the day. It's honestly insane and impossible to work with. One day everything is fine, the next they have a list of issues that you are forced to spend dozens of developer hours on, just so apple will grace you with the permission to push an unrelated localization fix.

[floatingatoll]

Correct, you are at the whims of Apple when you attempt to publish to their app store.

[oauea]

Some random app store reviewer fella. Not sure if you've ever been on the phone with them, but it does not inspire confidence at all.