3 ms·

I didn't expect Apple to actually do this. Kudos. During the client-side scanning debacle I noted they'd have to implement server-side scanning anyway, so they

by yyyk 4y ago

I didn't expect Apple to actually do this. Kudos. During the client-side scanning debacle I noted they'd have to implement server-side scanning anyway, so they might as well abandon client-side scanning. The wording still allows for server-side scanning ("raw byte checksum" is vague enough be a image hash or merely a CRC-32; I strongly suspect it's the former) - and I'm perfectly fine with Apple choosing this. Their server their rules. It's also the better technical choice IMHO.

yamtaddle 4y ago
> ("raw byte checksum" is vague enough be a image hash or merely a CRC-32; I strongly suspect it's the former) 1) The image fingerprinting they were talking about before is really different from a "raw byte checksum", since it could recognize photos that had been resized or cropped. 2) AFAIK the plan was always to generate the fingerprint on the device, but to check it server-side, possibly as a pre-flight check before sending the actual file. The thing that upset people was the device generating a too-good fingerprint [EDIT: To be fair, people were also concerned Apple would expand the fingerprint-generating-and-uploading to photos that weren't bound for iCloud—the concern would have been pretty silly otherwise, since of course unencrypted photos sent to iCloud are CSAM-scanned, same as everywhere else). Pretty sure they were gonna keep the naughty-list server-side all along. So, if this is the same thing (I doubt it, see #1) then checking the fingerprints(/hashes) server-side isn't a change in plans.
- yyyk 4y ago
  1) I'm aware of the difference. However, I think the Apple phrase is sufficiently ambiguous to legally cover an image hash as well. An image hash is technically a checksum and is made of raw bytes that cannot be converted back to the image. If Apple is indeed using an image hash, I don't have a problem with this - it's their servers. 2) The fingerprint check was supposed to be done client-side based on a server supplied list so that Apple would not get the image and image hash unless there was a match (I'm simplifying this, there was a rather complex procedure involved with thresholds and manual review). My main concern was that normalizing and making possible client-side scanning would lead to other things being scanned. e.g. China adding images of Winnie the Pooh to scan list, and then sending every Chinese suspect to dissident-ville in the sky. The Apple plan here was insufficient: it wanted to rely on multi-country lists, this had both legal and practical problems - e.g. China has sufficient sway with friendly countries to add its choice of images to the list.
  - yamtaddle 4y ago
    Ah, thanks for the clarification, seems I was off on some of that. > My main concern was that normalizing and making possible client-side scanning would lead to other things being scanned. e.g. China adding images of Winnie the Pooh to scan list, and then sending every Chinese suspect to dissident-ville in the sky. Right, but that hardly mattered as long as it applied only to iCloud-uploaded files, since those were and are already being scanned so all those scenarios were already in play (well, not now, I suppose, if you enable encryption... maybe. But at the time they announced the scanning, certainly)
    - yyyk 4y ago
      >Right, but that hardly mattered as long as it applied only to iCloud-uploaded files There were some practical differences. e.g. Some programs have a permissive default of always marking as 'save to iCloud', and avoiding this can be nonintuitive. Also certain difficulties with deleted images which I am not sure how Apple had wanted to resolve but could lead to unfortunate differences from the other scenario. More importantly, the moment the client-side capability was there, legal pressure to use it in all cases was bound to come. Normalizing client-side scanning was also bound to legitimize and encourage doing the same on Android, and I can easily think of certain brands which are way less scrupulous than Apple. All in all, I didn't see the benefit given that server-side scanning was accepted as legitimate and sufficiently effective by just about everyone, but without the risks of client-side scanning.
      - yamtaddle 4y ago
        > All in all, I didn't see the benefit given that server-side scanning was accepted as legitimate and sufficiently effective by just about everyone, but without the risks of client-side scanning. Oh, absolutely—unless you want to prevent super-easy use for storing CSAM while also having E2E encrypted storage. Which I'm still nearly-certain was their entire reason for wanting to do that in the first place—which isn't to say there can't also be legitimate concerns about such functionality, I just don't think it was some kind of nefarious plot on their part. At this point I expect they're sitting on the feature until or unless there's public outrage over their inability to provide evidence in some kind of CSAM case or investigation—if that doesn't happen, fine, if it does, they'll push it out as soon as that sentiment overwhelms the anti-scanning one.

by yyyk 4y ago

yamtaddle 4y ago

> ("raw byte checksum" is vague enough be a image hash or merely a CRC-32; I strongly suspect it's the former) 1) The image fingerprinting they were talking about before is really different from a "raw byte checksum", since it could recognize photos that had been resized or cropped. 2) AFAIK the plan was always to generate the fingerprint on the device, but to check it server-side, possibly as a pre-flight check before sending the actual file. The thing that upset people was the device generating a too-good fingerprint [EDIT: To be fair, people were also concerned Apple would expand the fingerprint-generating-and-uploading to photos that weren't bound for iCloud—the concern would have been pretty silly otherwise, since of course unencrypted photos sent to iCloud are CSAM-scanned, same as everywhere else). Pretty sure they were gonna keep the naughty-list server-side all along. So, if this is the same thing (I doubt it, see #1) then checking the fingerprints(/hashes) server-side isn't a change in plans.

yyyk 4y ago
1) I'm aware of the difference. However, I think the Apple phrase is sufficiently ambiguous to legally cover an image hash as well. An image hash is technically a checksum and is made of raw bytes that cannot be converted back to the image. If Apple is indeed using an image hash, I don't have a problem with this - it's their servers. 2) The fingerprint check was supposed to be done client-side based on a server supplied list so that Apple would not get the image and image hash unless there was a match (I'm simplifying this, there was a rather complex procedure involved with thresholds and manual review). My main concern was that normalizing and making possible client-side scanning would lead to other things being scanned. e.g. China adding images of Winnie the Pooh to scan list, and then sending every Chinese suspect to dissident-ville in the sky. The Apple plan here was insufficient: it wanted to rely on multi-country lists, this had both legal and practical problems - e.g. China has sufficient sway with friendly countries to add its choice of images to the list.
- yamtaddle 4y ago
  Ah, thanks for the clarification, seems I was off on some of that. > My main concern was that normalizing and making possible client-side scanning would lead to other things being scanned. e.g. China adding images of Winnie the Pooh to scan list, and then sending every Chinese suspect to dissident-ville in the sky. Right, but that hardly mattered as long as it applied only to iCloud-uploaded files, since those were and are already being scanned so all those scenarios were already in play (well, not now, I suppose, if you enable encryption... maybe. But at the time they announced the scanning, certainly)
  - yyyk 4y ago
    >Right, but that hardly mattered as long as it applied only to iCloud-uploaded files There were some practical differences. e.g. Some programs have a permissive default of always marking as 'save to iCloud', and avoiding this can be nonintuitive. Also certain difficulties with deleted images which I am not sure how Apple had wanted to resolve but could lead to unfortunate differences from the other scenario. More importantly, the moment the client-side capability was there, legal pressure to use it in all cases was bound to come. Normalizing client-side scanning was also bound to legitimize and encourage doing the same on Android, and I can easily think of certain brands which are way less scrupulous than Apple. All in all, I didn't see the benefit given that server-side scanning was accepted as legitimate and sufficiently effective by just about everyone, but without the risks of client-side scanning.
    - yamtaddle 4y ago
      > All in all, I didn't see the benefit given that server-side scanning was accepted as legitimate and sufficiently effective by just about everyone, but without the risks of client-side scanning. Oh, absolutely—unless you want to prevent super-easy use for storing CSAM while also having E2E encrypted storage. Which I'm still nearly-certain was their entire reason for wanting to do that in the first place—which isn't to say there can't also be legitimate concerns about such functionality, I just don't think it was some kind of nefarious plot on their part. At this point I expect they're sitting on the feature until or unless there's public outrage over their inability to provide evidence in some kind of CSAM case or investigation—if that doesn't happen, fine, if it does, they'll push it out as soon as that sentiment overwhelms the anti-scanning one.