(C) Alec Muffett's DropSafe blog.
Author Name: Alec Muffett
This story was originally published on allecmuffett.com. [1]
License: CC-BY-SA 3.0.[2]


Notes for interview with @TonyaJoRiley of @CyberScoopNews regarding #EndToEndEncryption of Direct Messenger on Twitter post-Musk

2022-11-25 11:05:47+00:00

So, I got interviewed for this; as usual I took a big set of questions via email, and then some back-and-forth over Signal for clarifications and followup:

Elon Musk wants to roll out encrypted messaging for Twitter, but his deep cuts to the company’s workforce and chaotic management style are raising major questions about whether he can do so responsibly, @TonyaJoRiley reports. https://t.co/alwZ94EHRr — CyberScoop (@CyberScoopNews) November 23, 2022 https://twitter.com/CyberScoopNews/status/1595529120200417284

Interview Notes

So, to answer the usual last question first, as I am sure you already know otherwise you would not be contacting me: I’m Alec Muffett, I used to work as a software engineer at Facebook/Meta, and I led the team which first built end-to-end encryption (E2EE) into Facebook Messenger as the “Secret Conversations” feature which allows people to chat with each other using E2EE from one device to another.

There are a bunch of people passionately but inaccurately discussing Twitter E2EE, saying things like: “But it won’t be able to do web browsers!!!”

But technology has moved on since 2016 and now there are solutions like Meta’s “Code Verify” plugin which can help people have a reasonable E2EE experience using a modern web browser.

The point of E2EE is to restrict messages so that information in them is only available in any reasonable way to the recipients who the sender intended, rather than for the sender to enforce what devices and software any given recipient is using. This makes the challenge of delivering E2EE less fraught than some people imagine.

Nonetheless: the challenge for Musk’s Twitter is to create a credible E2EE solution for Direct Messages (DMs) – and if the resulting code is not credible, there is no point in shipping it because the risk of it somehow being fundamentally broken reduces to zero any marginal benefit of using E2EE over the existing DM solution.

At Messenger we gained a lot of free “credibility points” by adopting the same Signal-based code that WhatsApp had licensed, and even though we had a free hand in design and implementation (because “Secret Conversations” is a “special feature” which users must opt-into) the whole thing still took about 18 months of effort.

Some of that could be discounted on the basis of having to build political consensus, but the time expenditure is not insignificant.

E2EE is not a feature which you credibly lash together with cable-ties and duct tape; it’s all about getting to the point where the platform becomes an inert medium over which people exchange messages which the platform cannot ever see — unless, of course, messages are reported to the Trust & Safety team as abuse; at which point one then has to have included some technology like “Message Franking” which we invented for Secret Conversations to prevent people making bogus abuse reports.

More than that, however: in Twitter E2EE, what do you do about old/existing DM history? Perhaps encrypt it and splice it into conversation histories? Perhaps build E2EE as a solution and make old messages “legacy” content? And what if one of the participants to a group chat is a stale or dead account?

These latter are the questions which my former colleagues at Meta are now facing as they convert Messenger towards being E2EE-by-default going forwards; and they have spent over 5 years working on this. To my mind, Twitter faces a similar challenge, and not only are “superprogrammers” and “being hardcore” not going to solve the problem in a credible way, but in fact taking such an approach would be antithetical to credibility.

(question clarifying “message franking”)

Franking (if you’re a stamp collector) is the process of “cancelling” a postage stamp, or use of a machine in place of postage stamps. https://en.wikipedia.org/wiki/Franking

Cryptographic Message Franking is something we invented for Messenger Secret Conversations, since embraced by industry and academia such as https://eprint.iacr.org/2019/016.pdf, where a platform “stamps” the outside of an E2EE-encrypted message in such a way that it can be proven, if revealed/reported by a recipient, that the whole thing came through the E2EE messenger solution and is not a Photoshop fabrication by a malicious recipient attempting to get the sender into trouble.

(question regarding what ought to happen with dead accounts)

That’s a great question. The challenge is: who is going to choose an answer, what will the answer be, and who is going to get inevitably upset at the answer?

(question regarding whether Meta’s head start is a great benefit)

[It’s] more than a 5 year head start. It’s also 7+ years of thinking, and capable engineers who want to do things right rather than quickly, and a vision for a product rather than a tickbox, plus all the modern obligations for a new platform like “how does one report hate speech in a way which does not compromise privacy nor provide an opportunity for fraudulent accusation?”

(question regarding the team at Twitter building stuff anew)

Twitter have been flirting with encrypted DMs on and off, for years. But I will bet beer that most or all of the people who were working on it, are gone.

(question re: my time building E2EE at Facebook/Meta)

The Facebook Secret Conversations project started around January 2015 and I led it from inception to first ship in mid-2016.

(question re: multiple devices and Lea Kissner’s web-browser-E2EE thread at https://twitter.com/LeaKissner/status/1592937783169286144)

Lea’s great, and you will take notice of her “point 3”, but the notion that a web-based client is inherently less trustworthy than an app, is…. arguable both ways. What she is suggesting is that alternate code with a backdoor could be pushed to a specific user, by the simple act of them loading up the webpage.

This is true but it is not terribly worse than the potential for releasing an app which silently leaks message content for people whom the platform has been ordered to spy upon

In the end there is the fundamental question of whether a user trusts a platform to supply a credible E2EE solution to them.

This is what’s called a “trusted computing base” — the set of software which a user is obliged to blindly trust for want of a better alternative.

e.g.: have you checked that there is no government backdoor in Android or iOS which allows governments to hack into your phone remotely? No? Then how can you be certain that you are secure?

Some things eventually you’ll have to take on faith, and that is why credibility of a solution is important.
[END]

[1] URL: https://alecmuffett.com/article/16436
[2] URL: https://creativecommons.org/licenses/by-sa/3.0/

DropSafe Blog via Magical.Fish Gopher News Feeds:
gopher://magical.fish/1/feeds/news/alecmuffett/

You are viewing proxied material from magical.fish. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.