Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Microsoft, Google, and Apple are all participants in the PRISM program, which provides data to the US federal government without a warrant (FBI and military intelligence) under the authority they claim via FISA Amendments Act Section 702. Edward Snowden is the reason we know about this.

https://www.eff.org/702-spying

Any data you provide to any of those companies (or any others that have been added in the time since, which presumably includes Dropbox and AWS) that is not end to end encrypted should be considered compromised by the state, or able to be compromised by the state at any time the moment they want to look. (PRISM is not mass surveillance, they specify the accounts they want data for.)

As far as the other apps go, you can watch it yourself. Install the iOS app called Charles Proxy, and you can see all of the hidden connections that apps are making.

Alternately, install NextDNS, and make sure your custom configuration settings (on their setup portal) is set to retain logs for a few hours. You’ll be able to see all of the different hostnames to which your phone connects.

I have stopped using iCloud, and only use Google for YouTube (or corporate/work stuff, for which I have no special desire for privacy from the state). I give my clients the option, though, if they wish to use a different method of collaboration.



The spying thing is a problem with US gov. Why are you dinging Apple for that? In fact, Apple refused to unlock the phone when FBI requested for the famous shooting case (I forgot). Others do the same - Google, Facebook, Microsoft, etc. Apple is complying to the law.

Also, Apple is putting encryption in hardware to prevent this sort of a thing. They don't have keys to the device.


Google implemented end-to-end encrypted backups for Android devices, which prevents the government from getting anything useful when they pull the device’s backed up data from Google.

Apple does not implement end-to-end encryption for their backups, which is why I’m “dinging” them. The iCloud device backups that happen each night on the device are backed up with Apple keys, which means that Apple can decrypt your entire message history for the device, without the device. iCloud Backup is on by default for every iPhone and iPad, which it is not inaccurate to describe as an effective cryptographic backdoor in iMessage’s end-to-end encryption, because it escrows the iMessage keys (as well as the complete message history) to Apple with Apple keys, each and every day. They don’t need any “keys to the device”.

This is well documented in Apple’s KB article about iCloud encryption: https://support.apple.com/en-us/HT202303

Apple’s on-device hardware encryption has nothing to do with this problem. This is a software design issue that Apple chose. Google chose a better, safer way to do it.

The fact that it’s a problem with the US government is a red herring. There are still good and bad choices in cryptographic system design.

Please do read the linked URL. Apple was on track to fix this glaring issue, and then, according to Reuters, Apple Legal shut down the project. Whether it was done specifically on FBI request, or proactively by Apple to butter up the FBI, is irrelevant: the FBI has no legal basis to command Apple to drop this project, so the decision not to safeguard user data from government snoops rests solely with Apple.

https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...

Additionally, the phone that Apple famously refused to unlock is irrelevant: Apple had already provided all of the related account’s iCloud data (presumably including a full device backup) to the FBI. It’s not in Apple or the FBI’s interest to draw attention to this detail.

I wonder if perhaps the news story about how “Apple vs FBI for user privacy” was an FBI reciprocation to aid Apple’s privacy brand narrative in exchange for Apple not encrypting backups (so Apple can always provide all of the device data to the FBI without the phone).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: