Hacker News Reader

Comment by anarchogeek | Hacker News Reader

What about inmutable systems? My app (using scuttlebutt) creates an 'account' but it's located as crypto keys only within the app and apple keychain. So far the apple reviewers refused to believe that it works like. It's open source, they've got the code... but still....

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.

View on HN

This is why using the blockchain got user data is such a stupid idea. The immutability makes it impossible to redact or remove information, even if that information is encrypted. The same is true foor P2P services where there is no central accounting system.

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.

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

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.

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.

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.

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

It's simple. Don't offer account deletion. You comply with both in that case.

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

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.

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.

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.

I know at least two swiss banks.

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.

Monzo.

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

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.

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

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.

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.

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.

Only accessible to the bank and every megacorp they're selling your data to

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

I agree that things can get complicated when taking into consideration multiple countries. But I think this is the cost of doing business and caring about users. If you do business in multiple countries then that is the cost to be paid.

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.

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?

When have you been able to do a rental agreement through an app without signing paperwork?

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?

Never mind the banks. UK companies have to keep VAT records for 6 years

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.

Well that's rather flippant. Where does it say that Apple is only talking about social media apps?

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.

> This is why using the blockchain got user data is such a stupid idea.

maybe for you, but there are use cases...

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.

> but that's not relevant to the point I'm trying to make.

why do you talk about it if it isn't relevant?

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

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

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

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.

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.

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.

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.

On the other hand, if all currency was on a blockchain it would be possible to perform block chain analysis to determine each individual’s wealth and income making taxes much easier.

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.

if you delete the key - the data is effectively gone

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.

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

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.

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

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

That's kinda the whole point :).

Your app is incompatible with the Apple App Store.

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.

What if you're making an unofficial, unaffiliated app for someone else's service, and their API/protocol doesn't support deleting accounts?

If your app implements account creation, then it will likely be taken down unless either your app removes create-account support or the API and your app implement delete-account support, as a user would reasonably expect that you're able to delete the accounts that you create.

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.

> 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 don't see why that would be any different. If it was, then companies who find enough value in not providing a deletion option could pay someone to submit an app on their behalf. There's no way for Apple to know whether or not an app submitted by a third party is actually full independent of the service.

Then you won't be able to continue making that app.

And this is why Apple needs to be forced to allow app sideloading on iOS. A software and hardware company shouldn't be playing police.

Or just stop buying Apple devices? That way the duopoly can shift from iOS/Android to Android/<Linux phones, or some other open alternative>.

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.

> Or just stop buying Apple devices

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.

Don’t buy their phones.

The rest of us will continue to because we want Apple policing apps on our behalf.

Blockchain wallets are an interesting case. I would argue that for example an Ethereum wallet that generates an address for you in the Ethereum system is not required to provide a way to delete that account again. Similarly, the Chrome app is not required to allow you to delete your hackernews account even though you created it using the Chrome app. Generally, if an app enables you to create an account in a system controlled by someone else, the account deletion rule shouldn’t be applicable.

I do not believe Apple will make a distinction based on corporate structure - if you support creating an account, you need to support deleting it. If you can't support deleting it, you can't support creating it in-app.

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.

Generally, if an app enables you to create an account in a system controlled by someone else, the account deletion rule shouldn’t be applicable

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.

Safari enables me to create accounts on lots of services controlled by third parties and, for some of these, Safari does not symmetrically enable me to initiate a deletion in-app.

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

Safari enables me to create accounts on lots of services controlled by third parties and, for some of these, Safari does not symmetrically enable me to initiate a deletion in-app.

This might be the weakest strawman argument I've ever seen. Well done.

It's very nearly the literal sentence that preceded the text you quoted upthread. It's exactly what we're talking about here and what you seem to be agreeing that Apple is intending to (and right to) enforce.

Defining account will be interesting. One definition might be:

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 writing an app that has an account on a server. A user with no account can send a POST form (through the app), requesting that we create an account for them. We do so, through an admin dashboard. It’s easy to completely delete the account through the same dashboard, and I don’t think we have any legal obligations to retain the account.

I’m planning to add a “delete my account” POST form, in the logged-in app.

I assume this will be fine.

Why not just automatically create/delete the account? What's the purpose of manually transcribing their information to an admin panel? Also, does this mean you have humans copying over and potentially looking at (even if only on accident) people's passwords?

It’s an app that is aimed at a specific demographic. It’s fairly important that we do our best to avoid giving accounts to “just anybody.”

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.

An account is quite literally an account of all the data added by a user.

Can you just delete the key and local data? Is the requirement to push that deletion to all other SSB instances?

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.

> Is the requirement to push that deletion to all other SSB instances?

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.

If the personal data is encrypted and you destroy the only key that can be used to decrypt it, is it still personal data? Or is it now simply some random bytes?

We built a system that creates backups of PII using that mechanism; throw away the key after data is supposed to be deleted. That is legal under EU GDPR.

What's funny is that all these laws and (appstore) rules are not very well thought.

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.

I had this exact question for our privacy legal team and the answer I got was that deleting the keys to encrypted data is legally equivalent to deleting the data itself.

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

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?

Commits are not personal data in the GDPR sense.

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

Are you certain that an app developer for a client would qualify as a Data Controller here? As long as the relevant data never passes through their or other third-party servers and it's strictly local account setup interfacing with SSB I think they are not?

I personally don’t think it’s a good idea for lay people to be using systems where they can’t delete their user data. Maybe Apples isn’t the right platform for such things.

Nobody is asking you to actually delete the information. I suppose that with a proper design it should be possible to mark an account as inactive, make the associated profile data as inaccessible (if it's accessible via the web, for instance), and, most importantly, stop requiring this account when using the app.

Putting PII or UGC into immutable storage is poor design, unfortunately, both users and laws want this information destroyable.

Maybe a tombstone record in your immutable system? It is technically marking the account as deleted and the data is unrecoverable if the only encryption keys have been safely purged...

Congratulations, you turned a trivial problem into an unsolvable one for no reason at all.

I'm working on an application where a digest replaces the data on delete. The digest is immutable, which represents the data, not the data itself.

It’s the same as trying adhering to RTBF/GDPR with a blockchain or any other immutable data store… Your design decisions need to match the regulatory or other commercial / situational requirements.

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.

For "actually private" systems like this the solution should be cryptoshredding. If this is not possible (f.e. because you believe information published once should be available forever), then the app is bad and should not exist. People have a right to be forgotten.

> deletion of their account from within the app.

Can't the app be reset to a state as if it was just installed ?

Well, from your perspective, wouldn't mean you just need to discard such keys for making the account unrecoverable from your perspective?

my guess would be to just delete all local data, instruct the user to destroy all private keys, and consider the data delete it. I think in this situation, best effort to "delete" the data is all you can do. IN this case, if all keys are deleted, the data effectively becomes meaningless bits.

You must provide a way to undo first party and third party data retention of personal data at the same level as the initial retention.

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.

Change your data model. That’s the answer. Add setters to the smart contract to change variables. It’s not that hard.

Scuttlebutt isn't a blockchain and doesn't have a concept of "smart contracts"

Reply on news.ycombinator.com