171–180 of 734 posts
Which is exactly why I use Signal exclusively.
Signal prohibits backing up chats on iOS. So there’s no question of information leaking from a backup when there’s no way to create it.
Another 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…
Earlier quoted context omitted.
It's mostly marketing bullshit. Apple and Microsoft both tried to build ad businesses, but when they weren't as successful as Google, they turned lemons into lemonade by launching data privacy PR campaigns against Google. Meanwhile, Apple and Microsoft quietly censor their products in China, surrender data to Chinese authorities, and now we find Apple is intentionally leaving iCloud data insecure. Presumably Google w…
I totally disagree. I work for Apple, and I can tell you that for everything you do privacy is involved. It’s not just marketing.
Beyond HN and tech circles, is there any detectable groundswell of demand for privacy? When you talk with friends & family about privacy, does anyone care? When average people care about privacy, the large players will respond. Until then, pressure from the state can be accommodated without irking customers, so Big Tech will play along.
I've spoken to many in security, selling E2E enablement for the enterprise, and even among CIOs, there is no urgency to implement this. You can imagine the indifference among the less tech savvy
Earlier 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.
Earlier quoted context omitted.
> Yes, but the key is stored in your iCloud backup if you use it. As soon as you disable iCloud backups it will roll the key for iMessage and they will be effectively E2E encrypted. Assuming this is true, you still don't know what people on the other end will do, meaning it is never actually E2E encrypted.
E2E usually means from endpoint device 1 (my iPhone) to endpoint device 2 (my friend’s iPhone). What the other person will do with it doesn’t factor into the conventional definition of E2E.
So what about all the privacy billboards, 'What happens on your phone stays on your phone?'. New version: 'What happens on your phone stays on your phone and unencrypted on the cloud'.
Non Apple fans have been screaming about Apple's Marketing being detached from reality.
Earlier 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…
Uh, no. There's no way to accomplish that without some kind of user-managed escrow (even a pass phrase would be fine). It's maybe not the seamless experience Apple wants to offer, but it's certainly not impossible.
Frankly the kind of dummyproof restore being offered is fundamentally incompatible with private backups.
Earlier 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…
Earlier quoted context omitted.
> Didn't Apple publicly claim IIRC it said it wouldn't bow down on implementing back doors to unlock protected devices and encrypted content on them, which is specific enough not to cover this case. Bowing down on implementing new security features doesn't go against the promise to not bow down on the security of existing ones, as written. It can be argued to go against the spirit of the earlier public statement of c…
Except that this is a backdoor that circumvents device protections for the vast majority of users.
It is a front door convenience feature which has distinct privacy/security trade-offs.
There exists no magical way to provide a means of lost password/device recovery which doesn’t grant Apple access to decrypt your data. It turns out that a lot of users want to have a way to recover from a lost device/password and are willing to let Apple decrypt their data.
You do this by ticking the ‘iCloud Backups’ toggle on your iPhone.
A backdoor by definition is not a user facing and configurable feature which is thoroughly explained in end-user documentation.