Lessons in Vendor Lock-in: Messaging

""

Is messaging really so complicated that you need five different messaging apps on your phone? Discover the reasons behind messaging vendor lock-in.

One of the saddest stories of vendor lock-in is the story of messaging. What makes this story sad is that the tech industry has continued to repeat the same mistakes and build the same proprietary systems over the last two decades, and we as end users continue to use them. In this article, I look at some of the history of those mistakes, the lessons we should have learned and didn't, and the modern messaging world we find ourselves in now. Along the way, I offer some explanations for why we're in this mess.

The First Wave

My first exposure to instant messaging was in the late 1990s. This was the era of the first dotcom boom, and it seemed like every internet company wanted to be a portal—the home page for your browser and the lens through which you experienced the web and the rest of the internet. Each of these portals created instant messengers of their own as offshoots of group chat rooms, such as AOL Instant Messenger (AIM), Yahoo Chat and MSN chat among others. The goal of each of them was simple: because you had to register an account with the provider to chat with your friends, once a service had a critical mass of your friends, you were sure to follow along so you wouldn't be left out.

My friends ended up using ICQ, so I did too. Unlike some of the others, ICQ didn't have a corresponding portal or internet service. It focused only on instant messaging. This service had its heyday, and for a while, it was the main instant messenger people used unless they were already tied in to another IM service from their internet portal.

The nice thing about ICQ, unlike some of the other services at the time, was that it didn't go to great effort to obscure its API and block unauthorized clients. This meant that quite a few Linux ICQ clients showed up that worked pretty well. Linux clients emerged for the other platforms too, but it seemed like once or twice a year, you could count on an outage for a week or more because the upstream messaging network decided to change the API to try to block unauthorized clients.

Proprietary APIs

Why did the networks want to block unauthorized clients? Simple: instant-messaging networks always have been about trends. One day, you're the popular IM network, and then the next day, someone else comes along. Since the IM network tightly controlled the client, it meant that as a user, you had to make sure all of your friends had accounts on that network. If a new network cropped up that wanted to compete, the first thing it had to do was make it easy for users to switch over. This meant offering compatibility with an existing IM network, so you could pull over your existing buddy list and chat with your friends, knowing that eventually some of them might move over to this new network.

The late 1990s and early 2000s were all about the cat-and-mouse game between these major providers. Linux users like myself ended up feeling the pain from this battle on the sidelines, because we often used multi-protocol chat clients like Pidgin and Bitlbee that use the libpurple library to allow you to talk to multiple chat networks from a single interface. Having a universal messaging application like this was convenient, but it also meant that from time to time, some of your friends would go offline for a week or two while the big tech vendors changed their protocol to lock each other out. At some point, a clever developer would figure out a workaround that made its way into libpurple, and you would be back in business.

Eventually, one of those platforms would lose too many users, and that IM network would go offline. Today, scrolling through the list of supported libpurple networks reads like a proprietary instant-messaging graveyard. Of course, through all of this, a universal messaging protocol appeared on the scene, and for a moment, it seemed like these bad-old-days of proprietary networks was over.

What's This Jibber Jabber?

The instant-messaging world was a mess of incompatible proprietary networks, and then one day, a chat client appeared that promised to fix everything for good: Jabber. Unlike other IM networks, Jabber's advantage was that it was free software and used an open IM protocol called XMPP. In addition to the fact that XMPP was an open protocol, it had another advantage. It was decentralized. With XMPP, you no longer had to worry about moving all your friends to a proprietary chat network that eventually would shut down. People with a few sysadmin skills could set up their own XMPP networks that could talk with all of the other existing XMPP networks.

Messaging isn't rocket science. After all the engineering effort, it's not like these proprietary IM networks were doing much innovating. In the end, they were all just re-inventing the same IM wheel—sending text, images and files with a new interface. With Jabber and XMPP, there was a universal, cross-platform and free IM network. With all of the basics solved once and for all, instead of re-inventing the wheel again, developers could focus on adding new and useful chat features with XMPP plugins. For instance, the OTR (Off the Record) plugin added strong encryption, authentication, deniability and perfect forward secrecy to XMPP messages.

For a while, it looked like XMPP was going to take off and become the new default cross-platform standard for IM, and we no longer would have to worry about proprietary companies coming in to re-invent the wheel just to lock users in to their platforms. Indeed, even Google used XMPP when it first created GChat, which meant that it was just another XMPP network—you could use any Jabber client to communicate with GChat users. Sadly, this era of open messaging standards wasn't meant to last, and it was the cell phone that arguably started a brand-new era of proprietary IM lock-in.

Just the Text, Ma'am

The advent of cell phones in everyone's pockets spawned a new era and platform for messaging. Instead of worrying about adding buddies to your buddy list, all you needed was to know someone's cell-phone number, and you could send them a message over SMS. At first, due to the limitations of typing on a number pad, SMSes were short with truncated syntax, but over time, phones started including either physical or virtual keyboards, and SMS quickly became the preferred way to send an instant message to someone else. Later on, the protocol was expanded, and MMS allowed you to send images as well as text.

There was only one real problem with SMS as a universal messaging platform, and that problem led to the new era of proprietary IM networks—cell-phone providers charged for SMSes. Each provider offered different plans and rates, with some charging per SMS, and others treating SMS like they did phone minutes, with different tiers included with a plan and overage fees if you went past your limit.

Once smartphones with data plans started to become the norm, those metered SMS plans provided an opening that proprietary vendors were waiting for to move the huge market of SMS users over to their platforms. How? By offering instant-messaging applications on the phone that took over your default SMS application. Then, if you and your friend both happened to use the same IM program, the messages would be sent over the vendor's network instead of SMS, thereby saving you the SMS fees. Of course, then you would be motivated to convince all of your friends to use the same IM app, and we would be back to where we were with desktop clients.

On Android, this launched the battle of SMS apps. In the browser wars, everyone wanted to be the default desktop browser, and during the SMS wars, everyone was including an SMS app in their suite of phone apps with the intention of being the default SMS app upon installation. As with desktop IM clients, the goal was the same: by convincing you to use their app and network, you'd also bring your friends along. Once you and your friends were all using the same app, you were locked in, since unlike switching away from SMS, switching to another app meant either bringing all of your friends along with you or falling back to metered SMS. Even Google abandoned GChat and launched one chat network after another, none of which seemed to take off.

Unlike with Android, the SMS war on iOS ended before it started. Because Apple controlled the OS and applications that showed up on the iPhone, it could make sure its own iMessage application handled SMS by default. This had the added benefit for Apple of further locking you in to the hardware platform and not just the application, since iMessage worked only on Apple's OSes. If all of your friends had iPhones, they got "free" SMS. Switching to Android meant you'd have to fall back to metered SMS.

The Current State of Instant Messaging

All of this leads to the current state of instant messaging: a mess. You have five different applications on your phone that you switch between depending on to whom you want to talk. When you do want to talk to someone, you have to remember whether you use SMS, Signal, WhatsApp, iMessage, FB messenger, Twitter DMs, Hangouts or any number of other messaging applications to communicate with that person.

Messaging isn't complicated. We solved this more than a decade ago. It's sending text, emojis and photos, perhaps to a group, ideally with end-to-end encryption. You have five incompatible messaging apps on your phone not from technical limitations, but because greed drives companies to ignore compatibility and optimize for vendor lock-in. Imagine having five different web browsers you had to switch between depending on which website you wanted to visit. If those same companies had their way, you would (and that's largely what phone apps have become).

So what's the solution? The solution is for people to realize the problem with this vendor lock-in and for the FOSS community to continue to push for and use open standards for messaging. Good-old XMPP is still around, and it works, and there's also Matrix if you want to try a newer open communication platform. Both offer clients for any platform you'd want, and you can find them on multi-platform chat clients as well.

Kyle Rankin is a Tech Editor and columnist at Linux Journal and the Chief Security Officer at Purism. He is the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks and Ubuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including at BsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.

Load Disqus comments

Subscribe now

 

Corporate Patron

Pulseway Logo

Limited Time Offer

September Cover

 

Take Linux Journal for a test drive. Download our September issue for FREE.