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.
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.
Try going to random bank websites and click on "open account".
Digital-only, but a "real" bank in every sense of the word.
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.
“…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.
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.
1: I can, nothing catastrophic happened. Other than the Meteor codebase.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.