4 ms·

Oh, well if Apple says... I'm sure their statement somehow completely aligns with all the potentially conflicting interpretations one can draw from their PR, th

Oh, well if Apple says... I'm sure their statement somehow completely aligns with all the potentially conflicting interpretations one can draw from their PR, their stated objectives, and the implementation details observed, and it always will - forever.

simondotau 5y ago
Apple has released fairly detailed technical summaries of their system, far beyond what could be hidden behind "conflicting interpretations" of material written by a PR department. Have you read them? Are you claiming that Apple is lying? If your contention is that Apple is lying now, then you have no reason to think Apple—or any other corporation for that matter—hasn't been lying about your data security for the past decade. Who knows, maybe Google Chrome is sending everyone's passwords in plain text to the NSA. If your contention is that Apple might turn evil in the future, that charge could be levied against against any other company at any time. It's functionally unfalsifiable.
- sennight 5y ago
  > Apple has released fairly detailed technical summaries of their system... ... 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.

simondotau 5y ago

Apple has released fairly detailed technical summaries of their system, far beyond what could be hidden behind "conflicting interpretations" of material written by a PR department. Have you read them? Are you claiming that Apple is lying? If your contention is that Apple is lying now, then you have no reason to think Apple—or any other corporation for that matter—hasn't been lying about your data security for the past decade. Who knows, maybe Google Chrome is sending everyone's passwords in plain text to the NSA. If your contention is that Apple might turn evil in the future, that charge could be levied against against any other company at any time. It's functionally unfalsifiable.

sennight 5y ago
> Apple has released fairly detailed technical summaries of their system... ... 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.