Dell, which started as a military supplier, encrypts their cloud storage to avoid liability.
I wonder what Apple is liable for in light of this.
Apple dropped plan for encrypting backups after FBI complained
331–340 of 734 posts
Re: Apple dropped plan for encrypting backups after FBI complained
#332Earlier quoted context omitted.
Because syncing isn't a backup? What happens when you sync corrupted files?
I didn't say syncing was a backup. That's the opposite of what I'm saying. I'm saying that my phone becomes the synced copy. The cloud is the canonical version (backed up separately elsewhere) and my phone becomes a device I can lose or break and not worry about anything so I don't need to back it up. As soon as I create any content on my phone I upload it to the cloud. Take my phone from my hand at any moment and as…
You asked why people care about backups anymore, and I told you why what you stated is not a solution to it.
Re: Apple dropped plan for encrypting backups after FBI complained
#333oh I'm deeply disapointed. I payed so much premium for quality and privacy and this is my outcome.
Re: Apple dropped plan for encrypting backups after FBI complained
#334Earlier quoted context omitted.
E2e means next to nothing when using closed source software. Apple could (have) issue(d) an update with code to steal yr anything, without you knowing, so FBI-or-whatever does not "complain". I currently use one e2e service, BitWarden as keychain, that ticks the boxes (e2e AND open source client).
This hard line is too facile. If you are paranoid about malicious code updates, then making part of your stack open-source doesn’t matter. I could push an update to your OS that reads the keys out of your BitWarden.
I meant that closed source even gets less safe when allowing auto-updates. When using opens source the auto-updates need to be trusted; yes. Nothing new.
Re: Apple dropped plan for encrypting backups after FBI complained
#335Earlier quoted context omitted.
They botched the original Windows Phone through a failure of management. They botched subsequent pushes on it because the bootstrapping problem around apps had grown too deep. At this point, if they tried to give it another go, there would be trust issues: "Am I investing in a phone ecosystem that's going to be dead in a few years?" Not to mention how much they've gone all-in on Android development. A Surface-branded…
They botched the original Windows Phone through a failure of management This. I had some Windows Phones besides my iPhones, because I liked very much what they were doing. Windows Phone 7, despite being technically weak (it was based on Windows CE), had an awesome UI. Nokia had some really affordable phones that were really well-built for the price and Windows Phone was getting traction. Quite a few friends/colleague…
And underpinning all of that was the unfortunate fact that this truly innovative and lively new area of development at Microsoft found itself happening at the tail end of Ballmer's tenure.
There was this spark of energy around Zune, and then Kin (https://en.wikipedia.org/wiki/Microsoft_Kin), and then Windows Phone that was just completely orthogonal to the stagnant money-printing strategy that Microsoft followed before Nadella. It was this little glimpse of an Apple-like spirit somewhere deep in the behemoth. It was exciting. But it was always treated as a side thing instead of being placed front-and-center. It's now been diffused into Microsoft's various consumer products, most obviously the Surface, but Windows Phone was already dead by the time things started to change.
Aside: despite all the jokes about it, the Zune (2nd gen and forward) was awesome. It was a little late to the game - it really nailed the traditional mp3/video player right when the iPod touch had just come out - but I think it may've been the peak of that category. Everything from the UX to the hardware buttons was so meticulously considered, the screen was much bigger than an iPod Video, it had momentum scrolling that worked really well despite lacking a touch screen, etc. It did not at all feel like a Microsoft product of the time. It was even one of the first services to offer all-you-can-download, subscription-based music. And you could download songs over WiFi.
Re: Apple dropped plan for encrypting backups after FBI complained
#336Earlier quoted context omitted.
I doubt the hardware supply chain can ever be secured. Even if you were to open-source every single part of manufacturing, there is no reliable way to ensure that the chip you, as a customer, have obtained, hasn't been backdoored. You'd have to delid it and put it under an X-Ray if that even resolves the tiny featuresin modern CPUs.
With an open hardware design, periodically de-liding and examining a random sample of available consumer hardware would probably sufficient to protect the general consumer population, and targeted attacks become very difficult if you purchase your hardware from a store rather than order it by mail. Even so I agree that examining all hardware in that manner is impractical. A better approach might be having a small, si…
It's turtles all the way down
Re: Apple dropped plan for encrypting backups after FBI complained
#337Earlier quoted context omitted.
Isn't Android at this point a more secure OS? The price for zero days at least is signaling that.
It could be signalling one is a far more attractive target to exploit, because e.g. harden shell, soft interior (M&M architecture). Or maybe Apple patches quicker and gets them out quicker, so exploit lifetime is shorter. Just to be clear, I don't know if that's true, but it's equally plausible explanation for the exploit price
That's a good point- there are nine times as many Android devices out there as iOS devices, making exploits for the former more valuable in certain ways.
Re: Apple dropped plan for encrypting backups after FBI complained
#338Earlier quoted context omitted.
I thought iMessage private keys are somehow based on data in the "secure enclave" chip, and thus not able to be stored in the cloud. It's my understanding that Apple could add new "devices" to listen in on future conversations, but it can't read iMessage conversations in transit between existing devices. It can also read iCloud backups of conversation content, which are created by the client device after decrypting t…
If you lose your device and buy a new one and restore your device with a back up, all your messages will be returned. There’s no way to accomplish this without having the private key in the backup. EDIT: When I say there is no way to accomplish this, I’m talking specifically about the process that exists today where the user doesn’t have to remember a password other than their iCloud password (which today, can also b…
Maybe we're talking about different private keys? To clarify, here's how I think it works:
1) To send you a new iMessage, someone else's iPhone Z encrypts it with your public key and sends it through the iMessage network. Apple can't read this message since they don't have your iMessage private key, which is only on your device.
2) Your iPhone A receives the encrypted iMessages and decrypts them with your iMessage private key on your device.
3) iPhone A stores the decrypted iMessage content in its filesystem, which is encrypted locally with the device private key (derived from your device passcode).
4) Time to backup... iPhone A decrypts its filesystem with your device private key, and sends filesystem contents as plaintext, through an encrypted tunnel, to an iCloud backup server, which encrypts the backup locally with an iCloud server private key, and stores it.
5) You get a new iPhone, let's call it iPhone B. iPhone B asks iCloud for a restore. The iCloud server locally decrypts the backup, and sends it to iPhone B as plaintext through an encrypted tunnel. iPhone B receives the backup as plaintext and stores it locally, encrypting it locally with the device private key.
6) iPhone B iMessage client loads the plaintext old iMessages into the Messages client for you to read.
At no point in this process would Apple have or store your iMessage private key or your device private key.
Re: Apple dropped plan for encrypting backups after FBI complained
#339Another case of a headline not being supported by the story: “ Reuters could not determine why exactly Apple dropped the plan. “Legal killed it, for reasons you can imagine,” another former Apple employee said he was told, without any specific mention of why the plan was dropped or if the FBI was a factor in the decision.” And further on: “ However, a former Apple employee said it was possible the encryption project…
I disagree. I read "after" in the headline to succinctly imply that there are reasonable grounds to suspect a causal link between these events, while acknowledging that such a link has not been admitted by Apple (otherwise it would be "in response to").
It's true this kind of wording is often used in low quality journalism to float the idea of a causal link when there is no good reason to suspect one, but this is not one of those cases.
Re: Apple dropped plan for encrypting backups after FBI complained
#340Another case of a headline not being supported by the story: “ Reuters could not determine why exactly Apple dropped the plan. “Legal killed it, for reasons you can imagine,” another former Apple employee said he was told, without any specific mention of why the plan was dropped or if the FBI was a factor in the decision.” And further on: “ However, a former Apple employee said it was possible the encryption project…
> However, a former Apple employee said it was possible the encryption project was dropped for other reasons, such as concern that more customers would find themselves locked out of their data more often.
This. It's also the reason why photos are not E2E encrypted on iOS: Apple really doesn't want to be in the position of saying "sorry, you lost all your data" or "sorry, it's sad that Grandma just died, but all of her photos are gone and there's nothing you can do about it."