Live data from Hacker News

Security Threat Model Review of the Apple Child Safety Features [pdf]

apple.com

91–100 of 393 posts

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#91

> The second protection [against mis-inclusion of non CSAM hashes] is human review: there is no automated reporting in Apple’s system. All positive matches must be visually confirmed by Apple as containing CSAM before Apple will disable the account and file a report with the child safety organization. I don't understand this at all. As I understand it, part of the problem is that — in the US — Apple isn't legally all…

Your phone transmits the images with their security envelope (which was computed on device and contains neural hash and "visual derivative") to the iCloud server. During that process, Apple does not know whether there's any CSAM in it, so they can transmit legally.

Then the server determines whether the number of matches exceeds the threshold. Only if that is the case (by crypto magic) can the security envelope of the flagged images only (by crypto magic) be unlocked, and the "visual derivative" be reviewed.

(Note that if (at a later stage) E2EE is enabled for the photos, the images themselves would never be accessible by Apple or LE, whether flagged or not, if I understand the design correctly).

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#92
In other HN comments on this subject I've (hopefully) made it clear that I'm not really in favor of this project of Apple's, and that there's a legitimate "slippery slope" argument to be made here. So I hope people will entertain a contrarian question without downvoting me into oblivion. :)

Here's the thing I keep circling around: assume that bad actors, government or otherwise, want to target political dissidents using internet-enabled smartphones. The more we learn about the way Apple actually implemented this technology, the less likely it seems that it would make it radically easier for those bad actors to do so. For instance, the "it only scans photos uploaded to iCloud" element isn't just an arbitrary limitation that can be flipped with one line of code, as some folks seem to think; as Erik Neuenschwander, head of Privacy Engineering at Apple, explained in an interview on TechCrunch[1]:

> Our system involves both an on-device component where the voucher is created, but nothing is learned, and a server-side component, which is where that voucher is sent along with data coming to Apple service and processed across the account to learn if there are collections of illegal CSAM. That means that it is a service feature.

Will this stop those bad actors if they're determined? No, of course not, but there are so many ways they can do it already. They'll get cloud storage providers to give them access. If they can't, they'll get network providers to give them access. And if those bad actors are, as many people fear, government actors, then they have tools far more potent than code: they have laws. It was illegal to export "strong encryption" for many years, remember? I've seen multiple reports that European lawmakers are planning to require some kind of scanning for CSAM. If this goes into effect, technology isn't going to block those laws for you. Your Purism phone will either be forced to comply or be illegal.

I wrote in a previous comment on this that one of Silicon Valley's original sins is that we tend to treat all problems as if they're engineering problems. Apple is treating CSAM as an engineering problem. Most of the discussion on HN about how horrible and wrong Apple is here still treats it as an engineering problem, though: well, you can get around this by just turning off iCloud Photos or never using Apple software or throwing your iPhone in the nearest lake and switching to Android, but only the right kind of Android, or maybe just never doing anything with computers again, which admittedly will probably be effective.

Yet at the end of the day, this isn't an engineering problem. It's a policy problem. It's a governance problem. In the long run, we solve this, at least in liberal democracies, by voting people into office who understand technology, understand the value of personal encryption, and last but certainly not least, understand the value of, well, liberal democracy. I know that's easy to dismiss as Pollyannaism, but "we need to protect ourselves from our own government" has a pretty dismal track record historically. The entire point of having a liberal democracy is that we are the government, and we can pull it back from authoritarianism.

The one thing that Apple is absolutely right about is that expanding what those hashes check for is a policy decision. Maybe where those hashes get checked isn't really what we need to be arguing about.

[1]: https://techcrunch.com/2021/08/10/interview-apples-head-of-p...

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#93

What’s not discussed in this Paper is how it won’t be used by third-party actors to falsely accuse someone. Does nobody remember the iCloud hack? What about instead of downloading Jennifer Lawrence’s photos, a hacker uploaded children to get someone falsely accused?

Google, Microsoft and a bunch of other services already scan for CSAM materials, yet this hasn’t been an issue so far. In fact I can’t really find a single case when someone was framed like this, despite how easy it is to fill someone’s account with CSAM and call the cops/wait. I don’t like the privacy and property rights issues of this but the whole someone will use this to frame someone is quite BS.

But the services you mentioned don’t do it on the device. The blind trust in Apple that everything will be ok is quite BS, and very naïve .

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#94

Earlier quoted context omitted.

You forgot, 'after it leaked'

It’s almost certain the “leak” was from someone they had pre-briefed prior to a launch. You don’t put together 80+ pages of technical documentation with multiple expert testimony in 16 hours.

'Almost certain'? Have you heard of contingency planning?

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#95

Earlier quoted context omitted.

...because cloud uploads require explicit user consent, practically speaking? Apple's system requires none.

I think the mods should consider shadow banning you. Your comments make little sense.

Ditto, too bad you got flagged earlier

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#96
post #81

> Apple will publish a Knowledge Base article containing a root hash of the encrypted CSAM hash database included with each version of every Apple operating system that supports the feature. Additionally, users will be able to inspect the root hash of the en- crypted database present on their device, and compare it to the expected root hash in the Knowledge Base article. This is just security theater, they already si…

> Until a 1-line code change happens that hooks it into UIImage. I really don't understand this view. You are using proprietary software, you are always an N-line change away from someone doing something you don't like. This situation doesn't change this. If you only use open source software and advocate for others to do the same, I would understand it more.

> I really don't understand this view. You are using proprietary software, you are always an N-line change away from someone doing something you don't like. This situation doesn't change this.

And I don't understand why it has to be black and white, I think the N is very important in this formula and if it is low that is a cause for concern. Like an enemy building a missile silo on an island just off your coast but promising it's just for defense.

All arguments I see is along the lines of "Apple can technically do anything they want anyways so this doesn't matter". But maybe you're right and moving to FOSS is the only solution long-term, that's what I'm doing if Apple goes through with this.

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#97

> The second protection [against mis-inclusion of non CSAM hashes] is human review: there is no automated reporting in Apple’s system. All positive matches must be visually confirmed by Apple as containing CSAM before Apple will disable the account and file a report with the child safety organization. I don't understand this at all. As I understand it, part of the problem is that — in the US — Apple isn't legally all…

Your understanding is incorrect. Apple can, and is in fact required to, verify that they have actual CSAM before forwarding it to the Cyber Tip line. At that point, they must delete the information within 60 days.

Interesting. In that case, do you know why they talk about reviews only seeing "visual derivatives" (from the second perceptual hash)?

Either these 'derivatives' basically contain the original image (so reviewers can verify that it's actual CSAM) and there's no point in using derivatives at all, or they're more abstract (eg. 8x8 pixellated images) in which case the reviewer can't see the actual content (but could confirm a database match).

Edit: I was able to find the answer, they suggest that the 'visual derivative' is something like a 'low-resolution version' of the original image, so the content should still be clearly visible.

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#98
post #56
post #26

Earlier quoted context omitted.

Yeah, it's weird. Speaking purely personally, whether the scanning happens immediately-before-upload on my phone or immediately-after-upload in the cloud doesn't really make a difference to me. But this is clearly not a universal opinion. The most-optimistic take on this I can see is that this program could be the prelude to needing to trust less people. If Apple can turn on e2e encryption for photos, using this prog…

> Speaking purely personally, whether the scanning happens immediately-before-upload on my phone or immediately-after-upload in the cloud doesn't really make a difference to me. What I find interesting is that so many people find it worse to do it on device, because of the risk that they do it to photos you don't intend to upload. This is clearly where Apple got caught off-guard, because to them, on-device = private.…

This seems like a necessary discussion to have in preparation for widespread, default end to end encryption.

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#99
post #90
post #41

Is there a good argument for doing the scanning on the phone and not on the iCloud servers?

Photos are currently encrypted e2e already so Apple does not have the access server side to create the hash unlike their competition who chews their customers data for machine learning. https://support.apple.com/en-us/HT202303

You've misread that page -- the table just refers to content being stored in an encrypted form, even if Apple still possesses a key. There's a list below it of fully end-to-end encrypted content, which doesn't include Photos.

Re: Security Threat Model Review of the Apple Child Safety Features [pdf]

#100

I strongly considered switching away from Apple products last weekend; but this document has convinced me otherwise. The threats people identify have minimal risk. If a total stranger offers you a bottle of water, you may worry about it being spiked, but him having offered the bottle doesn't make it more, or less, likely that he'll stab you after you accept it. They're separate events, no "slippery slope". It's very…

> If Apple has evil intent, or is being coerced by NSLs, they would (be forced to) implement the dangerous mechanism whether this Child Safety feature existed or not.

Apple used to fight implementing dangerous mechanisms. And succeeded.[1]

[1] https://en.wikipedia.org/wiki/FBI–Apple_encryption_dispute

Post reply on HN