Hacker News Reader

Comment by Terretta | Hacker News Reader

> Putting this on the client device is dubious

Putting it server side is categorically worse. Putting it in the client SDK for iCloud (architecturally speaking) rather than on cloud storage or in the OS is clearly the better correct technical choice, tying surveillance’s hands in a way server side or OS would not.

Most every client SDK routinely checks content before upload, it’s a best practice. Careful examination suggests this was engineered better than that practice.

(Note: even tech trade posts such as LWN, Stratechery, or Daring Fireball trying to write well about this need to sit down a minute and have how it actually works walked through for them, as do many in this community.)

FWIW, I agree with much of the rest of your post except the rationale for low reporting counts.

View on HN

No, architecturally there's no reason to do it on the client side. You're uploading a photo to iCloud, encrypted with a key that Apple controls. The only reason to use even a little bit of battery power to do the check on the client, and to do this elaborate song-and-dance around only notifying Apple if there are a certain number of positive matches, is that it creates the (false) impression that Apple couldn't just check your photos on the server side if they wanted to.

It's basically engineering with the goal of creating a perception of privacy rather than actual privacy. I don't really care that much about Apple policing what you upload to iCloud, but this disingenuous architecture does annoy me a bit, and there's also the added insult of having a device in your pocket that by design works against its owner (reminiscent of "treacherous computing"). These problems would go away if they just did the check on the server side.

Apple gets hung up on weird stuff. Likely doing work phone side was an environmental argument. The amount of energy used to decrypt server side to create the hash was marginally larger than the amount used by the phone pre-encryption with cost of transmitting. (Bonus that the energy and CPU was paid for by the client). The result for either location is identical.

> No, architecturally there's no reason to do it on the client side.

The architectural reason is to do things the server couldn’t.

> You're uploading a photo to iCloud, encrypted with a key that Apple controls.

The architectural reason is so the server doesn’t have to be able to read the photo, and it need not be a key Apple controls.

Your first two sentences are the exact reason to do it on the client instead of on the server, such that it’s possible to have e2e encryption opaque to the server.

But it's not e2e encrypted so I don't know what point you think you're making here.

If I were to design a spying device, I would definitively put it on both the client device and the server. That is because third party apps are not required to put their contents on Apple servers. By putting it on the client, you can potentially hoover up any app’s data. Just write a background service that scans the client’s file system and track all calls to encryption APIs.

The list of apps is such a treasure trove. Signal? Clubhouse? Telegram?

https://developer.apple.com/documentation/security/complying...

I need to research what Signal does on iOS. My next canary is encryption of messaging apps other than iMessage.

> Putting it server side is categorically worse.

Why? Putting it server-side means that it's only possible to examine the images that they claim they are targeting -- those going to the cloud. That seems like a much better and more private way to do it, because it's putting the surveillance "in their house", so to speak, instead of mine.

Keeping it in the client SDK means it’s possible to implement storage the server can never see into, in a manner that can be verified by red teams.

Reply on news.ycombinator.com