I was on a E2EE conference Zoom-call yesterday, run by the Stanford mob and discussing combatting political misinformation on end-to-end-secure messenger platforms. There were some (IMHO) constructive solutions proposed, such as:
- “tip-lines”
- community engagement with influencers
- reddit/slack-bot like “vaxbots” (“you appear to be repeating some misinformation re: Covid, here are some links to sites which explain the issues…“)
…and there were also some (IMHO) disastrous suggestions, such as:
- distributed client-side keyword blocklists
- technical proposals to implement “sender tracking” of messages in ways that the (eg: Indian) Governments are NOT asking for, thereby simultaneously weakening the defence against implementing what the Governments ARE asking for, whilst also not solving THAT problem in a minimally-privacy-invasive way.
At one point I made the following observation in the chat:
Regards cross-platform communication, the European Union is on track to pursue “interoperability” APIs so as to open up alternative-client access to messengers. This will be a nightmare re: proper and complete, interoperable crypto within (say) the Signal message space/network, but putting that aside: this also opens-up the potential for re-emergence of over-the-top E2EE like OTR on Pidgin/Adium was (same crypto, multiple transports). Would this mean that E2EE messenger apps would have to restrict/track use of being used to transport super encrypted content?
q.v.
…and I used that observation to kick off some side discussion, essentially that any academics who are trying to solve for “tracking a message’s creation and propagation within a messenger platform” will be stymied in a few years by EU demands to “open up messengers to competition” by coercing them all into interoperability, thereby turning our ecosystem of diverse messaging platforms into the same kind of “race to the functional bottom” nightmare where email has lived for the past 25 years.
I’m relieved that (so far?) (April 2022 Edit: Alas, I was correct.) I seem to have misspoken about the depth of active EU commitment and have simply been channeling Professor Ian Brown and a selection of journalism pundits, for instance:
- Interoperability as a tool for competition regulation – Ian Brown
- Why Messenger Interoperability is a digital canary in the coal mine – Adam Tinworth
- We need Messenger Interoperability – Martin Recke
…but it’s still a bloody scary, illiberal, misconceived idea. To explain:
Sometime around 2013, Facebook removed XMPP API and (eventually) MQTT API access to Facebook Messenger, which killed-off the ability to use Facebook Messenger from third-party clients such as Pidgin or Adium. This was — including by me — regarded as a “bad thing” from the perspective of software and communications freedom, and at the time I felt that that was a valid complaint.
But I don’t think that any more.
Reason: the extant XMPP and MQTT clients were, frankly, pieces of shit. They tried to do too much, for too many platforms, they did it badly, and they did it in a lowest-common-denominator (hence: “race to the bottom“) kind of way, meaning that the “open” clients like Pidgin and Adium were always going to be second class citizens (no stickers, no payments, no location sharing, no heart-emoji-animation-effects) and – worse – the people using the clients would be complaining about being second class citizens whilst also being righteous about exercising their choice to use shit software.
Meanwhile the “real” Facebook-authored Messenger client (and its competitors) could mature, expand in robustness, functionality, “cuteness” and “ability to communicate nuance” where the Adium community was still arguing with each other about the basics.
That multi-client software is innately limited by its attempt to embrace platform/stack diversity was fully driven home to me when I ended up as lead engineer for Facebook Messenger to adopt end-to-end encryption as “secret conversations”; the amount of engineering effort that goes into making a nice, seamless, modern user experience atop a solitary “stack” would be nightmarish in a multistack-client context (“how do we retrofit GIPHY to MSN?“)
The usual complaint from FOSS messenger-client evangelists at this point is that “Facebook” (and Google/GChat, and MSN, Yahoo, AIM, QQ, VK, and god knows how many other clients) should “open up” and publish “everything”, which would somehow “fix everything”. But it’s not that easy: someone would have to understand, comprehend, implement, track, and harmonise handling of these N diverse platform stacks… and with time it becomes untenable.
So I believe “messenger interoperability” is an unwise pursuit that would set back the aims of end-to-end-secure communication for decades; excepting one possible (including: possibly really stupid) proviso. If it were possible for “alternative client” apps to exist on a given phone and to be granted permission to talk to the locally-installed WhatsApp, Signal, and other chat-client instances, to present a single user interface… that might be okay.
This is clearly not what the proposers are angling for (eg: Ian Brown is literally discussing how to provide “competition regulation” rather than how to provide “a richer and more secure end-user messaging experience“) but my thinking harks back to Pidgin & Adium: what if there were one universal client which could drive all the stacks, for those people who wanted it?
Then it could talk via an (REST-equivalent of IMAP/NNTP-like) API abstraction to the other locally-installed clients, permitting them to advance and assuring they are available when the universal client falls short.
But why do this? For one reason alone: to restore the capability to use OTR:
If you’re going to mandate that people have the ability to talk to multiple messenger networks, the cleanest and most secure way to implement it is to talk to the “networks” via the locally-installed clients, thereby preserving the end-to-end principle; and if you do this it means that the “universal client” which achieves this can also provide over-the-top superencryption (and other features) without compromising the security features of the “apps”.
It could also open up a free market in superencryption – and surely that’s what we really want and need in these uncertain times, where governments are attempting to coerce the big platforms into implementing back doors?
Of course the obvious downside here is that access to the selfsame local API would be demanded by local law enforcement for purposes of spying on users.
But that’s what the interoperability discussion is actually all about, no?
⊞