Beeper as the universal inbox
This is a joint post with Prof. Carla Florencia Griggio.
Sometimes, a tool is the best way to demonstrate to people just how powerful interoperability can be. And Beeper is very rapidly making the potential of messaging interoperability clear (and providing the universal inbox many people would like.)
Try it out, if you’re a user of WhatsApp, Signal, Slack, Instagram, Facebook Messenger, Twitter, Discord, Telegram, Matrix, Google Chat, Google Messages, Android SMS, IRC, or LinkedIn!
Another advantage of such a tool is it lets us dive deep into the weeds of interoperability, but illustrate the issues in a very practical way. Here are a few thoughts we had after using it for a few months, in the form of a conversation.
CFG: Since it’s based on Matrix bridges, the current version breaks end-to-end encryption for messaging systems which implement E2EE, such as Signal (and instead, there’s end-to-bridge encryption).
IB: This is a perfectly reasonable trade-off to make in early-version software, as long as users are fully aware this is happening.
However, it makes the bridges critical to overall system security. For more mature software, preserving encryption from the sender’s system all the way to the recipient’s is critical. It’s technically possible for users to run bridges on their own system. And apparently, Beeper announced at this year’s FOSSDEM it is already close to releasing direct Signal encryption support in its own client.
As I wrote in this paper based on my undergraduate computer science research project 😉 and published during my PhD, I don’t have any problems with treating an “end” as “within the user’s own trusted zone of devices”. This is how distributed systems work, from a technical perspective. And indeed, it’s how the OG US National Security Agency defines a “trusted” component — something which can break your security policy.
CFG: A related issue is that users need an account on the original platform in order to connect to its users on Beeper. “True” interoperability would avoid this.
IB: Allowing, for example, a user of Signal to send an E2EE message to a WhatsApp user without needing an account on WhatsApp (if Signal chose to implement that functionality. Not yet). And indeed, Meta is legally required by the EU’s Digital Markets Act Art. 7 to facilitate this for those users who want it.
We are just waiting for a Meta competitor to implement this, since the DMA loads all the costs of implementing this functionality on startups and other challengers, not the behemoth gatekeepers it regulates.
I wrote about this in much more detail in 2020 in my tornado scale of interoperability (p.1 of this report).
CFG: The bridges (or perhaps Beeper as a client?) don’t cover all functionality from the original apps, and very often Beeper shows little notes telling you to go to the original app. For example, if you receive a call, Beeper just notifies you that there’s someone calling and you should open the native app.
A while ago, a friend from WhatsApp sent me a one-time view picture. I could only see it once on WhatsApp, but… it’s still there on Beeper. Those are the kind of asymmetries that I’m super-interested in catching and studying in my current “mInt” project, because they could give a very bad rep to interoperable chats on the safety front.
I’m actually working on a paper right now on message deletion features, which seem to typically be handled on the client side on E2EE apps (makes sense). When we delete a message, there is a “request to delete” to the client on the receiver’s side, but if the receiver is using a different client that perhaps ignores those requests… well, the message isn’t deleted, and the sender might think it is.
IB: I see that very clearly jumping between the Signal and WhatsApp apps on my phone/tablet/desktop and Beeper. The latter shows messages I long ago had “deleted” from the original apps. But in one sense Beeper is providing a more accurate visualisation to the user, since it is possible those messages are also available on other clients which do not enforce this deletion request. (And I’m confident Automattic, which recently acquired Beeper, will continue making very rapid strides in its development.)
CFG: I tried reproducing this today on Beeper and I see that now it’s fixed, BUT you get a little note saying that for privacy reasons, you can’t see the picture on Beeper, and you need to go to WhatsApp to look at it.
IB: Yes, I’ve had similar experiences with two-factor authentication messages, and calls. And there’s a discussion to be had about where Meta is and is not justified under the DMA in limiting interoperability to “trustworthy” interoperable clients — and what that means precisely. And how to stop Meta using this as a mechanism to subtly degrade interoperability — as I suspect it is doing here:
Apple has done something similar, forcing Beeper (for now) to abandon an investment of $750,000 to provide iMessage support.
I am constantly being disconnected from my LinkedIn messages in Beeper, I suspect as an accidental part of Microsoft’s implementation of two-factor authentication:
Regulators will need to stay on top of such issues to stop them being used as not-so-subtle obstacles, where interoperability is legally required.
IB: I suspect there is much to learn from the eternal debates during the 1990s/early 2000s on Digital Rights Management, and technically nonsensical ideas that users can be stopped from using external devices (such as audio recorders or cameras) to make copies of data on “trusted” systems which try to prevent unauthorised copies.
CFG: On Signal you can choose a setting to prevent screenshots of a conversation. If I take a screenshot of a conversation on Signal, it’s just a black/white image… but if I go to the same conversation on Beeper, I can take the screenshot as normal. This is quite the betrayal for Signal users counting on that feature (perhaps they shouldn’t, but that’s a different conversation.)
IB: See above 😉 But equally, I have nothing against less-than-perfect security measures (don’t fall for the myth of the super-user), and Beeper only needs to implement this type of feature once for it to apply to ALL its connected services.
CFG: Because it’s based on bridges, contacts don’t know that you’re connecting from somewhere else. Especially for cases where there are asymmetries in functionality, ESPECIALLY for privacy/safety functionality, I don’t think that “seamlessness” is the way to go (again, one of the critiques I’d like to play with in my mInt project).
IB: This is almost by definition always true outside a perfectly trusted system (which don’t exist, outside the highest-security elements of nuclear weapons detonation controls and similarly high-stakes systems).
What is often NOT mentioned is that universal clients like Beeper can also implement all sorts of services (such as message translation) that would not be worthwhile for a single service. Especially where such functionality runs counter to the business interests of a commercial service provider, who (for example) might want to grab as much of users’ attention as possible. Here is another Beeper example, which is very useful with contacts who send a message per paragraph every time they write to you, triggering multiple “kicks” from my Apple Watch as each notification arrives:
One feature I really like in Beeper is that it is trivial to assign conversations and groups to a “low priority” tab, which by default does not trigger notifications. Suddenly, my manic need to respond instantly to every single individual message I receive has subsided!
You can also easily search all your messages! This is otherwise only possible using separate tools (like Apple’s Spotlight, if you are using their operating systems).
It would also be almost trivial for Beeper to implement user preferences for which services they prefer over others. For example, to notify (categories of) potential contacts they prefer Signal over WhatsApp over iMessage.
Those categories might include (if information could be gleaned from a user’s address book and obvious cues, like their own work e-mail address) different suggestions for colleagues and non-work friends.
This would be helpful for building user interfaces for interoperable systems which address an issues identified by Carla and others: that many users currently use different messengers to actively segregate work and personal contacts, or family and friends.
CFG: Those are some thoughts on Beeper, there are other awkward things that I’m still figuring out. On the positive front, my main use of it is:
- To avoid having the Telegram app installed on my phone (I got a bit paranoid a few months ago, and it was also a good excuse to push Beeper a bit).
- On my computer, it’s much easier to have just one place for different apps rather than installing each app.
I prefer not to chat on my computer, otherwise I’d be chatting all the time, so it’s quite convenient to open/close all platforms at once. On the phone, I still like having the native apps and enjoy the full functionality of each.
IB: Fair enough! I personally have now replaced the original apps with Beeper everywhere 😁 (while keeping them tucked away for the functionality Beeper hasn’t implemented yet, like calls and 2FA messages).
Today, I shut off the closed iMessage service entirely on all my Apple devices, as I have moved my few remaining conversations on that service to WhatsApp or Signal (so I can use only Beeper).
Once Apple has implemented the promised GSMA-standard RCS-E2EE, and required all mobile telecommunications companies to support it, I’ll consider using it again. But it is not a particularly innovative system any more (that’s what a lack of competition does to innovation).
iMessage’s one real advantage these days is close integration into Apple’s platform hardware security mechanisms. But competitors can now demand access to those as well, under the DMA’s Art. 6(7).
Interoperability works really quickly as a solvent of closed ecosystems.
Users who similarly shut off all closed services will find it much easier to switch to cheaper hardware in future. This is one reason why Apple’s entire business model currently depends on tying their pricey hardware to software and services which use network effects to lock in their user base.
My amateur investment advice: short Apple shares.
