Hate to break it to you but banks are not deleting your account immediately when you close it. They legally can't.

KYC/audit regs aside, it's also because the account belongs to the bank. The money is held in trust on your behalf, but the amounts are a liability on the institution's balance sheet. This is also why an increase in the balance of your deposit account is referred to as a credit; the statement is written from the bank's perspective, not yours.

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.

I think this way of framing it is perhaps misleading.

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.

> 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.

> apps that allow for account creation must also allow users to initiate deletion of their account from within the app

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

Couldn't you make that same argument for any online service? "I own the database and servers, its my account that I operate on the user's behalf. Therefore they cannot delete the account".

You can make that argument, and many do, and some courts may even be suckered into falling for it when push comes to shove. In a more jurisprudent analysis, however, it relies on a false parity between consumer and company in negotiating power.

Legislation like the GDPR is motivated in part to nullify such arguments.

This falls astray of the new Apple requirement though, as I understand it.

The requirement only applies if one can create the account in the app. At least here in Finland that is not an option in any of the local banks apps I have used.

You might think that at first, but the distinction can be made for data as well. The argument goes, when is your data, not really your data? How about, when it's actually my records, of your use, of my system.

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.

It's not just banks either.

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.

I don't think these are corner 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.

> 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.

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?

This is making a mountain out of a molehill. There's nothing to suggest any pre-conditions for deleting an account have to be removed, simply that it must be possible to "initiate deletion" from within the app.

Then you're defeating the purpose of the requirement, because the scummy scam service will let you "initiate" deletion but to actually carry it out you still have to call them and wait on hold for sixteen years or come show your ID in person at their offices in Northern Alaska.

Frankly, this would still be a good start compared to the norm today: You can't even find information about account deletion from most mobile apps, let alone initiate the process.

It clearly states that if you create the account in the app you have to be able to delete the account within the app.

In none of those cases are you creating the account within the app.

>In none of those cases are you creating the account within the app.

why not?

You don't think rental customers create an account on the app to make their initial reservation, then sign the paperwork once they pick up the car?

Just create a separate "online account" that links to the other database.

The exact wording Apple have used is "initiate deletion", that's quite different from immediate deletion. For example, you should be able to request that your bank close your account, via the app - is that too much to ask a bank?

Your point being? Not deleting data for legal reasons is still better than the data being physically impossible to delete.

A large meteor would delete it just fine.

With distributed data centers it needs to be a quite sizable meteor though. The dinosaur killer asteroid may not be enough if your redundancy is on the other side of the globe.

Keep your backup tapes in a safe on the other side of the pond, as they say.

I once worked in a large Meteor codebase and I cannot comment[1].

1: I can, nothing catastrophic happened. Other than the Meteor codebase.

A deleted bank account is not publicly accessible.

Not as a counterpoint, but you'd be mad not to stick "yet" at the end of that.

You still likely have a limited window. Once their obligations to keep your info are up, they're likely to purge it. It's a waste of resources to keep that around and not much value. Plus they surely know it's a liability. PII is treated very carefully in regulated industries. The less of it they have, the better.

And not only banks. Everything which has audit or signatures as part of their requirements will have legally required user data after a user leaves.

Can confirm, I worked at a fintech company previously with a large number of users. They had a "deleted_at" column on the user table in the database. It's not actually deleted.

Isn't this almost necessarily true for any system which needs an auditable history?

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

You don't need to delete the rows from the database. Just replace user's name, address and phone with random data.

Regulated financial services must also store the documentation and results for how they verified a user's identity, too. This involves talking to third parties that can tell you if a given user's name matches their tax identifiers, street addresses, phone number, et cetera.

Anyone competent is storing both their requests to those external APIs, as well as those responses, for the entirety of the recordkeeping requirement period.

The company needs 7 to 10 years of audit info. Of course they cannot 'delete' any account.

Banks are under a completely different set of regulations so are many other financial companies as well as other sectors like insurance and medical.

They have specific regulation regarding record retention.

This is not just banks but (nearly) all companies who deal with payment data will not delete anything related to payment for many many years. In India this use to be 10 years. USA I think it is 5 years.

Yes, pretty much anything that has anything to do with anti-money laundering takes 7 to 10 years to even consider forgetting your account.

Ok, and? 7-10 years isn't forever, or at least certainly not long enough to negate GP's point about blockchain immutability being undesirable as far as account deletion is concerned.

Did I argue that point at all? Such immutable system will absolutely not be applicable to the EU and GDPR unless all the data is encrypted and the encryption keys are not part of the major chain.

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.

This is different from not deleting your account. Having to keep a record of your purchases doesn't mean they can keep track of your hobbies or whatever.

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.

> all apps that allow for account creation must also allow users to initiate deletion of their account from within the app

No, that doesn't seem true.

What bank lets you create an account just from the app?

… Okay, the digital-only ones, maybe. But virtually all other banks I've used make you go to a branch.

Revolut and many other apps allow creation of accounts from the app per local regulations. It may require SSN in the US to complete sign-up, but it's all done through the app and is immediate.

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.

Any bank in America for the last 20 years. I opened my very first account at the branch cause I though they need to see me. Dozens of accounts at multiple financial institutions after that I never had to go to the branch. Most of my accounts held at places that don't have any branches within hundreds of miles.

In fact Wells Fargo is famous for opening account for you without you even thinking about it.

Meanwhile, my experience with 6 bank accounts is exactly the opposite.

I remember pre 2008 financial collapse when you could call a banker and they’d open an account for you sight unseen.

Now it’s only internet banks that do this. They still require lots of KYC documents to open an account.

I signed up for Schwab (and numerous other financial institutions that were not "banks" per se) without having to go to a branch in person. You usually just submit photos of documents and, in some cases, have your picture taken at your computer.

Congrats, now those docs are stored in a database. Good luck getting them deleted.

Yes, banks store your information in databases. Not sure what you’re driving at.

They certainly don't scan and save images of your identifying documents when you go into the branch. They may store your DL and SSN number. This is a lot less than you volunteering up your identifying documents to a public webserver.

Ah, yeah, that was the issue; I didn't have documents. I now remember that I could've signed up entirely online, had I had them.

Monzo.

Digital-only, but a "real" bank in every sense of the word.

I think most major brick and mortar banks allow you to open account fully online.

Try going to random bank websites and click on "open account".

The guidelines apply to creation of accounts within the app, not just anywhere online.

ANZ Bank, in Australia - and I'm assuming the others of the Big 4 do as well (CBA, NAB and Westpac, that is). It's been added to the App for some account types over the past year or so.

All major banks let you create an account without going in to a branch now.

I know at least two swiss banks.

Does that apply if you automatically create an "account"?

It doesn’t actually say the account must be deleted. It says:

“…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.

And this is a major reason I'm personally wary about a lot of ideas around putting stuff onto a public blockchain. Once it's there it's never going away.

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.

Welcome to Monero, where you don't have to think about problems like that because privacy is by default.

each account's wealth and income

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)

You’d miss the value (and often ownership percentages) of anything illiquid (real estate, privately held companies/partnerships, and trusts).

That’s a significant slippage from the dystopian ideal of being able to calculate something that many think is none of your business.

> even if that information is encrypted.

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.

For now.

If the blockchain survives long enough, that info will become public in time.

We invade the privacy of people from a few hundred years ago all the time and it's considered fine. Do you think there will be a breakthrough in encryprion breaking soon enough for it to matter?

Assuming this will take a few hundred years.

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.

If AES is broken in your lifetime, you're going to have _way_ bigger problems than somebody decrypting your blockchain ciphertext.

And if you're not encrypting data with AES (or one of a handful of other algorithms), then you should be worried _now_.

If all of AES, then yes. But a particular choice of algorithm parameters can become insecure much earlier.

> 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.

AES being broken doesn't mean someone managed to brute force a key. It means someone found a flaw that enables them to break any key in much less time than you'd expect a brute force attack to take. In other words, if AES is broken people would be able to read that ephemeral data quickly enough for it to be useful.

I know - and the ephemeral data that attackers were able to capture would of course be at risk.

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.

That’s a very optimistic opinion :)

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.

> 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.

The key aspect of a blockchain is that each block contains the hash of the previous block. That provides integrity guarantees that you don't get simply by using a central entity.

I'd say the "each block contains the hash of a previous block" property is the implementation but not the key aspect. (Unless you count a git repo as a blockchain too)

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.

That part is very easy to implement without all the extra cruft that a blockchain also brings with it. Git manages to do that same thing without burning a ton of coal every time you make a commit.

Bitcoin blockchain does not use AES, wallets do.

Elliptic curve signatures of the blocks are _significantly_ more fragile to quantum attacks than AES.

The thread is about somebody storing ciphertext in a blockchain.

But it doesn’t though right? If there’s a database breach 10 years from now and I’m able to crack pki with like a quantum computer or something then I have that data… I think.

You don't need the breach, the DB is already public (in encrypted form).

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.

AES is =not= weak vs quantum computers.

Likely the encryption key (per user) should be split between central and distributed (device) system. That way the operator can remove any identifiable user from the chain. Leaks of the central system won't have an immediate effect, either. Still quite a bizarre case.

Except it shouldn’t be up to the device makers to delete your “account”. It should be up to you. What’s stupid is the current system, where you bought an e-book and they can delete it from under your nose at any time.

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:

https://www.youtube.com/watch?v=pZ1O_gmPneI

You can have decentralized p2p systems that respect users (allow deletes). One example would be Gun which allows you to “tombstone” your data. Just overwrite it with a blank.

A new version of Scuttlebutt allows tombstoning too.

I think mutable should be the default. Make it all ephemeral with optional permanence.

Can you stop anyone keeping a copy of everything that someone tries to tombstone, though?

I think this is an interesting hypothetical. If you never sync up, though, are you still part of the app developers aura of responsibility? Deletion of the data has been initialized per requirement, and will propagate through the system at the rate the system is able to propagate data.

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.

I just need versioned file system. or make copies, or well anythting. Te entire idea of deleting public information and all players are well-behaved, etc. is beyond futile.

No, you can’t. But you also can’t stop someone from screenshotting everything you do online.

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.

Key management is how many comply with GDPR today. They encrypt the PII and associate it with the user. Then, when someone requests their info to be "deleted", they zero out the encryption key.

This should continue to work as long as you use systems that do not fall to pieces under quantum attacks.

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.

There are no known quantum attacks, so it's pretty pointless for most people to consider it in their threat models.

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.

There are select bits of info we should protect, but can't. If you're in the US, your SSN is one of those.

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.

The best way to do user data on-chain is to commit to hashes of the data over time as it changes, and have users provide the data for the latest hash when it's needed.

It’s not a blockchain, it’s a merkle tree.

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.

if you delete the key - the data is effectively gone

> The immutability makes it impossible to redact or remove information, even if that information is encrypted.

That's kinda the whole point :).

In event sourced systems, where the state of an application is stored as a sequence of immutable events, one way of solving the "delete" problem (e.g: GDPR) is to have all the events encrypted to begin with. The deletion (without performing a rewriting of the events) can be considered executed by simply "deleting" the key used to decrypt the events.

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.

> The immutability makes it impossible to redact or remove information, even if that information is encrypted.

If that's the case, does it not run foul of GDPR?

You're just hating on crypto and finding reasons for it. Crypto has uses cases that people are using at the moment and it's not up to you to decide how people should decide to use systems. If they want to own some NFTs because it's part of a game or simply to hold some generative art, that is their choice.

The issue is with Apple being Apple as usual.

There are use-cases for blockchain.¹ However, storing user data is not one of them.

¹: 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.

> It probably could be fine for public user data that you want to spread out and be somewhat resistant to censor from governments.

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

> Can you give an example?

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.

I mean an example for when you'd want to put user data on the blockchain – rather than a description of the general category. (It's a mistake many mathematicians make at one time or other: declaring a property on all members of a certain set without first checking whether it's the empty set.)

And yet we all knew about it without blockchains and cryptotransactions are banned in China.