5 ms·
I would not say it is "scanning" as the device doesn't know the final result (match or not). If I had to summarize very broadly the thing to my understanding: i
by alibert 5y ago
I would not say it is "scanning" as the device doesn't know the final result (match or not). If I had to summarize very broadly the thing to my understanding: it will be like doing a "loose" SHA on every photos in the Photos app and sending these to Apple (if iCloud is enabled). Server side, Apple checks if the hashes match or not. Isn't this like "scanning in iCloud" but without Apple needing to have a decrypted photos in their servers ?
- yyyk 5y ago>I would not say it is "scanning" as the device doesn't know the final result (match or not) I don't think this is a relevant distinction. If the device had known the result and just sent Y/N to Apple, what would change in your argument? Nothing. Your last sentence would be just as arguable. >Isn't this like "scanning in iCloud" but without Apple needing to have a decrypted photos in their servers? Note that Apple right now already has the decrypted photos since they have the decryption key. There's no evidence they are even considering E2EE right now, and since there are other legal requirements for scanning (e.g. terrorist material) I'm not sure this allows them to implement E2EE. And I don't see how the client-side feature can remain as is. There are obvious cases that would be caught by the typical server-side scanning and won't be caught here, so once the door was opened, the government will pressure. For example: * What happens when the NCMEC database updates? It could be that the phone rescans all your images. Or that apple keeps the hash and rescans that. Note that the second case is identical to some server-side scanning implementations. * What happens when you upload something to iCloud, delete it from your phone and then the NCMEC database updates? If Apple keeps the hash, it's just server-side again. If Apple doesn't keep it but uses client side scanning, the phone has to keep the hashes so you can't ever truely delete an image you've taken. If there's no rescan, the bad guys get to keep CSAM on iCloud so long as they passed the original scanning with the older NCMEC database - surely the government wouldn't accept that. (I considered scanning on download but I don't know if Apple/the government would like this compromise, since with that approach CSAM can remain on iCloud undetected so long as it's not downloaded, anyway it's not in the original papers). Basically, either they scan on client-side more than they let on or we end up in a world with both server-side and client-side scanning. The latter is arguably worst of both worlds, the former has implications which need to be looked at.
- hfsh 5y ago> I would not say it is "scanning" as the device doesn't know the final result (match or not). I would argue that 'scanning' is the process of collecting data, not necessarily of interpreting it.
- mikehearn 5y agoIsn't the "interpreting" step the one that matters? Apple takes a photo, runs it through some on-device transformations to create an encrypted safety voucher, then it gets "interpreted" once it's uploaded to the cloud and Apple attempts to decrypt it using their secret key. Google uploads a raw photo, which itself is essentially a meaningless value in the context of identifying CSAM, and Google "interprets" it on the server by hashing it and comparing it against some database. In both cases, the values that are uploaded by the respective companies' devices don't mean anything, in the context of CSAM identification, until they are interpreted on the server.