EFF Joins Global Coalition Asking Apple CEO Tim Cook to Stop Phone-Scanning

I vehemently disagree that a feature could be classed as spyware if it clearly and unambiguously declares exactly what it's going to do prior offering a choice whether or not to do it. By that logic, the mere presence of a "report phishing" button in any cloud email service would be sufficient to declare it as spyware.

But fine, whatever. You're welcome to call any form of parental oversight of a child below the age of thirteen "spyware" if you like, so long as you accept that it's entirely my choice as a parent. This feature isn't on by default. If your opinions as a parent are different, don't turn it on. It's not your place to deny me access to this opt-in tool which can help keep my child safe.

... that don't address implementation details - like what background processes get hooked into for hash generation and under what circumstances. They are also relying very heavily on secrecy, the secret local db being a good example. Why does that matter? Because their assurances against false positives depend on you assuming that the threshold counter only applies to content being flagged with a reasonably low rate of false positives and subsequently stored on their cloud, which permits additional safety assuring verification steps - and I don't see any reason why you should assume that.

> Have you read them?

I have.

> Are you claiming that Apple is lying?

Yes, but not about their intent (which I don't really care about, and is immaterial anyway) - they are lying about their ability to execute the program as they've described. Take for example their hybrid perceptual algorithm approach, which supposedly provides some increased measure of protection against adversarial attacks. We know for a fact that their primary algo is hopelessly vulnerable to hash length extension attacks, which makes the generation of false positives trivial. The second algo that supposedly addresses that is a secret, which should immediately raise red flags for anyone familiar with infosec. But I wouldn't be surprised if that safety turns out to be Microsoft's PhotoDNA - because it is already commonly used in the CP cataloging realm, and Apple would have more than one reason to not want to advertise something like that. First, PhotoDNA is a blackbox that has no independently conducted research available for public scrutiny. Second, it would mean they designed their system totally backwards - as PhotoDNA employs a high pass filter to guard against extension attacks, but at this point in the flagging process (as Apple has described) that filtering protection can't be employed to guard against extension attacks... so it provides no additional protection to speak of. Third, it was invented by a competitor.

> ...hasn't been lying about your data security for the past decade.

You are forgetting about all the cries for not ascribing malice to stupidity, and how this case involves a very different kind of cover for action. When calc.exe sends tiny encrypted fragments to telemetry.microsoft.com and it has no means of using a hidden channel to receive anything outside of itself - I'm irritated, but not alarmed. When PhotoAgent is chilling in the background - occasionally opening a RW handle to some persistent encrypted db, a db that also gets opened by another process prior to establishing a network connection to thinkofthechildren.apple.com, I become suspicious.

> If your contention is that Apple might turn evil in the future...

My contention is that they can't avoid making mistakes, and that assurances addressing concerns related to consequence of said mistakes depend entirely upon secrecy. History has shown how relying on secrecy and infallibility plays out, Apple's defenders are ignoring that.

“ The Australian Telecommunications and Other Legislation Amendment (Assistance and Access) Act 2018 (TOLA) allows government agencies to issue “technical assistance” and “technical capability” notices to providers of communications services. The notices require that the providers give the authorities help in conducting criminal enforcement intercepts, and that they make changes in their systems to ensure that they can give that help.”

…

“In any event, the FBI chose a curiously roundabout way of getting access to ANOM messages. For ANOM devices operating outside of the United States, “an encrypted [blind carbon copy or BCC]” of each message that a user sent was transmitted to a server located outside of the United States, which then decrypted and reencrypted the message with an encryption key known to the FBI. Those reencrypted messages were sent to another server that was owned by the FBI, outside of the United States.

In the summer of 2019, the FBI started negotiating to build the legal structure that would make this technical architecture work. In essence, the FBI went looking for a third country that would host the BCC server and could lawfully accept all of the decrypted messages and send the copies to the FBI. As the affidavit notes, “Unlike the Australian beta test, the third country would not review the content in the first instance.” This would have been a fascinating negotiation. Both participants wanted to make criminal cases and avoid privacy scandals. The U.S. would want to be sure that the third country had full legal authority to intercept the contents of every ANOM message, and that the country was also willing to share the full ANOM take with the U.S. in something like real time.”