Live data from Hacker News

Bugs in our pockets: the risks of client-side scanning

arxiv.org

31–40 of 138 posts

Re: Bugs in our pockets: the risks of client-side scanning

#31
post #7
post #6

Earlier quoted context omitted.

Client side scanning of inappropriate pictures is of content you'd ordinarily be sending them as anyways as well. The proposal was only to do this if cloud services were/are enabled.

A significant number of concerns aren't about the feature as proposed by Apple, but the slippery slope it creates.

True but slippery slopes are simply a thing. Like the Overton window. Every move takes a step further and moves something else from ridiculous into feasible.

And personally, I know this won't affect me. I don't own such content. I don't use the cloud without encryption first (thanks Cryptomator). However I just hate the feeling of my own phone constantly looking over my shoulder on someone else's behalf. Is that so weird?

Re: Bugs in our pockets: the risks of client-side scanning

#32
post #16

Earlier quoted context omitted.

But none of these conundrums could exist if Apple had no access to the user's device, nor control over the software running on it. "Who owns your computer" is still the central question; we're just Sapir-Whorfing ourselves around it within the implicit language of walled gardens. "Apple owns your computer" is the unspoken premise, and it's not axiomatic. Stallman was very, very right.

There's a huge tangle of things with "Apple owns your computer" but I don't think most of it applies to the icloud question. If you wanted to store photos in icloud on a Windows machine, you'd be using the Apple icloud client. Apple has at least some control over what software they write and ship does[1]. They can break 3rd party clients almost at will, so if they choose to be hostile to 3rd party clients that contro…

[deleted]

Re: Bugs in our pockets: the risks of client-side scanning

#33

Earlier quoted context omitted.

Maybe. I'm very anti-cloud from the first moments I ever heard of it and saw the first puffy shapes in slide decks. I don't trust it. It's not in my control and I don't know who does control it. That scares the bejeebus out of me. I'm not the unsuspecting dupe that devs are targeting to get a new user tricked into something. I'm very much aware of the shenanigans devs try and pay attention to that shit from the go. H…

It's not even the devs in general. It's their management and bean counters. Data is money. And yeah.. The cloud is just someone else's computer. Would you store all your stuff on your friend's computer? Well most people store everything they have on the computers of people they don't even know...

Thank gawd we don't make decisions on what most people do...hrmph

Re: Bugs in our pockets: the risks of client-side scanning

#34
post #15

Earlier quoted context omitted.

I've had an iDevice since 2007. I've never signed up for the paid iCloud. I get the standard 5GB plan that all Apple accounts receive. I have never accidentally uploaded a photo to it. I have never enabled it. I don't understand how your situation happens as it has never happened to me. It makes no sense other than someone (maybe you forgot, a significant other, a kid) played around with some settings? There's no oth…

> since 2007 I'm speculating here, but I wonder if part of your experience is based on the fact that you're a long time user. Features like auto-uploading to Photo Library are new, and Apple is generally decent about informing you of new features before opting in. Brand new account setups are a different story. You're encouraged to use all of the latest/greatest stuff (and why not, current topic notwithstanding?). Bo…

[deleted]

Re: Bugs in our pockets: the risks of client-side scanning

#35
post #25

On the other hand, CSS might -- eventually, anyway -- offer the best compromise for facilitating reliable, responsible lawful access to mass consumer information technology. Develop CSS in a manner that minimizes the noted risks. Such mechanisms are a fundamental compromise, philosophically. I am skeptical that those on opposing ends of the privacy debate will find sufficient common ground to achieve responsible impl…

> Develop CSS

No, do not. There is no reasonable privacy preserving manner in which you can do so. Spyware is fundamentally incompatible with privacy. I don't care how many god damn whitepapers they write about their novel perceptual hash cohort-based homomorphic 0-trust TPM scanner. It's still a rat.

Re: Bugs in our pockets: the risks of client-side scanning

#36
post #13

Earlier quoted context omitted.

> If they wish to enforce rules over what is stored on their server The whole point of end-to-end encryption is that what is stored on their server is statistically uniform binary white noise. If they wish to enforce that, there are a plethora of server-side tools (like the Diehard test suite) with which to do so.

You are completely correct from a computer science perspective - unfortunately, this is not a computer science discussion. As far as the FBI are concerned, “storing encrypted child porn on behalf of people with the keys to decrypt it” still counts as “storing child porn”. You can disagree with that (and there are many good reasons to do so) - but “it’s encrypted so it’s fine” isn’t going to convince anybody who matte…

In the US, a service provider incurs legal obligations when it has actual knowledge that it is hosting something that appears to be CSAM. A provider hosting encrypted data with no knowledge of what it decrypts to does not have such obligations.

https://www.law.cornell.edu/uscode/text/18/2258A

Re: Bugs in our pockets: the risks of client-side scanning

#37
post #25

On the other hand, CSS might -- eventually, anyway -- offer the best compromise for facilitating reliable, responsible lawful access to mass consumer information technology. Develop CSS in a manner that minimizes the noted risks. Such mechanisms are a fundamental compromise, philosophically. I am skeptical that those on opposing ends of the privacy debate will find sufficient common ground to achieve responsible impl…

> Develop CSS No, do not. There is no reasonable privacy preserving manner in which you can do so. Spyware is fundamentally incompatible with privacy. I don't care how many god damn whitepapers they write about their novel perceptual hash cohort-based homomorphic 0-trust TPM scanner. It's still a rat.

What about in the Apple case where:

- The alternative is hold the keys to your photo library and scan the entire thing (like google photos)

vs

- Don't hold the keys but do CSS, that then on a positive provides partial keys to partial data.

That feels like a better trade off. But I can see that it could be the slippery slope towards broader CSS...

Re: Bugs in our pockets: the risks of client-side scanning

#38
post #2

It's not their device to scan.

Sure, but it's their software that you are 'licensed' to use under their conditions. So sure, the silicon is yours, but the bits on it are merely licensed for use by you.

Not saying I agree with this status quo. But it's not ambiguous.

Re: Bugs in our pockets: the risks of client-side scanning

#39
post #25

On the other hand, CSS might -- eventually, anyway -- offer the best compromise for facilitating reliable, responsible lawful access to mass consumer information technology. Develop CSS in a manner that minimizes the noted risks. Such mechanisms are a fundamental compromise, philosophically. I am skeptical that those on opposing ends of the privacy debate will find sufficient common ground to achieve responsible impl…

> Develop CSS No, do not. There is no reasonable privacy preserving manner in which you can do so. Spyware is fundamentally incompatible with privacy. I don't care how many god damn whitepapers they write about their novel perceptual hash cohort-based homomorphic 0-trust TPM scanner. It's still a rat.

As another poster said, it's not a choice of whether or not your content is scanned; it's a choice of where. If you upload pictures to the cloud—which is the only scenario in which Apple's scanning was stated to happen¹—then it's a choice between scanning on your device, which allows for the possibility of E2E encryption, or definitely no encryption and scanning on the server.

At present, Apple doesn't scan photos on the server, but all their competitors do, and I don't doubt for a second that they will eventually start scanning photos as well. The choice is not if, but how, and their client-side solution seems to me to be much more privacy-preserving than server-side scanning.

¹If you don't believe them, that's fine, but given that they have root control over the software running on your phone, your only choice is to either believe them or don't use their phones. Same goes for all other phones.

Re: Bugs in our pockets: the risks of client-side scanning

#40
post #21
post #13

Earlier quoted context omitted.

You are completely correct from a computer science perspective - unfortunately, this is not a computer science discussion. As far as the FBI are concerned, “storing encrypted child porn on behalf of people with the keys to decrypt it” still counts as “storing child porn”. You can disagree with that (and there are many good reasons to do so) - but “it’s encrypted so it’s fine” isn’t going to convince anybody who matte…

I agree with you, but if the FBI wanted to serve a warrant to search my device, they can compel me to do so. Failure to unlock that device could put you into jail until you comply with the warrant.

US case law is not settled on that matter, and some courts have concluded that disclosing a password is testimonial and therefore covered by the fifth amendment. Courts that have ruled the other way have usually done so under narrow exceptions.
Post reply on HN