Walrus cows give birth away from their herd. Blubbergasting!

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

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

Thanks Tessa! I'm excited to be helping out with Germ, and to know that you'll always maintain privacy and security as top priorities!

E2EE comes with a lot of fascinating challenges - but it's a lot of fun to work through them 🙂

So I do agree with you! I'm more just sharing that the choice carries a lot of complexity and nuance, whichever way it goes; and suspect that these sorts of tradeoffs and constraints are some of the key drivers of this outcome.

Don't get me wrong: I would love to see that work, or similar, happen. Or better, to accept that the product risk needs to be adopted, and find a way to make an E2EE-style product with a bit of additional network-specific nuance.

But then again - if the primary categorisation that's discussed is whether something is E2EE or not; it would be understandable to assume you won't get much public kudos or gain much trust for doing this. So for a product leader, this might look more like a very expensive security program.

WhatsApp's IPLS presents an interesting middle ground of Access Transparency instead of Access Control; which I don't think would meet the definition of E2EE, but coupled with E2EE-style engineering, and your proposed previews compromise - would be meaningfully more secure than pure plaintext.

But note that message history is an especially inflexible option here. Either the backend can access it: and you're not E2EE, or it can't: and people need to manage their own keys. And that comes with a very real product cost.

I 100% agree that incremental security improvements towards E2EE are valuable in themselves, even without closing off every possible leak. But it is an expensive proposition for product (e.g. history), product eng (reimplementing all features), and infra eng (new messaging stack).

This is a really worthwhile point, though I do think there's a meaningful difference between Signal/Germ and Instagram DMs - in large part due to the relationship between the network and the content being shared (first party vs third party) and the associated responsibilities.

Fair! This is the right choice for some people!

A note on this, though, is that if you have privacy preserving rich previews in the messaging thread - it can actually help you decide whether to click on the link or not, so informing your choice better on what to reveal to the network.

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.

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

So I can understand Instagram's decision here.

I'm still disappointed though.

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

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.

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.

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.

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.

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

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.

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

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

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.

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.

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.

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.