Jon Millican

I've seen a lot of chatter today about Instagram ending support for optional End-to-End Encrypted DMs. I helped to lead on cryptography and privacy for E2EE in Messenger and Instagram for many years, until I left around 10 months ago, so it's disappointing to see it being removed from Instagram.

Jon Millican reposted

walrusfacts.bsky.social

@walrusfacts.bsky.social

6 Apr

Walrus cows give birth away from their herd. Blubbergasting!

Jon Millican reposted

walrusfacts.bsky.social

@walrusfacts.bsky.social

22 Mar

Walruses sometimes appear almost-white when swimming because their surface blood vessels constrict in the cold water. Walrusome!

Jon Millican reposted

walrusfacts.bsky.social

@walrusfacts.bsky.social

21 Mar

Walruses use their tusks to form holes in the ice, and to help them climb out of the water. Blubbergasting!

What we showed in Messenger is that even in a very complex messaging product attached to a social network, it is possible to prioritise deploying strong privacy through E2EE. It's not exactly the same as Signal or WhatsApp as it has to make its own set of tradeoffs for its own users. But it's doable

No two networks are identical, so a decision that's right for one isn't always right for another. E2EE for Messenger doesn't necessarily mean it's also right for IG DMs. But privacy and security are critically important; and I'm disappointed that the tradeoff didn't land in their favour this time.

This thread is more than long enough, so I'll wrap up shortly. But suffice to say: end-to-end encryption is hard to do well in a complex product, makes promises that can be tough to reason about and maintain, and comes with both positives and downsides.

So I can understand Instagram's decision here. I'm still disappointed though.

I think there is value in having optional E2EE within a larger messaging app. It was one of my first projects at FB, before we made Messenger E2EE default! But the privacy value is: * People who know they need E2EE. * ..without another communications channel. That's not zero. But may not be huge.

So in my view, the biggest loss here isn't the removal of optional E2EE. It's the implication that IG DMs are no longer planned to be end-to-end encrypted by default.

If we look at optional vs default; it's first important to recognise that IG DMs were never E2EE by default. That's a shame in itself; but at least it means that IG are not changing anything for the vast majority of conversations on the platform.

But on the other hand, I don't think "few people are opting in to a non-default feature that lives in a settings menu" is a good reason to assume that the feature isn't valuable and shouldn't be default.

Then if we look at message history: this is tough to do well in multi-device applications, authenticated by username + password or similar, especially those supporting web. We pulled it off in Messenger; but with product friction, and the innate E2EE downside that some people will lose data.

I'm not sure that Message History should be any harder to do well on Instagram than it was on Messenger. But it is hard, regardless.

But when you're talking about somebody interacting with content, then bringing up a "share" dialog, then sending a message - then somebody else opening their inbox, opening a thread, and immediately loading some content from a direct link - it's much harder to reason about what cannot be inferred.

I can't speak for others, but I primarily use WhatsApp, Signal and Messenger for communications, and Instagram DMs for sharing content. Assuming that this pattern holds; the above means that the feature cost is higher for IG, and the privacy benefit may be lesser than in WA, Signal and Msgr.

Finally, "cannot know what content is in your messages" is an incredibly high bar to achieve.

When we're talking about text messages, with strong cryptography and adequate padding, this is - to simplify things significantly - relatively straightforward to achieve.

From a pure privacy perspective, there are obviously a lot of downsides to this, but if the network knows the things that you choose to share (a strong positive signal), that is likely to significantly improve its ability to show you content that you're likely to interact with.

I don't really have the expertise to debate whether "likely to interact" ~= "want to see"; but it's a reasonable assumption that they will at least be meaningfully correlated. So if better ranking is part of the implicit value of sharing content; E2EE is in direct tension with this.

There are some designs attempting to approximate this; but people don't want approximate privacy guarantees. So it generally involves adding nuance to the encryption story, and then degrading the product experience somewhat by failing closed when the approximation can't achieve a clear answer.

Another side to content sharing is that, for many people, a big part of the value of the social network is its ability to surface content that you want to see.

First-party Content is harder because E2EE isn't the only privacy constraint. First-party content may be ephemeral, may have restrictive privacy settings, or its owner delete it post-sharing.

These are really important to respect on a social network; that are hard to achieve if you simultaneously need: * The server to decide whether you specifically may see a specific piece of content, and indeed whether it still exists. * The server to know neither what you're viewing, nor who you are.

The thing is, though, that sharing rich content is tough to pull off well with end-to-end encryption. In large part because it's a pretty bad experience if you're just sharing links: you actually want to display previews of the content, maybe even with some interactivity, in the messaging thread.

You might attach a preview of the content to the message as an image. And is what many apps do when you share a third-party URL: fetch it, render locally, and just attach a picture of it. But that's not super efficient for sender or receiver; and it doesn't necessarily work for first-party content.

I'll share thoughts on: * Key features of messaging apps. * Message history. * Optional vs default.

First: when a messaging product is attached to a social network, there's a somewhat innate dual purpose to it: communications, and sharing on-platform content. I.e. you might just be talking to your friends; or you might be talking specifically about content on the platform.

9to5mac.comApple is removing iCloud end-to-encryption features from the UK after government compelled it to add backdoorsApple is removing the option to enable Advanced Data Protection for iCloud users in the United Kingdom. This feature let users fully protect their data stored in iCloud with end-to-end encryption. However, a recent UK government order forces companies…

In this thread I'll share some of my own thoughts on this. None of this speaks for the company (which I no longer work for), for and it's based on my own opinions, not internal data.

Jon Millican reposted

Edwin Hayward

@edwinhayward.com

22 Feb 2025

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.)

9to5Mac@9to5mac.com

Apple is removing iCloud end-to-encryption features from the UK after government compelled it to add backdoors

Jon Millican reposted

Joseph Lorenzo Hall, PhD

@josephhall.org

22 Feb 2025

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

Jon Millican reposted

Joseph Lorenzo Hall, PhD

@josephhall.org

21 Feb 2025

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/

Jon Millican reposted

Joseph Lorenzo Hall, PhD

@josephhall.org

13 Feb 2025

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

pro.politico.euEuropean Parliament urges lawmakers to only use encrypted messages after China hacks13 Feb 2025 - Pro Article - By Max Griera, Ellen O'Regan

Jon Millican reposted

Justin Hendrix

@justinhendrix.bsky.social

7 Feb 2025

"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."

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

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.