The blue bubble vs green bubble debate hit a new point recently when Beeper released an Android client for iMessage after a high schooler reverse engineered the protocol and sold the code to them.
While I’m bearish on Beeper as a company1, reverse engineering iMessage and releasing a polished Android client is a big deal and impressive work. However, to nobody’s surprise, Apple fixed the security hole that allowed it and broke Beeper’s client within a couple days.
In response, Erik Migicovsky (Beeper’s founder) has been arguing that not supporting Beeper actually reduces iMessage security.
“I would be very interested to hear why they think that making security worse for iPhone users makes sense,” he said.
Of course, this triggered regulatory attention on whether Apple should be mandated to support Beeper.
Apple’s move to cut off Beeper, the app that brought iMessage to Android users, already caught the attention of U.S. Senator Elizabeth Warren, who called out the tech giant for anticompetitive behavior. Now, a bipartisan group of U.S. lawmakers is asking the U.S. Department of Justice to investigate Apple’s “potential anticompetitive treatment of the Beeper Mini messaging application,” noting that “interoperability and interconnections have long been key drivers of competition and consumer choice in communications services.”
Since then, lots of bytes have been spent debating the merits of opening iMessage to Android users. Beeper’s stance seems to be that they are doing Apple a favor by building an Android client since Apple has been unable to do so, such that not supporting said third party client is anti-competitive.
Let’s be clear, this whole debate is asinine. Erik must know he’s in the wrong, but is playing a game to make his startup viable via regulation. Suggesting that we should force any company to support third party clients to their service is an obviously bad idea if you care about security. Just because Beeper (probably) isn’t doing something shady with user data doesn’t mean Apple must be required to trust them.
What if I make a third party client that actively records my users’ iMessages and sells them to Facebook? Should Apple be required to support my app too? If not, are they expected to audit and vouch for every third party client? If yes, how is Apple supposed to make any claims about the security of iMessage if they have no control over the client my recipient might be using?
The whole interoperable API argument comes from the same place as “encryption where the good guys have keys,” a political pipe dream that anybody with technical experience can tell you is impossible. Yet somehow demands for interoperability seem to be much more popular.
The E2E in “E2E encryption” stands for end-to-end, which inherently requires trusting both ends. Otherwise you might as well not have encryption. Said another way, arguing for interoperable API’s is equivalent to arguing for encryption where only the “good guys” will have the keys. Of course only these hypothetical good guys will make clients for your interoperable API, right?
Note that whether or not companies should be required to support third party clients is a different debate than whether or not Apple should be required to support Android, even if the end result happens to be similar in this case. I think most people defending Beeper are interested in the latter and are willing to burn down encryption to get it via the former. As a user, sure I’d love for my Android friends to use iMessage too. But this is not the way.2
If Beeper’s goal is to finally destroy encryption via regulation, then this is a smart strategy. If not, I really hope somebody talks some sense into Erik or they run out of VC funding soon, and Erik can go back to advising other startup founders on what not to do.
Admittedly, I have my own stories of Erik Migicovsky and I happen to work on a community chat platform so I might be a little biased, but chat platforms compete by supporting different features and user experiences. Discord is not the same product as Slack which is not the same product as iMessage. Trying to treat each platform as a commodity backend for transferring bits by unifying the experience means you have to cater to the lowest common denominator, which by definition means the UX must be worse (either for Beeper’s user and/or for the other parties). It’s certainly a fun technical challenge and niche product category. It might even be a viable bootstrapped indie product, but trying to make it a VC funded startup by promising a “multi-billion dollar chat app” is a recipe for disaster for many reasons. ↩
To be clear, I don’t think we should regulate that Apple has to support Android either. If I develop a new OS, would every company be required to build a client for their service for my new OS too? But at least I understand the merits of that debate a little more. ↩