Hacker News Reader

Comment by rgovostes | Hacker News Reader

Which is the perplexing thing here. The frenzy to paint this as anti-privacy given outlandish scenarios could very well end up killing a very pro-privacy move towards stronger encryption for everyone.

It would be vastly easier for them to do this on the server, and never expend the engineering effort to implement device-side scanning with all these cryptographic safeguards, and altogether abandon E2EE for photos, not to mention the lobbying effort to protect E2EE against legislation.

Today governments could demand Apple scan through every photo in iCloud. iOS today does NN-based classification of your photo library and Apple could in theory be compelled to modify this to report on certain kinds of content.

(You can argue: The best for privacy is E2EE without CSAM scanning. This puts them on much less secure footing to defend against anti-E2EE legislation, so it would be risky.)

View on HN

That might be slightly valid if Apple had any plans to do e2e encryption. The fact that they haven’t said a word on that front would seem to indicate that they have no such plans, have never had such plans, and are not willing to make such plans.

Another alternative would be to scan for CSAM and simply choose not to upload it and show a warning instead. I don’t get why folks are overlooking the absolutely critical _and then it snitches to Apple and/or the government_ part.

P.S. it is weird to say Apple is “abandoning” an e2e encryption feature it doesn’t have, has never announced, and has made no mention of at any point, despite clear public pressure.

My understanding of the law is if you believe you have CP you must report it.

Apple has not announced anything about E2EE, you are right, that is speculative. I think this intention is telegraphed by a few recent actions they’ve taken, from strongest to weakest evidence:

1. The fact that they built device-side scanning in the first place when they could have done it quietly on the server. They invested significant engineering time into the advanced cryptographic algorithms used, such as the private set intersection and threshold secret sharing. They had their work vetted, in public, by well-known cryptographers from academia. This is all leading-edge cryptographic engineering, most of which I would bet is being deployed in a consumer product for the first time ever.

It only makes sense that they would do this if they intend to cut off the capability for this type of scanning on the server altogether.

2. They recently added more account recovery options, a necessary step towards helping the average user avoid catastrophic loss of E2EE data if they need to reset their password.

3. They announced well outside of their regular cycle of product announcements (June, September). This is unusual for Apple and could mean they plan to announce something else like E2EE in September. In their public statements they have indicated that this is one component of future unspecified plans.

iMessage, FaceTime, iCloud Keychain, etc. are all E2EE. It is not completely unreasonable to think that they would endeavor to encrypt more content. If there were political hurdles to doing so in the past (as reported), these might be mitigated by the new features.

> The frenzy to paint this as anti-privacy given outlandish scenarios could very well end up killing a very pro-privacy move towards stronger encryption for everyone

I'm not sure a device you own silently scanning your files at someone else's behest can really be counted as a privacy win. You have no idea what it's actually doing, or how this process could be subverted for criminal or political purposes.

End-to-end encryption only means something if you and whoever you intend to communicate with control the endpoints. With an iOS device, you don't: Apple controls the endpoint. You may have paid for the device, but Apple has exclusive control of the software. You don't have the ability to replace it with third-party software or even to audit the source code for the software Apple supplies and verify that it matches the binaries. Consequently, you have to assume that anything you put on the device has already been shared with Apple, simply because Apple's software has access to it. This move just makes their control over the operation of "your" device more explicit.

The best for privacy would be E2EE where the backup software never even has access to the unencrypted data. In other words, the backup image(s) are created locally by auditable open-source (or at least source-available) software, encrypted and signed using a key or password known only to the device owner, and provided to the backup service as opaque blob(s). The backup service never has access to the raw data and is incapable of accessing or tampering with the content of the backup. Untrusted services would be restricted to have access to either plaintext data or the network—never both. Any network application wanting access to local photos, e.g. for sharing, would need to go through a privileged photo-choosing interface and would only be granted access to the selected photo(s). Even this has some concerns since the local photo software could embed information into unrelated photos to exfiltrate data to the network when those photos are shared, but you could at least compartmentalize the data to limit the potential for cross-contamination.

Or, you know, just use a fully open device and open source software in the first place so you're not playing silly adversarial games with a device you rely on for everything.

> Or, you know, just use a fully open device and open source software in the first place so you're not playing silly adversarial games with a device you rely on for everything.

Are you using open source hardware? And then how are you auditing the supply chain to ensure the hardware you're receiving matches the open sourced design?

Fully open source hardware with an audited supply chain would be ideal, yes. We're not quite there yet, though some groups are working on it, and a device like the PinePhone is a big step in the right direction. There is still a risk that components may be unknowingly compromised but at least you're not stuck running software on "your" device which is publicly acknowledged to place the manufacturer's interests above your own.

It's still a good ideal to enforce compartmentalization and privilege separation, of course. That last sentence was aimed at knowingly running untrusted proprietary software and relying on compartmentalization alone—I didn't mean to imply that one should forego proper security architecture just because the hardware and software are a bit more open.

Reply on news.ycombinator.com