Live data from Hacker News

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

apple.com

231–240 of 393 posts

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

#231
post #57

This seems like a pretty helpful document, and really shows how carefully the CSAM system has been designed. Two things that stuck out to me: 1) The CSAM hash database is encrypted on-device 2) The device doesn't know the results of hash comparisons These suggest to me that the hash comparison is going to happen inside the Secure Enclave - give it the encrypted database and the NeuralHash of an image, it gives you ba…

No secure enclave is needed, the system uses strong cryptography to protect Apple and their database providers from accountability.

I gave a semi-technical description of how private set intersection works here:

https://news.ycombinator.com/item?id=28124716

Assuming they implement it correctly and there are no apple-internal leaks we won't be discovering the content of the database.

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

#232
post #51
post #22

Earlier quoted context omitted.

> And there is no way to audit that the database is what they claim it is, doesn't contain multiple databases that can be activated under certain conditions, etc. Although this is true, the same argument already applies to "your phone might be scanning all your photos and stealthily uploading them" -- Apple having announced this program doesn't seem to have changed the odds of that. At some point you have to trust yo…

Which is why I am confused by a lot of this backlash. Apple already controls the hardware, software, and services. I don't see why it really matters where in that chain the scanning is done when they control the entire system. If Apple can't be trusted with this control today, why did people trust them with this control a week ago?

[deleted]

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

#233
post #22

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

> And there is no way to audit that the database is what they claim it is, doesn't contain multiple databases that can be activated under certain conditions, etc. Although this is true, the same argument already applies to "your phone might be scanning all your photos and stealthily uploading them" -- Apple having announced this program doesn't seem to have changed the odds of that. At some point you have to trust yo…

What happens if someone tries to coerce Apple into writing backdoor code? Engineers at Apple could resist, resign, slow roll the design and engineering process. They could leak it and it would get killed. Things would have to get very very bad for that kind of pressure to work.

On the other hand, once Apple has written a backdoor enthusiastically themselves, it's a lot easier to force someone to change how it can be used. The changes are small and compliance can be immediately verified and refusal punished. To take it to its logical extreme: you cannot really fire or execute people who delay something (especially if you lake the expertise to tell how long it should take). But you can fire or execute people who refuse to flip a switch.

This technology deeply erodes Apple and its engineers' ability to resist future pressure. And the important bit here is there adversary isn't all powerful. It can coerce you to do things in secret, but its power isn't unlimited. See what happened with yahoo.[0]

https://www.reuters.com/article/us-yahoo-nsa-exclusive/exclu...

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

#234

> Apple generates the on-device perceptual CSAM hash database through an intersection of hashes provided by at least two child safety organizations operating in separate sovereign jurisdictions – that is, not under the control of the same government. Any perceptual hashes appearing in only one participating child safety organization’s database, or only in databases from multiple agencies in a single sovereign jurisdi…

well crap I just wrote a response lecturing you on the Five Eyes collusion before reading the last two lines of your post. :P

There exists a kind of sufficiently advanced stupidity that it can only be constructed by really smart people. People who are smart enough to rationalize doing something which is transparently wrong.

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

#235
post #159

Earlier quoted context omitted.

Lots of people have made policy arguments. No US law requires client side scanning. No US law forbids E2E encryption. US courts don't let law enforcement agencies just demand everything they want from companies. Apple relied on that 5 years ago successfully.[1] And capitulating preemptively is bad strategy usually. What Neuenschwander said doesn't establish it isn't just an arbitrary limitation. [1] https://en.wikipe…

That’s different. The FBI can legally require Apple or any other US company to search for specific files it has access to on it’s own servers because nothing currently shields backup providers. They could and did force Apple to aid in unlocking iPhones when Apple had that capacity. What they couldn’t do was “These orders would compel Apple to write new software that would let the government bypass these devices' secu…

Apple is a trillion dollar company with a lot of smart people. You could probably get them to design a system of N of M parts for recovery, or an apple branded key holder that you can store in your bank vault and friends houses. If they wanted to they'd do it.

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

#237
post #51
post #22

Earlier quoted context omitted.

> And there is no way to audit that the database is what they claim it is, doesn't contain multiple databases that can be activated under certain conditions, etc. Although this is true, the same argument already applies to "your phone might be scanning all your photos and stealthily uploading them" -- Apple having announced this program doesn't seem to have changed the odds of that. At some point you have to trust yo…

Which is why I am confused by a lot of this backlash. Apple already controls the hardware, software, and services. I don't see why it really matters where in that chain the scanning is done when they control the entire system. If Apple can't be trusted with this control today, why did people trust them with this control a week ago?

This is the conclusion that I personally arrived at. When I confronted some friends of mine with this, they gave me some good points to the contrary.

Letting Apple scan for government-related material on your device is a slippery slope to government surveillance and a hard line should be drawn here. Today, Apple may only be scanning your device for CSAM material for iCloud. Tomorrow, Apple may implement similar scanning elsewhere, gradually expand the scope of scanning to other types of content and across the entire device, implement similar government-enforcing processes on the device, and so on. It's not a good direction for Apple to be taking, regardless of how it works in this particular case. A user's device is their own personal device and anything that inches toward government surveillance on that device, should be stopped.

Another point made was that government surveillance never happens overnight. It is always very gradual. People don't mean to let government surveillance happen and yet it does because little things like this evolve. It's better to stop potential government surveillance in its tracks right now.

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

#238

Earlier quoted context omitted.

Is this really surprising to you? I'm not trying to be rude, but this is an enormous distinction. In today's world, smartphones are basically an appendage of your body. They should not work to potentially incriminate its owner.

They should not work to potentially incriminate its owner. But that ship has long sailed, right? Every packet that leaves a device potentially incriminates its owner. Every access point and router is a potential capture point.

When I use a web service, I expect my data to be collected by the service, especially if it is free of charge.

A device I own should not be allowed to collect and scan my data without my permission.

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

#239
post #227

Earlier quoted context omitted.

> Having said that, having heard from people who have investigated how bad pedophile activity actually is, I can imagine being easily persuaded back in the other direction. There are terrible things out there that we should seek to solve. They should not be solved by creating 1984 in the literal sense, and certainly not by the company that became famous for an advertisement based on that book [1]. Apple, take your ow…

> creating 1984 in the literal sense I take it you haven’t read 1984. When Craig Federighi straps a cage full of starving rats to my face, I’ll concede this point.

China has tiger chairs. Should we move closer to their big brother systems?

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

#240
post #229

Earlier quoted context omitted.

Let's not pretend anyone is really "opting in" on this feature.

Anyone who doesn’t like it can switch off iCloud Photo Library. I can imagine many people doing that in response to this news.

The fact that you can opt out for now does not set me at ease.
Post reply on HN