6 ms·

Sure, but I don't expect it from third party cloud platforms - in the same way I wouldn't expect accountability from a garbage man who reports to the police aft

Sure, but I don't expect it from third party cloud platforms - in the same way I wouldn't expect accountability from a garbage man who reports to the police after finding evidence of crime in my garbage. Apple is, for some insane reason, trying to establish the precedent that the contents of your Apple product are now part of the public space - where expectation of privacy isn't a thing.

azinman2 5y ago
But that isn’t true. This is only photos uploaded to iCloud.
- sennight 5y ago
  Why would you lie about something so easily disproven? "Instead of scanning images in the cloud, the system performs on-device matching..." https://www.apple.com/child-safety/ https://www.apple.com/child-safety/
  - azinman2 5y ago
    Lie? I don't take kindly to such words, because you're ascribing malicious intent where there is none. Please check your tone... HN comments are about assuming the best in everyone. This is only applying to photos uploaded to iCloud. Every single thing talks exactly about that, including the technical details: https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni... The hash matching is occurring on device, but only for iCloud photo images: > Before an image is stored in iCloud Photos, an on-device matching process is performed for that image against the database of known CSAM hashes. This matching process is powered by a cryptographic technology called private set intersection, which determines whether there is a match without revealing the result. The device creates a cryptographic safety voucher that encodes the match result. It also encrypts the image’s NeuralHash and a visual derivative. This voucher is uploaded to iCloud Photos along with the image. Read that PDF. You'll see everything in it is designed for iCloud photos only.
    - sennight 5y ago
      > Lie? I don't take kindly to such words, because you're ascribing malicious intent where there is none. Howdy partner, it seems my tone communicated the sentiment as intended. It is unreasonable to ascribe anything but malice in this case, because the rationale strains credulity. Do you know at what point Apple is determining your intent to sync photos? What processes, exactly, are they hooking into in order to trigger the local hash functionality? Is it the resource hogging Photos-Agent frequently complained about? Is this thresholding functionality restricted to cloud content, or is the local database mentioned involved? Does that local database only relate to images uploaded to the cloud, and how would the deletion of local and/or cloud content influence that? These are all questions that are either unaddressed, provide no assurance beyond "trust us", or hint at logical conflicts between the stated purpose of local scanning and the actual implementation details. With all that in mind, granting Apple and its defenders the benefit of doubt is laughably foolish.
  - simondotau 5y ago
    It is not a lie. The scanning is done on device, but photos are not scanned unless they are going to be uploaded to iCloud. Apple has explicitly stated this.
    - sennight 5y ago
      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.
- noptd 5y ago
  And all it would take is a confidential change in policy before all photos are scanned, and the same "save the children" argument would be used to save face if the decision ever leaks. "Pedophiles are taking pornographic photos of kids on their phones and then sharing them outside of iCloud. But wait, you don't want us to compare each photo you capture against ML models capable of identifying child porn? Why are you defending and siding with pedophiles?" The only surefire way to avoid a slippery slope is to keep away from the edge.

azinman2 5y ago

But that isn’t true. This is only photos uploaded to iCloud.

sennight 5y ago
Why would you lie about something so easily disproven? "Instead of scanning images in the cloud, the system performs on-device matching..." https://www.apple.com/child-safety/ https://www.apple.com/child-safety/
- azinman2 5y ago
  Lie? I don't take kindly to such words, because you're ascribing malicious intent where there is none. Please check your tone... HN comments are about assuming the best in everyone. This is only applying to photos uploaded to iCloud. Every single thing talks exactly about that, including the technical details: https://www.apple.com/child-safety/pdf/CSAM_Detection_Technical_Summary.pdf https://www.apple.com/child-safety/pdf/CSAM_Detection_Techni... The hash matching is occurring on device, but only for iCloud photo images: > Before an image is stored in iCloud Photos, an on-device matching process is performed for that image against the database of known CSAM hashes. This matching process is powered by a cryptographic technology called private set intersection, which determines whether there is a match without revealing the result. The device creates a cryptographic safety voucher that encodes the match result. It also encrypts the image’s NeuralHash and a visual derivative. This voucher is uploaded to iCloud Photos along with the image. Read that PDF. You'll see everything in it is designed for iCloud photos only.
  - sennight 5y ago
    > Lie? I don't take kindly to such words, because you're ascribing malicious intent where there is none. Howdy partner, it seems my tone communicated the sentiment as intended. It is unreasonable to ascribe anything but malice in this case, because the rationale strains credulity. Do you know at what point Apple is determining your intent to sync photos? What processes, exactly, are they hooking into in order to trigger the local hash functionality? Is it the resource hogging Photos-Agent frequently complained about? Is this thresholding functionality restricted to cloud content, or is the local database mentioned involved? Does that local database only relate to images uploaded to the cloud, and how would the deletion of local and/or cloud content influence that? These are all questions that are either unaddressed, provide no assurance beyond "trust us", or hint at logical conflicts between the stated purpose of local scanning and the actual implementation details. With all that in mind, granting Apple and its defenders the benefit of doubt is laughably foolish.
- simondotau 5y ago
  It is not a lie. The scanning is done on device, but photos are not scanned unless they are going to be uploaded to iCloud. Apple has explicitly stated this.
  - sennight 5y ago
    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.
noptd 5y ago
And all it would take is a confidential change in policy before all photos are scanned, and the same "save the children" argument would be used to save face if the decision ever leaks. "Pedophiles are taking pornographic photos of kids on their phones and then sharing them outside of iCloud. But wait, you don't want us to compare each photo you capture against ML models capable of identifying child porn? Why are you defending and siding with pedophiles?" The only surefire way to avoid a slippery slope is to keep away from the edge.