Hacker News Reader

Comment by new299 | Hacker News Reader

Some have speculated that with the introduction of the PSI/CSAM system Apple will enable E2EE backups. Given the lack of an explicit statement on Apple's part and their history regarding E2EE backups (this article, and other statements). It seems really unlikely to me that Apple will enable E2EE backups.

Under E2EE, assuming the device key is randomly generated, if you have one device (as many users do) and you lose that device you would lose all your data. The alternative is the key is derived from your iCloud password, in which case, if you forget your password, you lose all your data.

Right now, you can browse your photos online. There's been no statement that this is going away. Implementing this functionality with E2EE backups seem highly problematic.

These are huge changes to iCloud functionality that Apple would surely announce...

There are many open questions. And given that there’s no clear statement from Apple, I’m inclined to believe that they retain the ability to decrypt all data.

View on HN

A viable alternative is multiple LUKS-style key slots, one per registered device that can be unlocked with a device keys, and one that is by default encrypted with a key derived from your iCloud password. If you lose all your iDevices _and_ your password at the same time, you lose your data.

They could also make this opt in (add another escrow key slot by default, but allow you to promise that you've written down a recovery key and then destroy the escrow key slot).

Online browsing would use the iCloud password to decrypt the images client side. Thumbnails could be generated client side and stored alongside the images under the same key.

You can make this pretty transparent.

> If you lose all your iDevices _and_ your password at the same time ...

I don't know how this is with iPhones (I don't own one), but with Android these events are almost 100% correlated for many people. That's because you never get prompted for your Google account password on your phone. If you don't use the same Google account on your phone as on your desktop, or don't really use your Google account on the desktop that much to begin with (both apply to me and plenty of others I'm sure) then you might never need to know your password. I've seen people not even realise that they have a Google account, despite using one every day on their phone. Is there anything significantly different with Apple accounts?

In case it seems unlikely that someone would not use their phone account on their desktop, remember that plenty of young people today don't even have a non-phone device.

You can reset your password with email and phone number. Did it once.

Right, because there isn't the end-to-end encryption scheme that we're currently discussing. You seem to have missed the point of the conversation:

Comment 1: The problem with adding end-to-end encryption is that password reset is no longer possible (or it's possible but your data is lost)

Comment 2: You can come up with an end-to-end encryption scheme where you can reset your password and keep your data so long as you still have your phone (or when you lose your phone so long as you remember your password)

Comment 3 (mine): But if you lose your phone you often don't have your password any more, so that doesn't really help

By "Is there anything significantly different with Apple accounts?" I really meant does it often ask you to retype your password or otherwise force you to remember it.

I have to sign-in with my Apple-ID regularly (once a month) - but only on MacOS-Devices.

> “That's because you never get prompted for your Google account password on your phone. […] then you might never need to know your password.”

This is so true. 1Password silently changed their UX on iPhone app 4 years (?) ago and the primary password was not required between app-quit. I had tweaked my password after using it every minute one weekend installing a new system. When I finally needed the master password, the new password was not accepted. Evidently I misremembered the tweak. That experience still burns me. Not forgotten, not forgiven.

iPhone requires iCloud for purchases, but I use touch password and bypass this. I never need to use iCloud password.

iOS purchases require an Apple account. iCloud uses Apple accounts too. But purchases don't require iCloud.

WhatsApps 'pin' method is a good one to prevent users forgetting passwords.

It periodically asks you for your password. If you get it right, it will wait longer before re-asking. If you get it wrong first time, it'll ask again more frequently (and let you pick a new one IIRC). Works pretty well against forgetful humans.

>If you lose all your iDevices _and_ your password at the same time, you lose your data.

This is the risk most non-tech Apple users aren't willing or even expecting to take. No way Apple would enable this, even as opt-in, because many would misconfigure it, lose their data and blame Apple that failed them.

And good luck explaining they need to buy another iPhone and guard the two instead of one to be truly secure.

There is a third option, which is to use secure elements in the datacenter to encrypt the device key with the user's screen lock code. The secure element prevents brute force attacks even with a low entropy passcode. The user can restore their backups on a fresh device only knowing their screen lock code, but backups remain end-to-end encrypted.

Google has done this for Android backups. Apple has actually done it too, but only for Keychain passwords and a couple of other things. So Apple actually already has an implementation of the right solution and intentionally prevents you from using it to secure your backups, reportedly because they failed to stand up to the FBI. Which is strange given their public stance in the San Bernardino case.

This still seems like it would require a significant change in functionality, which they would likely announce. I.e. lose your lock code, lose all your data. Also, are you going to enter your lock code online to browse photos in a browser? What about syncing between devices?

In the absence of an explicit announcement regarding these changes in functionality it seems unlikely to me.

You're right, Apple is definitely not going to secretly enable end-to-end encryption without announcing it.

If this client side photo scanning thing is part of an ongoing plan to eventually enable end-to-end encryption of iCloud, then Apple made a huge blunder. They should have waited until end to end encryption was ready first so that they could announce it simultaneously.

Or, get the contentious part out of the way so that your E2EE announcement isn’t overshadowed.

I don’t know how much I believe that, though.

What is the point of end-to-end encryption if the snitch for objectionable content lives on the device?

Reverse engineers can examine the snitch to see what it's looking for. Without semi-E2E, Apple could hand over every photo of every account to China and we would be none the wiser.

How? I can’t imagine security researchers wanting to hold csam and pictures of the police to test this out…

What's wrong with pictures of the police?

Also, a big concern that people have is what the Chinese government will want to be censored. Researchers in the US can investigate that without fear.

Apple has to follow local law. Rightfully so IMO the very last thing I want is US companies making us all honorary Americans.

Yes, and the next time you find yourself in a hold-up, just inform the perpetrators that what they're doing is actually illegal.

The problem is when local law requests data on someone from another country. Then everyone in the world's iCloud data is only as private as the least private country with influence over Apple (the US isn't that country IMO).

This is the pattern that signal took with secure value recovery as well.

> if you have one device (as many users do) and you lose that device you would lose all your data. The alternative is the key is derived from your iCloud password, in which case, if you forget your password, you lose all your data.

This is all a good point.

Purely coincidentally, the imminent next release of iOS adds new account recovery options: https://9to5mac.com/2021/08/06/how-to-use-icloud-data-recove...

That's a really interesting link, thanks. I'd not seen that. This statement:

> The service requires Apple to maintain access to your data to help you recover it. For your privacy, Apple can’t access or help you recover your end-to-end encrypted information, such as Keychain, Screen Time, and Health data.

Seems to suggest that there is no change to end-to-end encryption on iCloud.

If there is some upcoming change that has not been announced, Apple would try to be careful not to make any mention of it in the public betas.

From the screenshot of turning on "Use Recovery Key":

> If you create a recovery key and can't access your devices, Apple won't be able to help you regain access to your account or your data.

That sounds like E2EE backups, but its impossible to know if that is truly the case until they provide more details.

> Purely coincidentally, the imminent next release of iOS adds new account recovery options

The scariest thing about this update to me is that it makes one's iCloud account incompatible (permanently?) with iOS and Mac devices that are not on iOS 15 or Monterey.

At this point, with Apple introducing a feature for law enforcement the general public had no opinion on or interest in, I'd argue Apple is more likely to expand what the new system does than improve E2EE.

The theory was that they are adding the client-side backdoor to please the US institutions and to be allowed to E2EE iCloud.

Pretty insane that one needs to kowtow to illegal spies to be able to publish software.

Seems like a 1A battle they don't want to fight, because the actual retaliation for the 1A exercise would come in the form of regulation or antitrust that is unrelated to the publication of the objectionable software.

Sad state of affairs in the USA.

> if you have one device (as many users do) and you lose that device you would lose all your data.

Apple has given that excuse before, but they could just provide the option with a serious warning, or make you jump through a couple of hoops first.

Apple is known for not bifurcating user experiences by giving users many options to choose from, but they are also known for their stance on privacy. I don't see why they wouldn't allow for this, maybe at first to trial it on the few that want it before deciding to roll it iCloud-wide.

If I were Apple, from a legal standpoint, I'd prefer not to have the ability to decrypt my users' data. Only in that light does it make sense to introduce the PSI/CSAM system on Apple devices, so you can claim you don't host such content, even if you allow users E2EE backups.

Also if Apple did enable E2EE backups then law enforcement would put tremendous pressure on them to expand what they're scanning for in this new client side CSAM layer.

So I can encrypt my files but does that mean it'll still be proactively scanned for MFing child pornography without any prior evidence?

I don't want that on my phone because I'm not a criminal.

Solution: Don't buy Apple.

Never again!

luckily, I haven't used an iPhone as my main phone in years.

Yep when apple releases this monstrosity there is literally no way around it unless you encrypt your files before they ever hit your iphone or mac computer. Then they'll just be scanning encrypted data which is theoretically protected. Technically they will (at their discretion) only scan stuff headed for icloud. Theoretically it is still very possible for them to scan things on your phone and report you no matter whether you use icloud or not. 100% if you are using icloud everything will be scanned that's considered a "photo" before uploading it. Eventually (I predict with 99% probablity) this will be slowly extended to scanning everything on your iphone and imac equipments for other "criminal activities" such as financial transactions, all documents, etc for whatever the government at the time considers "criminal"

>Some have speculated that with the introduction of the PSI/CSAM system Apple will enable E2EE backups.

For me it seems that latest changes do not change anything, FBI will still object with the same reasons as in the past, because they will have a legal obtained warrant and they need the user backups/phone content. I do not see Apple fighting this in courts especially now when they also have a big fight vs Epic and a fight vs right to repair.

> I do not see Apple fighting this in courts especially now when they also have a big fight vs Epic and a fight vs right to repair.

Apple already gives up data on tens of thousands of users and accounts each year in response on requests from governments. Apple keeps statistics about those data requests here[1].

For reference, Apple gave data on over 31,000 users/accounts based on FISA requests and National Security Letter requests in the first half of 2020 alone[1].

During that same period, Apple provided data to the government's requests (non-FISA or NSL) about 9,000 times, and responded to requests for data with the data about ~85% of the time, and 92% in cases of "emergencies"[1].

[1] https://www.apple.com/legal/transparency/us.html

Yes, so I do not see Apple implementing true end to end encryption and telling to the FBI/NSA to fuck off. The fact that Apple can catch some CP now won't convince the government or some judges that is fine to stop the collaboration. In fact I can see it more likely that in secret or with a judge approval new hashes would be added into the secret database(maybe someone leaked some stuff to the press and some gov want to catch the involved people)

Just fyi the new acronym CSAM (Child Sexual Abuse Material) is much more fitting.. CP just makes it seem like dudes getting off on pictures and not evidence of a crime having taken place which is how I had it explained to me.

Apparently a lot of the CSAM on Tumblr were Snapchat selfies.

So CP is cancelled now? We all know what it means, good grief.

I'm sorry it offends you, but if you listen to a decent explanation it makes much better sense. There's more to it than printed material (definition of pornography). It's photographic evidence of a crime scene.

This is like giving into terrorists. FBI/NSA/local cops won't be happy until they have software regularly scanning everything on your computer for "criminal" activity and uploading it for them to review and add to your "social score" much like China is already implementing. I wouldn't be shocked if this wasn't built in anticipation of China cranking down the thumb screws and Apple wants to be able easily comply with spying on citizens in those nations whose government desires to do that.

I don't think it's highly problematic to browse end 2 end encrypted photos online. You need to decrypt them on the browser, but it's nothing WebCrypto or WebAssembly can't do.

I played a bit with crypto in a web browser using Rust and WebAssembly, and it works perfectly fine.

> It seems really unlikely to me that Apple will enable E2EE backups.

And even if they did, how would we verify that the code they instruct our hardware to run does e2ee correctly, without bugs or backdoors? Apple doesn't seem to be in the habit of opening much of their code or (on mobile) allowing users to install unapproved builds. Unless that changed, I would be skeptical, just as I am of all "e2ee" software that cannot be independently audited by anyone at any time.

Out of curiousity how are you auditing the pre compiled binaries of otherwise open source software?

I spent 2 months going through the signal code base checking it and now I need to audit the production code on their servers as well as the binaries they have compiled. Any tips?

I find it's much easier to audit the source code, and build the binaries yourself from that code.

Also, it's a collaborative effort. If you build your binaries from the same sources that other people use, then you can split up the work, and you all benefit from anyone's discoveries.

Obviously, we don't have perfect verification of the code we run. People can overlook things. Compilers can be subverted. Operating systems can be pwned. Malicious hardware can undermine all of our efforts. But let's not let perfect be the enemy of good, and let's not fool ourselves into thinking that faith in a corporation is a substitute for transparency.

You have to assume that everything you do not control and monitor is compromised.

I don't know why anyone would assume this changes anything with regards to E2E at all.

Like you've said, Apple haven't announced anything, and I don't see what the business case is from their perspective when most people don't know or care what that means (but surely will care if they lock themselves out of their data forever).

> There's been no statement that this is going away. Implementing this functionality with E2EE backups seem highly problematic.

No more problematic than WhatsApp offering WhatsApp web (web.whatsapp.com) or Signal offering its desktop client while being fully end-to-end encrypted and routing communications through the phone.

Some also the introduction of the PSI/CSAM system to Apple means anything they do can no longer be considered E2EE as there is a built in backdoor to the encryption that allows a 3rd party to scan communications, as such it should not be considered a End-to-End Encryption system

I agree with this analysis

Correct me if I am wrong. But I think E2EE also makes storage cost much more expensive since no piece of Data are the same again.

4th option.

A user provided key, not derived from the password.

Chrome uses (used?) this for History encryption, etc.

5th option:

Apple (or whomever) could sell a "backup box": a simple embedded device with RAID 1 (mirroring) storage and the usual data/charging port(s). First time you plug an iphone into it you are asked to verify using the connected device to store backups.

The user then uses the "backup box" as their regular home charger. Backups happen automatically while charging. The user doesn't worry about keys; attack surface is limited to physically local risks (no network!). People already understand how to protect a physical device: lock in in a safe, move it to a safer location, etc. Instead of trying to solve the security problem for the user, give the user tool they can understand that allow them to protect themselves.

> if you have one device (as many users do) and you lose that device you would lose all your data

On the other hand: Apple loves giving people reasons to have more Apple devices

An obvious solution would be to allow third-party storage services where you can dump your device data pre-encrypted and restore from those services. Only you would have the key. It isn't hard to implement.

The hard part would be getting the US security apparatus to allow it. ALL major storage providers DON'T support end-to-end encryption for this reason. Not Google. Not Microsoft. Not Apple. Not Dropbox. Isn't this interesting?

Furthermore, talk of supporting end-to-end encryption is basically NOT in the Overton window in these companies as far as I know. Discussion of it is met by silence from management. It is weird when you begin to see the spider webs of power in society.

All those people positing that it this is an effort by Apple to push for end-to-end encryption are either disingenuous or wrong headed. If Apple even thought about end-to-end encryption, the whole US government would come down on Apple like a ton of bricks.

Apple has shown no recent indication of even leaning in this direction. Not only does Apple not directly support end-to-end encrypted backup on iOS devices to third parties, it precludes it from happening. You are stuck backing up to your Mac or jailbreaking.

EDIT: There seem to be a few small movements in this area. Dropbox has their Vault with pin based protection. Seems incredibly and intentionally weak.

Google's Android backups claim end to end encryption.

> By design, this means that no one (including Google) can access a user's backed-up application data without specifically knowing their passcode.

https://security.googleblog.com/2018/10/google-and-android-h...

Not if that application data is already part of Google services. That appears to application data for non-Google services.

https://transparencyreport.google.com/user-data/us-national-...

But I do stand corrected on non-Google application data.

How do you restore from a different device? Oh, you only need the passcode.

> The hard part would be getting the US security apparatus to allow it. This is why ALL the major storage providers DON'T support end-to-end encryption.

I don't think so. The reason is there's no money to be earned with being simply a storage provider. Additional processing, indexing, workflow tools etc. is what people pay for. That's not possible with E2E encryption.

What is Dropbox Vault then?

https://www.dropbox.com/features/security/vault

Why only pincode protection?

What about Dropbox Password? That seems to be zero knowledge?

They are two separate attempts in the security space.

What do you call Tarsnap, rsync.net, S3, and Backblaze?

> the major storage providers **major**

Their claim wasn't limited to major storage providers. And what do you call S3?

This isn't the kind of "storage provider" we were talking about. As long as you simply put blobs in there, you don't need end to end encryption, you can simply do the encryption yourself (like people do with these services).

Reply on news.ycombinator.com