Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

usenix.org

Post reply on HN
Print view View original

131–140 of 141 posts

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#131

Post by commandersaki »

matthewdgreen wrote: post #101
tpmoney wrote: post #92

Earlier quoted context omitted.

Is “Settings -> iCloud -> Advanced Data Protection” really the “moral equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the leopard”? Where else would you put it? I could see an argument for putting it in “Settings -> Privacy and Security -> Advanced Data Protection” but that to me feels like a “six if one, half dozen of the other” change.

You could suggest it during initial setup. You could advertise the feature beyond a weirdly named setting at the scroll-down portion of the iCloud page. You could call it something more descriptive like “end to end encrypted iCloud”, which would distinguish it from other security features. You could periodically ask users to do checkups, and verify that their backup contacts are still active and available — even if t…

I think the requirement of having a recovery contact or key is placing too much burden and complexity on an average user. I think that's why they also keep it off the setup screens not to mention that your personal device ecosystem has to be supported (no legacy device or software). Anyone seeking improved privacy and security will discover ADP and the nuanced setup.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#132

Post by matthewdgreen »

commandersaki wrote: post #131
matthewdgreen wrote: post #101

Earlier quoted context omitted.

You could suggest it during initial setup. You could advertise the feature beyond a weirdly named setting at the scroll-down portion of the iCloud page. You could call it something more descriptive like “end to end encrypted iCloud”, which would distinguish it from other security features. You could periodically ask users to do checkups, and verify that their backup contacts are still active and available — even if t…

I think the requirement of having a recovery contact or key is placing too much burden and complexity on an average user. I think that's why they also keep it off the setup screens not to mention that your personal device ecosystem has to be supported (no legacy device or software). Anyone seeking improved privacy and security will discover ADP and the nuanced setup.

This is a set of engineering problems to be navigated, not really a fundamental challenge. My critique is that Apple isn't navigating those problems. Many of these problems have solutions, some of which don't require a ton of work.

1. Legacy devices are going away naturally. I doubt the number of Apple accounts with legacy (iOS/Mac) devices and routine iCloud usage is anywhere near a majority, and I assume the number drops every year. You can test for this condition whenever a user adds a new device, and encourage adoption for people who don't have this problem.

2. Apple already requires that you have backup phones and emails for MFA. They could easily enforce recovery contacts as a basic requirement for any new iOS device (even if ADP isn't turned on) and measure the stability of those relationships over time, until they're confident that these recovery relationships are viable. This would probably reduce their support costs as well.

3. Apple has a tool called "Safety Check" that's designed to help you secure your device. Last I checked, ADP isn't recommended or even mentioned by the tool as an option. This seems like an obvious place where Apple could boost understanding and knowledge about ADP, but they've chosen not to.

So yes, I do think there's quite a bit more that Apple could do. I think it's unfortunate that people believe that Apple is not currently downplaying this feature globally due to the UK mess, because that is certainly what they are doing.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#133

Post by methuselah_in »

frontfor wrote: post #39
methuselah_in wrote: post #33

[flagged]

Both of us know this is a non-starter for most people, even technically inclined ones.

well, if not there are hundreds of servers(public you can choose from). And Encryption is there as well. So server administrator can't even read your texts, if you are not so tech savy.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#134

Post by methuselah_in »

9dev wrote: post #55
methuselah_in wrote: post #33

[flagged]

Nice! That way you can chat with yourself at all times! I mean, everyone else will continue using a different messenger, but they don't have anything interesting to say anyway!

If you are not dumb enough to let other people how companies sucking your data and giving and fixing you in their own silos. its about personal choice.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#135

Post by methuselah_in »

some_furry wrote: post #120
ezst wrote: post #119

Earlier quoted context omitted.

For the record, XMPP has OMEMO as its standard E2E/PFS-preserving encryption protocol (based on your usual double-ratchet aka Signal encryption), which is regularly audited for security (and as recently as last month in the case of the Conversations Android client). XMPP being used by several law enforcement agencies and institutions like NATO, I wouldn't default to making fun of its security.

https://soatok.blog/2024/08/04/against-xmppomemo/ OMEMO is not always-on like Signal, so it doesn't even compare.

you sure?

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#136

Post by methuselah_in »

methuselah_in wrote: post #134
9dev wrote: post #55

Earlier quoted context omitted.

Nice! That way you can chat with yourself at all times! I mean, everyone else will continue using a different messenger, but they don't have anything interesting to say anyway!

If you are not dumb enough to let other people how companies sucking your data and giving and fixing you in their own silos. its about personal choice.

Also to be precise i have made 30+ people switch!

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#137

Post by int_19h »

modeless wrote: post #106
int_19h wrote: post #65

Earlier quoted context omitted.

> the only cloud backup solution Apple allows you to use Not quite. You can still have automatic local backups set up for iOS and macOS devices to your own NAS. And that NAS can then do cloud backups of whatever is on it in any way you want. It's certainly more effort than the stock iCloud solution, but it's still an option.

OK, if you have or buy a $599+ Mac from Apple in addition to your iOS device, and first connect your iOS device with a USB cable, and then enable the optional Wi-Fi sync, and regularly connect the Mac and the iOS device to the same Wi-Fi network while the Mac is not sleeping, and configure an e2ee cloud backup on the Mac to include the iOS backup, then that is actually a way to achieve a third-party e2ee cloud backup…

I'm pretty sure your estimate is wrong by at least several orders of magnitude. Lots of iPhone users also own MacBooks, for starters, and iPhone will nudge you to set backup when you connect it to any Mac. And of course they are going to be on the same Wi-Fi network most of the time, too, when that person is at home. I'm not sure how sleep plays into it exactly, but MacBooks do wake up on their own to do their backups and things like app updates, so I wouldn't be surprised if an iPhone can actually wake up a sleeping MacBook to back up to it.

So the only case that is relatively unusual is having the Mac back up to a local NAS, but that's only because NAS themselves are a power user thing. Still, turnkey ones like Synology etc are much more common than "triple digits worldwide", and if you have a Mac and a NAS, why wouldn't you set up Time Machine to backup to said NAS?

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#138

Post by some_furry »

methuselah_in wrote: post #135
some_furry wrote: post #120

Earlier quoted context omitted.

https://soatok.blog/2024/08/04/against-xmppomemo/ OMEMO is not always-on like Signal, so it doesn't even compare.

you sure?

Yes, this is obviously true because XMPP has a plaintext mode.
Post reply on HN