Jon Millican

FYI, Labour just made every Apple product in the UK less secure. All so that the state can snoop at leisure on anyone they like.

(Apple refused to install a back door to let government snoops in and got rid of enhanced security instead. Like binning a door instead of cutting a skeleton key for it.)

it shouldn't be illegal to not have access to your customers' data

The following can be attributed to Dr. Joseph Lorenzo Hall, Distinguished Technologist at the Internet Society: The Internet Society is saddened at the news that Apple has removed access to its cloud end-to-end encryption, known as Advanced Data Protection, for its UK users as a result of pressure by the UK government. This move will make British Apple users less safe, and make their cloud data more susceptible to criminals and other attackers. It is clear that the UK government continued to pressure Apple to weaken the security of its service despite global outcry from cybersecurity experts, civil society, private industry, and foreign politicians. In choosing to remove the feature rather than building a backdoor into its Advanced Data Protection, Apple ensured that at least its global users would continue to benefit from the security and privacy of end-to-end encryption. However, for UK users, their government ensured that their security and privacy is worse than before.

We at the Internet Society are deeply disappointed that Apple has had to stop offering end-to-end encryption in the UK. The following can be attributed to Dr. Joseph Lorenzo Hall, Distinguished Technologist at the Internet Society: 1/

European Parliament urges lawmakers to only use encrypted messages after China hacks 13 Feb 2025 - Pro Article - By Max Griera, Ellen O'Regan

Maybe there's something important about end-to-end encryption?! European Parliament is now recommending members use E2EE messaging because of the implications of Salt Typhoon. ht @komadori.bsky.social

U.K. orders Apple to let it spy on users’ encrypted accounts Secret order requires blanket access to protected cloud backups around the world, which if implemented would undermine Apple’s privacy pledge to its users.

"The British government’s undisclosed order, issued last month, requires blanket capability to view fully encrypted material, not merely assistance in cracking a specific account, and has no known precedent in major democracies."

I do think this is a bit different though. E.g. you can also lose a physical driving license - and there's a pretty well standardised reissuance process for them, involving no permanent data loss.

Not to say that there aren't issues with the proposal. But I'm not sure recoverability is one of them.

Thanks! Definitely understand why you'd build it incrementally rather than going straight to E2EE; and just having Bluesky DMs will already be great!

But yeah - if there were a single architectural choice that has the biggest impact on ease of transition, message history would have to be it!

Of course, by "we" here I mean Meta. I don't know what tradeoffs Bluesky will be making. But as they plan a progression from non-E2EE to E2EE messaging, I hope they're able to design to constraints like this tradeoff, to simplify their transition later on.

However in our case, per the Labyrinth Protocol whitepaper, we ended up choosing to keep 1 & 2. This means you can log in to use Facebook and Messenger as before, and won’t be blocked if you don’t restore your history. Just in that situation, you won’t have earlier messages.

It’s obviously tough moving from a world where you can have all 3 for a product - as is the case for non-E2EE messages - to a world in which one of them is not guaranteed. None of them are ideal to give up.

Third, it might be particularly important to people to always have their historical E2EE data to hand when using the E2EE component. In our case, this would mean that you can only even use messaging at all in situations where all message history is available.

Second, somebody in that state may still be actively using the E2EE component. In our case, that’s sending and receiving new messages. For some use cases, this will be all somebody needs; and others it will be good enough.

In our case, Facebook is a platform with many features, of which Messenger is just one. Someone might not recover their E2EE history when logging in for various reasons, and if they don’t need message history for what they’re doing, we don’t need to block them from other things.

First up, you don’t want somebody who has temporarily lost access to some key material to have to completely reset their account to log in. It’d be drastic and painful! Maybe they were logging in to use a different function of the service; or only care about new data?

A pick-two triangle, with corners titled "Message history is available whenever messaging works", "User can log in without cryptographic key material" and "Messaging functions whenever the user is logged in".

Specifically, there are three desirable properties, of which you must pick two:

1. User can log in without cryptographic key material.
2. E2EE component functions whenever the user is logged in.
3. All stored data is available whenever the E2EE component works.

The challenge arises when a larger platform includes a component that is end-to-end encrypted; such as Facebook and now Messenger. As the platform cannot give access to the plaintext E2EE content, there’s a choice to make around authentication, data recovery and functionality.

Given that E2EE messaging is coming to Bluesky, now seems a good time to cross-post a thread of mine from Threads, briefly discussing one of the interesting non-obvious tradeoffs that we had to consider around message history.

Hey there, this is exciting to hear! I'm Jon, from Meta's team who built E2EE for Messenger. If it would be at all helpful to talk over any considerations in the initial system design that might make the E2EE transition easier/harder in future, I'd be very happy to chat over some of our learnings!

Emma Connor and I have been ratcheting the ratchets up to 5! drive.google.com/file/d/1Wr-8...