Deleting the account shouldn't be a problem if all the "account" info is stored on the device itself, so if your reviewers aren't completely incompetent I don't see why this would be a problem.
What you have is partial control of these funds, via instructions to your bank, electronic or otherwise, but since it is merely operated on your behalf, you can't unilaterally delete the account. What you can do, is terminate the relationship with your bank.
Yes, it's plainly true that the bank owns (or rents) the hardware, software, databases, etc. and that you're paying for a service through various fees.
But IP is much less clear, and the view that "it's my database so it's my data" is not actually universally legal when the data concerns humans.
The whole notion that someone could have a legal property interest in personal data collected by others is exceedingly modern. Even the most abstract scholarly work presaging the concept can only be traced back a few decades. Similarly, privacy as a concrete, distinct legal concept is only slightly older. (Notwithstanding the historical narrative gymnastics legal and social policy advocates often perform in their attempts to appeal to tradition.)
Suffice it to say, modern concepts regarding privacy and personal data aren't very useful in understanding banking practices and property regimes that can be traced centuries, if not millennia, in nearly identical forms.
This is a relatively straight forward request that maybe doesn't go as far as most people imagine here. Pressing "delete" doesn't instantly delete all user data and it's not expected to. In some cases there may be subsequent steps and some data may be kept for legal reasons*.
The point is very sensible, if I can request the creation of an account or subscription easily in the app, the reverse process should be just as straight forward. If an app can give a one button "create-subscribe-pay" experience then when it comes to deletion you shouldn't suddenly fill out paper forms, or send letters at specific times in the month. And that's if you can even find the info on how to do it in the first place.
Now you can trigger the deletion and know that they have to do something about it, at the very least get clear instructions on how to proceed.
*When it comes to banks, they are subject to laws and regulation that many other companies/services don't have to deal with. Which is why Apples makes this provision:
> We encourage you to review any laws that may require you to maintain certain types of data, and to make sure your app clearly explains what data your app collects, how it collects that data, all uses of that data, your data retention/deletion policies, and more as described in the guideline
Legislation like the GDPR is motivated in part to nullify such arguments.
If you allow such a construct, then "deleting your account" could mean, your immediate personal details (or perhaps even just your access credentials) are erased in some fashion, but nothing else.
This is how legislation like the GDPR gets motivated, of course. The Apple guidelines reference "usage data" elsewhere, and I imagine that's for similar reasons. The deletion clause itself, rather notably, doesn't.
Suppose you're an equipment rental service. But you can't delete the customer's account before they return the equipment (or pay for losing it).
Suppose you're a dog kennel. You can't delete the customer's account while you have their dog in your possession.
Suppose you're the parole division of the police department. Can the "customer" delete their "account"?
This is the problem with dictatorial fiat. The world is full of edge cases.
If the user is allowed according with their contract or law to delete their account they should be able to request that themselves from within the app. This is what I understand from what Apple is requiring the apps to do. It is very similar with GDPR "Right to erasure"/"right to be forgotten".
For your specific cases:
- if a user rented something then they should not be allowed legally to close their account until they return or pay the equipment. If that is in the contract then the delete my account button should be disabled until their contract is terminated/closed.
- if you're a dog kennel it is the same, the user should keep the account until the dog is returned.
- if you are a parole division of the police and the "customer" by law can have their records deleted they should be able to do so.
But now you're exposing the huge problem. It goes from "everybody has to be able to cancel their account in the app" to having to be a contract lawyer steeped in the specifics of every business arrangement and know the law in a hundred different countries to be able to determine if you're allowed to cancel within the app.
Then the app reviewers would either have to be lawyers with plenty of time to make an accurate determination, or they'll be getting it wrong left and right. And it'll obviously be the second one. So now what does the dog kennel owner do, or the OP above, when the app reviewer rejects their excuse?
I also think that the default should be that users should be able to delete their accounts and companies should provide evidence why they have that button disabled or removed.
So in case of review the rule maybe could be: if the user is creating an account in your app, then. the user should have the option to delete their account from the app, unless evidence is provided why the account cannot be deleted because of legal reasons.
In none of those cases are you creating the account within the app.
why not?
1: I can, nothing catastrophic happened. Other than the Meteor codebase.
Just thinking out loud, of course cascading deletes will fail, so I guess you could avoid using true foreign keys to the user table for things which are truly related, and then you'd know what the user did but presumably no PII... Seems insanely sketchy though. Way cleaner to soft delete if you ever need to recover history, which the fintech context amongs many obviously requires
Anyone competent is storing both their requests to those external APIs, as well as those responses, for the entirety of the recordkeeping requirement period.
They have specific regulation regarding record retention.
A lot of firms that deal with personal data may even have snapshots of every single change, sort of immutable - just not global. Again destroying the keys solves the issue of the immediate erasure. The latter is often times impossible due to tape back ups.
GDPR solved this years ago: right to be forgotten does not apply to legal requirements to keep records. Companies must keep those records only for the minimum time though.
And what has it got to do with GDPR. Apple are not the GDPR police in my country. But now you mention it, are the app reviewers going to be trained in GDPR and document retention exemptions, or are they just going to hand out bans?
Getting sick of the down voting from the Apple fanbois of hn.
No, that doesn't seem true.
… Okay, the digital-only ones, maybe. But virtually all other banks I've used make you go to a branch.
The account falls under all the regular retention and reporting requirements, although these companies mitigate some classes of issues with stricter limits, not paying any interest (even though that'd be miniscule), etc.
In fact Wells Fargo is famous for opening account for you without you even thinking about it.
Now it’s only internet banks that do this. They still require lots of KYC documents to open an account.
Digital-only, but a "real" bank in every sense of the word.
Try going to random bank websites and click on "open account".
“…must also allow users to INITIATE deletion of their account”
Capitals mine. So I can allow the initiation of deletion but never actually completely delete the account… and my app complies.
INITIATION is the important part, if they fail to delete the parts they're required to delete, F them: get them off the app store.
Sure, if you can open an account easily, then you should be able to delete an account easily. So if we make opening an account difficult, then it is fine that deleting one would also be difficult.
Sounds like an invitation to make opening an account at a bank or a bunch of other services much more difficult aka impossible from the app.
Even just transaction info on a public blockchain is odd to me. It's possible to remain anonymous, but all it takes is one slip-up and then anyone can perform blockchain analysis to trace all sorts of stuff back to me.
On some blockchains it's easy to map the account to the user, on others it's impossible. There are solutions which are completely secret with regards to transfers, so blockchain doesn't solve the taxes. (a specific blockchain may in theory)
That’s a significant slippage from the dystopian ideal of being able to calculate something that many think is none of your business.
Assuming that information is only visible to the owner of the key anyways, then disposing of the key effectively renders that encrypted data as garbage. Not being able to delete it only enables some unknown future attack that can decrypt any data without the key.
If the blockchain survives long enough, that info will become public in time.
Browsers have to frequently deprecate cryptosystems that have become insecure. That's not possible with data frozen inside the blockchain.
Also, we're at a point where quantom computers are just starting to become practically usable. So yes, I think the point of a "cryptographic breakthrough" that will crack some configurations is quite likely.
And if you're not encrypting data with AES (or one of a handful of other algorithms), then you should be worried _now_.
> If AES is broken in your lifetime, you're going to have _way_ bigger problems than somebody decrypting your blockchain ciphertext.
I'm not so sure about that. Not a lot of encrypted data is simply lying around at rest, available for everyone to run attacks against. Most encrypted data is either ephemeral (encrypted data connections) or secured by additional measures (e.g. to even get the raw bytes of an encrypted partition, you need access to the machine, appropriate permissions, etc) That gives the data owners various opportunities to react and mitigate the risks: Stop processes that send sensitive data, unmount sensitive partitions, detete data, etc.
You can't do a lot to protect data on the blockchain - it's literally out there for everyone to access.
My point was that data owners have options to limit damage - e.g. immediately stopping any data transmission and not producing any future ephemeral data.
And just to nitpick about blockchains, ledgers, etc.: they don’t need to be world-readable. You can protect them the same as you would a regular database.
Then you'll need some central entity to manage access to the chain. If you already have a central entity, you can just use a regular database instead of a blockchain and save yourself all the energy waste.
I think the key aspect is that it is a database that no single person or organisation can delete or alter - not even the developers or operators of the database themselves. The only operation possible is append.
But this property requires that the majority of nodes participating in the chain are not under your control. When the nodes are under your control, you could just order them to swap out the current chain with one you just made up. (Which is effectively how git's "history rewriting" features work) This doesn't provide any more integrity than an ordinary database.
On the other hand, if you want an append-only database and you already have a central gatekeeper that you trust (as required for access enforcement), you also can use an ordinary database and have the gatekeeper enforce the append-only property. No blockchain required.
Elliptic curve signatures of the blocks are _significantly_ more fragile to quantum attacks than AES.
So yeah, all you need is either a currently unknown mathematic weakness in the encryption scheme, or bug in implementation, or as you suggest some future quantum or other technical advance that defeats the encryption.
There are three pieces, in fact:
1) The device keys - they should never leave the device
2) YOUR private keys - which you should be accessing and managing from multiple devices, and you can have many of these
3) User accounts on networks. This is where you actually authenticated some sessions, and they shouldn’t contain most of your personal info, only info necessary to operate the service.
For example at our company, we have a way for websites to display your name and friends back to yourself, while having no idea what they are. You can manage multiple identities across many services, and choose which to share with friends, and which not, and everything is automated so the Web turns into a social network:
A new version of Scuttlebutt allows tombstoning too.
I think mutable should be the default. Make it all ephemeral with optional permanence.
If someone changes their system to avoid the data being deleted, presumably that would then have to accept the liability / responsibility for deletion. But that’s already moot anyway, because we’re not talking about a court of law, but a court of App Store publication, which it would already no-longer be a part of.
The reality is that most people don’t have hardcore enemies that go out of their way to do things like that. And if you do, you ideally would have them blocked anyway.
Regardless, not posting totally publicly is becoming the norm now anyway. Posting in some kind of context limits the danger of this level of malicious snooping.
AES is considered "resistant" in that quantum does an effective square-rooting of the brute forcing effort (or if you prefer, halving of the binary key length). So, do not use anything under AES 256.
Asymmetric algorithms fall apart though, which is why NIST has had a multi-year effort to select new standardized asymmetric algorithms.
If you're a nation state that needs to protect information for 30+ years, then it's worth considering. For everyone on HN, it's not.
It never ceases to make me chuckle that it says that it's not a form of ID on front, and yet everyone considers it a form of ID. Even state governments. It's usually listed under one of the documents they accept to prove ID.
You could probably get away with signing an “implode” message and appending it to the tree, instructing any conforming client to wipe the account upon receipt (or at least cease to retransmit). That would give users the option to request their data be removed.
That's kinda the whole point :).
The information is not deleted per se, but it is not usable anymore. Now, if you have access to new means that allow you to break the encryption, then yeah it could be a problem.
If that's the case, does it not run foul of GDPR?
The issue is with Apple being Apple as usual.
maybe for you, but there are use cases...
¹: All of them are silly, or could be done better with something else, but that's not relevant to the point I'm trying to make.
> but that's not relevant to the point I'm trying to make.
why do you talk about it if it isn't relevant?
Can you give an example? “spread out and be somewhat resistant to censorship from governments” is just a description of blockchain's strengths¹.
> why do you talk about it if it isn't relevant?
If I didn't mention it, I'd be lying by omission. In order for this discussion to make sense, I have to make the implicit assumption that blockchain is good for anything. I have never, in my life, encountered a situation where blockchain is better than alternatives. Heck, I'm half-convinced that Bitcoin would've been better off with a block-graph (like Git); it models the dependencies better, and means attempted double-spend attacks have a lower impact on the rest of the ledger. (51% attacks would be a little easier, but only for very recent transactions, assuming even distribution of wealth² and a free market economy³.)
¹: though it isn't particularly good at either of those things in practice
²: this is a bad assumption, but it would only affect wealth hoarders so I don't care
³: this is a really bad assumption, but it wouldn't take much improvement to the world to make it a sufficiently reasonable assumption
it is very easy to find an example of censorship, not sure why you need one but let's say: "World marks 32 years since Tiananmen massacre as China censors all mention of it"
There is also daily examples of censorship on this website.
There’s a lot of arguments that people will make about whether this is justified or not, but from a plain rules standpoint, that’s not a permissible data management strategy if you want to publish an iOS app through Apple’s store.
If you do not implement account creation, then you're unlikely to be held responsible for account deletion, as a user would reasonably understand that your app is not responsible for creation or deletion of accounts.
EDIT: Elsethread, someone asked "What if I create accounts on the blockchain?", and since it's possible you'll come around to that idea next — the app would have to interact directly with the blockchain, so you'd probably get rejected for a whole array of reasons, such as but not limited to that you're storing account data on the blockchain. And I wouldn't envy you trying to explain why you shouldn't be continuously fined for GDPR violation in the EU, either.
This is kind of a bizarre thought to me. You think anyone who provides software that - without involving any services hosted by that person - should be liable for what users do with this software? If this were to hold up in court (which I'm confident it wouldn't), then open-source software would be done.
Or is this a problem of terminology? In the scuttlebutt case, there is no actual "account" - just a key. Maybe one should simply replace the string "Create account" (if there is such a string) with "Generate key/identity".
I realize many people are heavily invested in the Apple ecosystem, especially since Apple encourages that with the proprietary integrations between their different devices, but there's a point when one should realize they have a choice. It's a walled garden not a prison.
As an app developer, this isn't a choice I get to make. I myself have used Android ever since modern smartphones became a widespread phenomenon.
The rest of us will continue to because we want Apple policing apps on our behalf.
That said, I would argue that there is no Ethereum "account" - it's just a crypto key. In that sense, use on Ethereum is similar to someone using an email address to sign up for mailing lists and to post on forums.
The counter-argument is that your wallet app likely provides the interfaces to do that functionality, which makes the Ethereum blockchains a proper system under consideration.
The post you're replying to says Apple believe it should. Unless you can persuade Apple to change their policy, it won't matter if you disagree.
(I’ll give you that Safari isn’t in the App Store but many other browsers are. It would viewed as anti-competitive for Apple to remove all competing browsers.)
This might be the weakest strawman argument I've ever seen. Well done.
The 'account' consists of the credentials required to add or modify data associated with a human.
In that case, the person deleting their private key would suffice for deleting an account.
There are plenty of things this doesn't cover, or even backfires. Just interested in what other perspectives people may have.
---
Scuttlebutt actually could allow for 'deletion' in the sense that a 'compliant' scuttlebutt client could choose to interpret a 'delete this account' message as a filter for any messages that match said public key. Many client's UX understand that the state of messages may be incomplete due to the P2P nature, so thats kinda nice too.
I’m planning to add a “delete my account” POST form, in the logged-in app.
I assume this will be fine.
If we ever get to the kind of scale that would require us to have automatic account creation, we’ll see. We certainly have the technical means to do it. Until then, we’ll have volunteer admins creating accounts.
I know that most services do everything they can, to push for massive scale, but we’re different. It’s an NPO, serving a fairly small subset of the population, and we need to be careful not to sacrifice quality for scale (heresy, I know).
The temp passwords are auto-generated and sent to the user, and stored in the traditional one-way hash. The dashboard can reset passwords, but we pretty much let the user do what they want, once the account is set up.
Seems like a case where in 2021 this rule is good, but blocks the creation of new business/product/tools that don't confirm with the 2020 way of thinking... which is good for apple.
Well if you follow the GDPR: yes. Article 17.2
> Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data.
It comes down to the individual to interpret and enforce a solution that may or may not be in compliance.
It's like doing taxes in the US. You may or may not doing it correctly and you'll only find out if they start knocking.
This is just not possible for a lot of data like SSB.
How would you do this if someone asked github to delete all their commits across repos?
> For the purposes of this Regulation:
> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;
Putting PII or UGC into immutable storage is poor design, unfortunately, both users and laws want this information destroyable.
But in your case I’m not sure what exactly is the problem other than Apple doesn’t believe you… you can still delete the account it’s just deleted locally.
And you may be required to delete any server side identifiers if such exist.
Can't the app be reset to a state as if it was just installed ?
If such data exists in an app under control of the user, then uninstallation is fine.
If you persist that data in your own systems, you must provide a way to withdraw that consent. Same with data shared with third parties.
If you create an account in first party systems, you must provide a way to delete that account.
If the account is created outside the app (say via your website), thats fine, but you may get the same regulatory pressures directly (from GDPR, from California, etc) to support deletion in the same context.
Same is true for anything crypto. The account as it were exists on many devices, but it's not something you as the app creator can manage.
I think apple protecting privacy is good, but the effect on actually private systems is complicated.