Earlier quoted context omitted.
The first name that stood out to me was Ron Rivest, of RSA, MD5, and public-key cryptography fame.
Also Whitfield Diffie, of Diffie-Hellman fame.
His partner went on to make some pretty good mayonnaise, too!
Bugs in our pockets: the risks of client-side scanning
61–70 of 138 posts
Re: Bugs in our pockets: the risks of client-side scanning
#62On 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…
Looking forward to the day that people publicly argue for client-side scanning on NeuralinkOS for thought-crime.
Re: Bugs in our pockets: the risks of client-side scanning
#63“It’s not perfect yet, so let’s not do it” is not much of an argument, especially from cryptography wonks with no experience in public policy or law enforcement.
Schneier at least has substantial experience and analysis on public policy - his "Beyond Fear" book published over a decade ago is one example.
Re: Bugs in our pockets: the risks of client-side scanning
#64Earlier quoted context omitted.
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...
> You skipped over Whitfield Diffie
don't forget Steven M. Bellovin who's on that list and who was one of the inventors of the first Encrypted Key Exchange, a precursor to the Diffie-Hellman Key Exchange.
Re: Bugs in our pockets: the risks of client-side scanning
#65Earlier 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…
There's nothing better than knowing everything and never having to play around with settings to discover what they do, never forgetting what you've set your settings to, and not having children, family members, or friends do the same. There's no way any reasonable person could ever have their uploads accidentally turned on without their full knowledge and consent so that definitely invalidates any reason to argue aga…
With server side scanning, if someone accidentally enables uploading you are in exactly the same position. It being enabled on upload, which side it runs changes nothing in all the scenarios you are sarcastically ranting about.
Re: Bugs in our pockets: the risks of client-side scanning
#66It'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…
> "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.
So the core of the problem is that they want to enforce rules over what is stored on their servers, even in E2EE form. They could just allow regular E2EE, where they ignore the content that they don't know and push back against politicians who think they are entitled to all data. They chose to push back against user's privacy instead.
What if I have a file on my phone that is already encrypted before I upload it to icloud and it gets encrypted a second time? Apple would have no knowledge about its content. Would they have to scan all my other devices too?
Re: Bugs in our pockets: the risks of client-side scanning
#67Eventually we’ll see cryptographic attestation of open source binaries on our phones. Until then, all popular phones will run closed source software, and it will be necessary to trust the vendor. Even then, the vendor may also be the chip maker. Apple would do well to look at sourcing an independent chip vendor for their on-device enclaves. That would give them a trust advantage over Android phones.
> Eventually
This is far from a given.
Re: Bugs in our pockets: the risks of client-side scanning
#68Given how the average person and even the majority of people on tech have been acting the last 6 years I'm at the point where I don't care. I can protect myself, everyone else is their own responsibility.
The more we remove privacy by tech the less we lose it by law which I now think is the much worse outcome.
Re: Bugs in our pockets: the risks of client-side scanning
#69Earlier 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.
Apple develops a phone operating system and sells phones that run that operating system. What does it even mean to say “if Apple had no access to the user’s device”?
Yes, Apple is also the OS vendor. What it would mean to say "Apple has no access to the user's device" is, whatever an average, unsophisticated user understands it to mean -- because their informed consent is ethically all that matters here.
It means precisely that Apple has no technical capability to remotely access the device.
It means any (consented) Apple software update leaves behind no hooks or backdoors that enable subsequent, remotely-initiated access.
It means there verifiably exist no code paths that allow remote exfiltration of data, other than those that pass through consent dialogs. The basic distinction between legitimate OS functionality, and malware.
Re: Bugs in our pockets: the risks of client-side scanning
#70Given how the average person and even the majority of people on tech have been acting the last 6 years I'm at the point where I don't care. I can protect myself, everyone else is their own responsibility. The more we remove privacy by tech the less we lose it by law which I now think is the much worse outcome.
> The more we remove privacy by tech the less we lose it by law
On its face, that seems like a false dichotomy. Can you expand?
Generally, I see the erosion of our right against unreasonable search and seizure to be something that hurts everyone (regardless of an individual's ability to make fewer searchable spaces).