The parts of it being uploaded to iCloud, not the whole thing, yes?
> and sending hashes to an unaccountable, no oversight nonprofit (NCMEC)
As I understand it, the whole point is that the hashes are computed on-device and compared to the NCMEC database on-device. Is my understanding incorrect?
This is policy, not capability. The capability is each and every image can be scanned.
> As I understand it, the whole point is that the hashes are computed on-device and compared to the NCMEC database on-device. Is my understanding incorrect?
You are incorrect but also the concern is NCMEC’s database’s accuracy. Also, going by other NPO’s the government has taken an interest in, NCMEC is very exposed to government control. They can easily decide to allow the government to slip a few extra hashes in their database and tell no one. They can do this in exchange for protecting their NPO status, a national security letter, anything. We will never know and if we find out, we will have no way to hold them accountable. Ever.
Anyway, the NMEC database is NDA’ed and a secret. It’s not open to review or auditing. It’s also grossly inaccurate and nearly useless.
You are taking these points entirely out of context and in a vacuum. It reads a bit bad faith and win an Internet argument at any cost.
Are you familiar with the implementation? If it's in the uploader, then the capability for each image to be scanned sounds like it would involve a bunch of code changes.
But let's posit that the implementation just checks the "uploaded to iCloud" flag and hence this is "just policy". I agree that this is concerning, but I think it's important to distinguish between "could do X" and "is doing X" when describing a situation.
> You are incorrect
I would love to be enlightened here. Can you please point me to an explanation of how my understanding is incorrect?
> but also the concern is NCMEC’s database’s accuracy
I absolutely share this concern.
> You are taking these points entirely out of context and in a vacuum.
No, I don't think I am. I think there is enough heated rhetoric going on here, with people mis-stating what is actually going on to justify how they feel about it, that it's worth being very clear about what the problems here really are. Otherwise it feels like people are arguing against strawmen and makes it too easy to dismiss concerns that are very pertinent.
The original article for this thread, by the way, does a good job here.
But I will respond to this point:
I said:
> Anyway, the NMEC database is NDA’ed and a secret. It’s not open to review or auditing.
NMEC itself would never go for the entirety of the database sitting on each phone. It’s a jailbreak away from “Them” having the database and being able to check their images before uploading them places. (This overlooks the fact that it’s almost universally accepted by everyone outside of NMEC that deals with NMEC that “They” have the database several times over.)
That capability is in every software/app that has access to your photos and to the internet, on any device.
If you leave your phone on default settings, that’s all of them. In fact you need to turn off a lot of things. Turn off backups, Photo Stream, Files, Mail Drop, album sharing (make sure you don’t accept any invites to shared albums or you will get flagged) and I’m sure there are more iCloud integrations I’m not aware of.
It’s actually quite hard to not use iCloud, by design.
It's funny, it is literally in the first paragraph of the system overview in terms of how the database of hashes is stored - "which is securely stored on users’ devices"
"Apple further transforms this database into an unreadable set of hashes, which is securely stored on users’ devices."
> the blinding step using the server-side secret is not possible on device because it is unknown to the device. The goal is to run the final step on the server and finish the process on server. This ensures the device doesn’t know the result of the match, but it can encode the result of the on-device match process before uploading to the server.
Note the last part: "... but it can encode the result of the on-device match process before uploading to the server." The result of the match already exists before it is uploaded to the server. This is also made clear in the diagram.
Depending on how you define "matching," it either occurs on-device or no explicit matching actually occurs. The server gets a payload for each uploaded image and attempts to use its server-side secret to derive its decryption key from the header. If (and only if) the image was a match - as determined by the blinded on-device comparison - it will now have a key to decrypt the rest of the payload (for review). Note that neither client nor server explicitly compare the real database hash to the image hash. The comparison is absorbed into crypto "properties."
1. For every image that's scanned, whether matching or non-matching, some data will be sent to the server.
2. Your phone never learns and has no way to tell which images match and which ones don't.