4 ms·

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

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.

LexGray 5y ago
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.
Terretta 5y ago
> 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.
- lordlic 5y ago
  But it's not e2e encrypted so I don't know what point you think you're making here.

LexGray 5y ago

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.

Terretta 5y ago

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

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