zimmie

dcgoo said:

Agree! What is the difference between already existing VPN services and Apple Private Relay?

Difference is Private Relay only applies to traffic from the Safari browser.  A VPN would apply to the entire device.

ravnorodom said:

This is where chip makers need to step in and work with universities or institutions. Many big corporations donate equipments to schools for training, research and hiring after graduation. Establishing mini or virtual chip fabrication lab in University maybe tough but something is needed to be done.

chris-net said:

are other browsers or applications like chrome, Firefox, games able to use private relay?

exceptionhandler said:

zimmie said:

exceptionhandler said:

badmonk said:

I suspect CSAM screening will ultimately be performed and confined iCloud server side, like every other cloud based service has been doing for years (and not talked about it).

I always thought iCloud screened for CSAM, after all MSFT and Google have been doing it for years.

Freedom has its limits.

I think they’ve always been scanning iCloud photos and reporting on the server side.  I think someone previously linked to a document that states so.  So the claims about protecting peds is unwarranted, because it will still be done on the server side.  What apple was trying to do was impose/move their house rule (server side) into our houses (iPhones) for whatever reason.

I see no reason for the move.  As some people have previously stated, “maybe Apple is going to e2e encrypt iCloud photos”.  The rub here is that it would not be e2e encrypted either way.  Scanning and reporting necessitates access to the data. E2E encryption is only E2E encryption IFF there is no process to circumvent it (including at either end) to send the data to someone else outside of the authorized recipients intended by the sender.  This very fact alone means that iCloud photos will never be e2e encrypted as Apple needs to do CSAM scanning.

So all things stated, I’m fine with the current state of server side scanning as it’s not on my device and the only way the scanning and reporting applies is IFF you use the service (some may argue that’s the way it would work on device, but that is subject to change, whereas if it’s on the server, they can’t make that change to scan more than what’s sent to iCloud)

The proposed on-device CSAM scanning intrinsically involves end-to-end encryption. The whole point is to allow your device to encrypt photos with a key which Apple doesn't hold. If it detects CSAM, it also uploads partial directions on how to find the key. Once enough partial directions are uploaded, they can be used to find the key to decrypt the images, but Apple doesn't have the key until then. They also can't create the partial directions on their own.

To protect against one of those partial directions being used as evidence of possession, they also set the system up to emit fake partial directions which are indistinguishable from real ones until after you have uploaded enough real ones.

The clear solution is to spin all of the iCloud-related functionality out of Photos and into a separate application. CSAM scanning then goes in that application. If you want to upload stuff to iCloud, you need that application, which has the CSAM scanning. If you don't want the CSAM scanning, don't load the application (or remove it if it comes preinstalled). Done. Addresses everybody's concerns.

It’s not intrinsic, the encryption used as a veil of protection.  I get that it’s theoretically impossible to decrypt the offending files until a threshold is met, but in order to report those images, it necessarily circumvents the E2E process between the normal intended sender and receiver(s), to send them for review at Apple and authorities.  Yes, the process heavily relies on encryption methods, but allows for another originally unintended party to be involved.  True E2E encryption means only specified sender and receiver have access to the information (but you still have to trust those involved not to reshape it).  Top it off, it’s on device, where it’s easier to “expand” functionality to include other things, whereas when it’s in the service, it’s physically unable to access anything on device unless it’s sent (hopefully over ssl) or already stored in the service.

exceptionhandler said:

badmonk said:

I suspect CSAM screening will ultimately be performed and confined iCloud server side, like every other cloud based service has been doing for years (and not talked about it).

I always thought iCloud screened for CSAM, after all MSFT and Google have been doing it for years.

Freedom has its limits.

I think they’ve always been scanning iCloud photos and reporting on the server side.  I think someone previously linked to a document that states so.  So the claims about protecting peds is unwarranted, because it will still be done on the server side.  What apple was trying to do was impose/move their house rule (server side) into our houses (iPhones) for whatever reason.

I see no reason for the move.  As some people have previously stated, “maybe Apple is going to e2e encrypt iCloud photos”.  The rub here is that it would not be e2e encrypted either way.  Scanning and reporting necessitates access to the data. E2E encryption is only E2E encryption IFF there is no process to circumvent it (including at either end) to send the data to someone else outside of the authorized recipients intended by the sender.  This very fact alone means that iCloud photos will never be e2e encrypted as Apple needs to do CSAM scanning.

So all things stated, I’m fine with the current state of server side scanning as it’s not on my device and the only way the scanning and reporting applies is IFF you use the service (some may argue that’s the way it would work on device, but that is subject to change, whereas if it’s on the server, they can’t make that change to scan more than what’s sent to iCloud)