In theory this is meant to be one of the advantages of end to end encryption: no more "accidental" leakage of user data between users, leakage in logs, etc (remember Facebook's logging incident? [0]). as it's only available on end user devices. And if you look at Apple's documentation [1], they say that iCloud is end to end encrypted. This is obviously not accurate as Apple keeps decryption keys for themselves. But this issue is even worse: here, the end to end encryption was circumvented in such a bad way that this bug could surface.
One thing to remember is that end-to-end encryption comes with the very real possibility of complete and total loss of data, which is hard to stomach for someone’s entire photo library.
iMessage is end-to-end encrypted, but a key to decrypt messages is stored in iCloud backups.
Your statement is nonsensical. Either Apple has the key, or it's end to end encrypted. Both cannot be true. And in fact Apple has the key, even if you turned off iCloud backups in most cases since the person you're talking to probably has it enabled. Which makes the marketing misleading at best, and downright fraudulent at worst.
BTW both Apple and Google have a way of doing end to end encryption of backups with a recovery option in the case of device loss. Apple deliberately chooses not to enable it for iMessage and iCloud photos (it is used for keychain passwords among other things). Credible news reports state that Apple did this at the explicit request of the FBI. https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
Also note that Apple policies prohibit anyone else from offering cloud backups for iPhones, so you're SOL if you want cloud backups and privacy. Apple's way or the highway.
> Credible news reports state that Apple did this at the explicit request of the FBI.
A minor point of fact (I have posted this Reuters link more than anyone): a careful reading of the article does not specify an explicit request. It is very much implicit in the article. There is no direct reporting on the request itself.
It is obvious that there was an explicit request. The article simply strongly implies it, because Reuters will not report as fact things they can not verify.
Yes, I apologize for using the incorrect label. iMessage is not end-to-end encrypted for most people.
The point I was trying to make still stands. The recovery options are a form of key escrow. They require a recovery code. As I'm sure you know, if you lose your device and forget the recovery code, then it's total loss – the HSM will reset after a fixed number of tries. People are plenty capable of doing that, and with a billion devices, some non-trivial number of them do it regularly.
Plenty of people lose their devices but I question how many simultaneously forget their screen lock code that they enter literally every day. Of course anything that is possible will eventually happen given enough users. But that doesn't come close to justifying denying the rest of us the option and marketing it as end-to-end encrypted despite that.
Do you have any statement from Apple themselves or any indication that this was their line of thought? As far as I know, the on-device iMessage image scanning for CSAM (presumably what you are referring to) is a shipped feature live on all recent iOS builds, and I don't ever recall seeing any sort of public debate regarding whether iCloud photos should be encrypted or not (to be fair, before this thread, I assumed that they were).
Right, they say iMessage is end-to-end encrypted, but this is only true if you and the people you talk to don't use iCloud backups. If you do, then iMessage's E2E encryption silently degrades to key escrow.
I've read that Apple could technically inject a 3rd key in a two party chat and eavesdrop on it. Not sure how true that is in practice, but it seems plausible based on their security design document.
This is true. It's been proven to have happened in multiple court cases.
They can basically insert another "end" for the end to end encryption without any of the parties knowing.
You basically should never trust Apple / Google / Microsoft / Amazon / etc to handle your private information... ever. Use audited open-source messaging apps.
That article does not say what you claim it does. It’s about feds accessing imessage data via icloud backups, not by injecting keys to tap into conversations.
Using an “audited” app like signal on an iPhone still requires you to trust apple, because they could replace a library signal depends upon or they could just replace the whole app and you wouldn’t know. I also don’t know the extent to which we can verify that the app we get from the App Store is actually the audited version. I’ve always imagined signal could have secret code that gets included at compile time for certain platforms that could make it more vulnerable.
If we controlled all the code on our device and we could build the open source app ourselves that would go a long way. Otherwise you still have no choice but to trust your OS provider.
> You basically should never trust Apple / Google / Microsoft / Amazon / etc to handle your private information... ever. Use audited open-source messaging apps.
Nonsense. Understanding one’s own threat model is critical to deciding the acceptable amount of trust to place in these companies, but black and white thinking helps no one.
So could literally anyone who writes and distributes end-point software that encrypts and/or decrypts content (or hosts software that does) - including operating systems, browsers, e2e messaging apps, password managers, VPN clients, etc.
I believe solving this problem is the crux of the next major breakthrough (if it ever comes) in privacy and personal security. I'm not even sure a solution exists, but a lot can happen when smart people put their heads together on a seemingly intractable problem.
This happened to me during a Google Takeout export when I was degoogling in late 2019. I recall going through some photos from the earlier 2010's and some random pictures of other people were popping up. About a month or so later I received an email from Google letting me know that some of my files may have been accidentally in other people's exports. Since then, I stopped using apps like Google Photos and cloud storage in general. If I do, my files will be encrypted before I upload them.
I'm not surprised at all. I've reported literal malware in the App Store, with disassembly of the binary, etc. to them and Apple's "security" team did nothing. The inaction wasn't the worst part, it was their complete disinterest and lack of communication.
Google is even worse, you can't contact a human. Their app reporting process insisted I create a Google account and report it from within Android's App Store if I expected them to take action. I have better things to do than jump through unnecessary hoops.
Imagine getting still frames of somebody else's bedroom photos or kinky selfies sent to a partner or something similar rendered into your own video.
This could be very much like the technical cloud-based version of the fictional Tyler Durden splicing dick pics into single frames of 35mm film movies.
Based on what people use phones for these days some sizable percentage of icloud synced photos have to be something you really wouldn't want to get out there to random other icloud users.
Hm, what if you modified a CSAM video to evade detection (adversarial ML etc), then injected it onto the target's machine with this fun bug, then when the target's computer automatically creates a thumbnail for the video the thumbnail would be automatically flagged.
Holy heck this is a bad one. That response from the security team is completely unacceptable. I wonder if there's a way to force this to happen, e.g. by modifying the file contents directly.
Reminder: Photos and videos in iCloud are not end to end encrypted (just like your device backup that contains your iMessage "e2e" keys) and are always readable by Apple (and thus FBI et al).
Apple is required to hand over data without a search warrant over 30,000 times per year to US authorities.
The extra steps are having everyone else you iMessage with also turn off iCloud Backup.
Messages are all backed up twice by default: once from each device.
Turning off iCloud Backup is like migrating off of gmail to keep daddy G from reading your correspondence: it doesn't work when everyone else you correspond with is still being surveilled.
This kind of bug is unacceptable for a supposedly private cloud service. I wonder how long the bug has been around and whether it is at all related to the recent roll out of iCloud Shared Photo Library.
We have diluted the popular usage terminology so it's meaningless. Everyone ascribes the property "encrypted" to their service but you can't tell from that if they are just storing the key and the data next to each other in the database, or doing the equivalent with extra steps.
The important and hard part in crypto is key management, but that's considered too complicated a concept to explain to users.
From Reolink (all they do here is use a TLS connection):
"Your Privacy Is Our Top Priority
Security at the expense of privacy is not what we're committed to. Reolink Cloud collaborates with Amazon Web Services for secure data storage. Also, we use standard AES algorithm for data transmission encryption, use RSA/ECDHE algorithm for secure key exchange, and follow the TLS standards. When you save footage to Cloud or play clips back, your personal information is always kept confidential from beginning to end."
They can't even consider encrypting them, since they are forced to scan for CSAM and the public overwhelmingly rejected on-device scanning. So their server needs access to the images.
There is no evidence that iCloud was going to implement end-to-end encryption. This was a rumor that was spread by people who defended Apple's plan to implement on-device CSAM scanning.
I think this is one of the biggest unsolved problems with holding private keys. There needs to be some kind of recoverable key system (secret sharing) that is bulletproof and idiot proof. Hopefully something like that is possible!
Anyone else think the "scanlines" in the video are not scanlines but actually data of some sort? They seem to have white/black bits. Suggesting it might be some sort of data the video codec displays that way.
In a world of containers and micro services, I do not understand why we cannot have independent databases and buckets per user, specially if we are talking about sensitive data.
It looks like iCloud for Windows might remote-transcode HEVC down into a format that doesn't ask for a fee to be played back on that platform. In that case it's probably a good idea to stop using iCloud for Windows right now.
The encoder container / lambda would had been spawned for that particular user and it would have permissions to access only the content of that specific user.
There is absolutely no proof that these are images from other peoples iCloud accounts.
Assuming these are even from iCloud in the first place, they could have been their version of "stock photos".
Assuming these are from iCloud, could have been the user's previous deleted photos. Could also just be photos on their windows computer. So many options. Going straight for the most unlikely scenario is strange, and seems like people have an agenda.
Stock photos had crossed my mind as a possibility as well, but I'd say it's unlikely to be previously deleted photos or from their Windows computer if they're seeing photos of kids they don't know.
All I am saying is that this is a very serious security breach if true, and everyone in this thread is taking a forum post at face value. There are a hundred things that could "cause" this, even if true.
The data appears to be improperly handled personal info. There is no evidence suggesting that the photos are from a "used computer" and the photos are directly downloaded via the iCloud for Windows client.
I get the feeling that the folks working on the Windows/Android team at Apple are not highly regarded - get the sense of "folks working in the basement" - you can see it by the lackluster stuff they ship.
As a Windows/Android developer, you probably don't apply at Apple for a job, and as an Apple employee you're probably not too enamored with developing for Windows/Android.
Apple Music was Beats Music and iTunes just added cruft over the years and the Windows version was eventually added to the Windows Store with no improvement whatsever (podcasts was the last big upgrade).
Guess iTunes has been sunset and deprecated by Apple Music - who buys music tracks these days ???.
I must be the only oddball that still curates and listens to his music on a PC (Spotify).
All US operated websites are technically illegal in EU (due to the CLOUD Act). Practically, they are still used en masse. In theory the next iteration of the Privacy Shield (or whatever name they are going to give it this time around) and which EU-US should sign sometime next year should reconcile in some way the existing privacy issues where EU residents personal data does not have adequate privacy protection once it's touched by a US company.
I had another issue with iCloud and photo syncing being abysmally slow, and I ended up digging through LinkedIn and I found the director of engineering for photos at Apple. I messaged that person through LinkedIn, and ended up getting some very senior tech support people who helped go through my issues with me. I hesitate to post contact info, but just saying... it's possible if you are polite and can clearly articulate the issue to get someone like that to help really escalate the support.
If I upload photos on, say, icloud.com, it'll turn up on my devices days later.
In 2022, that shouldn't be categorised as merely slow when it is basically broken.
This is a well-known issue with thousands and thousands of posts on various forums, with the usual answers of "Have you tried turning it off and on again?".
The photo sync functionality is probably the most broken part of the Apple ecosystem that I've encountered, and this security issue just proves my suspicions.
[0]: https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...
[1]: https://support.apple.com/en-us/HT202303