Live data from Hacker News

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

arxiv.org

41–50 of 138 posts

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

#41
post #28
post #4

Earlier quoted context omitted.

While I don't like client-side scanning, that's overly reductive. "Client side scanning" (both in general, and in the recent Apple kerfuffle) is talking about a network client, that will be talking to servers that are owned by "them." If they wish to enforce rules over what is stored on their server then to enforce that right, the only two choices are to disallow E2EE or to perform client-side scanning. Really client…

> The Javascript that checks validity of forms before you submit them is a form of client-side scanning It is hardly difficult to draw a distinction between ensuring a field looks like an expected datatype and ML analysis guessing at photo content. In fact, trying to construct an argument conflating the two pretty much immediately runs in to the fact that one is adversarial, so it only works if you studiously ignore…

When you say "one is adversarial", I assume you mean that someone trying to upload illegal files will try to prevent the system from detecting that their files are illegal, while someone filling in a form isn't trying to sneak invalid data past the client-side validator (assuming all hackers know that the system is correctly implemented, i.e. the server performs its own validation).

The other distinction is, if a client-side form validator detects a problem with the input, it tells the user so they can fix it, whereas if Apple's system detects a problem with your input, it potentially tells the police without giving you a chance to delete the maliciously-generated false positive files you've unwittingly received.

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

#42
post #4
post #2

It's not their device to scan.

While I don't like client-side scanning, that's overly reductive. "Client side scanning" (both in general, and in the recent Apple kerfuffle) is talking about a network client, that will be talking to servers that are owned by "them." If they wish to enforce rules over what is stored on their server then to enforce that right, the only two choices are to disallow E2EE or to perform client-side scanning. Really client…

Just to be clear, is apple's icloud photo storage E2EE? From what I've been able to find it isn't, but I couldn't find anything official one way or the other from apple directly.

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

#45
post #28

Earlier quoted context omitted.

> The Javascript that checks validity of forms before you submit them is a form of client-side scanning It is hardly difficult to draw a distinction between ensuring a field looks like an expected datatype and ML analysis guessing at photo content. In fact, trying to construct an argument conflating the two pretty much immediately runs in to the fact that one is adversarial, so it only works if you studiously ignore…

When you say "one is adversarial", I assume you mean that someone trying to upload illegal files will try to prevent the system from detecting that their files are illegal, while someone filling in a form isn't trying to sneak invalid data past the client-side validator (assuming all hackers know that the system is correctly implemented, i.e. the server performs its own validation). The other distinction is, if a cli…

Yeah, 'adversarial' isn't exactly the right word; I'm not sure what is.

What I mean is that client side form validation is typically part of a cooperative process - I want to buy something at your store, you want to sell it to me, and smart client side validation can make that faster/easier if I typo something it can catch. It is (or at least should be) mostly aimed at helping the user; your parsing for security is (should be), as you note, on the server.

Scanning photos for [CSAM, thoughtcrime memes, poor taste, whatever] doesn't make the user's life easier, is not something anyone asked to be subjected to, and potentially can lead to a very negative outcome for them.

That's the distinction I was getting at, and yes, your second point is directly relevant there.

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

#46
post #43
post #23

Quite the roster of names behind the article.

The first name that stood out to me was Ron Rivest, of RSA, MD5, and public-key cryptography fame.

You skipped over Whitfield Diffie to find someone of public-key cryptography fame, lol. You might like his work too https://en.wikipedia.org/wiki/Whitfield_Diffie

Hal Abelson, first name there, is from the computer science classic SICP book/MIT lecture series - https://groups.csail.mit.edu/mac/classes/6.001/abelson-sussm...

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

#47

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. I have an iPhone. The Photos app keeps telling me that it's unable to upload things to iCloud because my account is full. I never turned it on. I never intended to upload any photos to the cloud. I haven't signed into my iCloud account…

Bullshit, Microsoft shoves that shit down people's throats. As an example of this, I never once opted into any kind of data sharing, set telemetry to the lowest allowed setting, and don't remember ever signing into a system-wide Microsoft account, yet when I eventually discovered deeply hidden privacy options I found that my MS account had a log of every single application I had ever used on my W10 laptop.

Where the "deeply hidden" options under Settings -> Privacy -> Activity History with "Jump back into what you were doing on your device by storing your activity history"?

It implements the feature of pressing Win+Tab to see open programs, and then scrolling down to see previously open programs.

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

#48

Earlier quoted context omitted.

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

There are other options.

For example, a full e2e encryption system where only the user owns the keys and nothing is scanned.

This is already possible today with any general purpose computer.

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

#49
post #4
post #2

It's not their device to scan.

While I don't like client-side scanning, that's overly reductive. "Client side scanning" (both in general, and in the recent Apple kerfuffle) is talking about a network client, that will be talking to servers that are owned by "them." If they wish to enforce rules over what is stored on their server then to enforce that right, the only two choices are to disallow E2EE or to perform client-side scanning. Really client…

> While I don't like client-side scanning, that's overly reductive.

No it isn’t. It’s my device. I get to decide what runs on it.

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

#50
post #42
post #4

Earlier quoted context omitted.

While I don't like client-side scanning, that's overly reductive. "Client side scanning" (both in general, and in the recent Apple kerfuffle) is talking about a network client, that will be talking to servers that are owned by "them." If they wish to enforce rules over what is stored on their server then to enforce that right, the only two choices are to disallow E2EE or to perform client-side scanning. Really client…

Just to be clear, is apple's icloud photo storage E2EE? From what I've been able to find it isn't, but I couldn't find anything official one way or the other from apple directly.

No, Apple’s iCloud storage isn’t E2EE. In fact a lot/most of their encryption appears sketchy, as they hold keys.
Post reply on HN