Interconnected vs. Non-Interconnected Text Messaging Applications: Yes, This Will Be Confusing

Unlike AT&T, I fully support the Commission’s action on text-to-911, but I think that Bob Quinn has a good point about the likely consumer confusion surrounding interconnected vs. non-interconnected texting apps. Due to the widespread use of phone numbers as IDs in non-interconnected apps, I think that some users might struggle to understand where they can text 911 and where they can’t.

I would bet that most people would think that non-interconnected services that allow you to send and receive text messages using your phone number as an ID count as “interconnected,” but they don’t. Phone numbers, like email addresses, are widely used as account names in third-party services that have no connection to the phone network. When you send a WhatsApp message to a “phone number,” even though WhatsApp has taken steps to make sure your phone number is really your phone number, you’re not using SMS or the phone network in any way. WhatsApp and similar services use phone numbers because it’s one less thing for people to keep track, because they’re all unique, and because it’s a handy way to bootstrap a contacts list, but a phone number in WhatsApp is no different than an IM username.

By contrast, something like Google Voice, which allows you to send and receive text messages to any number from third-party apps, web pages, etc, is an interconnected text messages application. On my iPhone I can send a text message from Google Voice to anywhere from my Google Voice number–I can even send SMS messages back and forth between Google Voice and the phone itself.

However, iMessage, an example Bob uses, is not an interconnected text app, as I see it. That’s because iMessage lets you send and receive iMessages with iMessage users, including using a phone number as an ID, but as a fallback, it is just an SMS app itself, using the phone’s native SMS capability. (The well-known problem where people stop using iMessage and stop getting messages of any kind from some people happens because other iOS devices sometimes don’t do the “fall back” step when they should. This is another problem with using phone numbers as IDs on private systems.) You cannot send an SMS from iMessage on an iPad or Mac. (Though, to make things more fun, iOS 8 and Yosemite further complicate this by allowing iPads and Macs to relay SMS messages to and from an iPhone over a local network. Yet it is still the iPhone that is doing the actual SMSing.) So iMessage either is a non-interconnected text messaging application or it simply is vanilla SMS–a third category is only necessary for applications that allow you to send SMS messages from something other than a phone, or by using something other’s than your phone’s native capacity. Even a third-party app that allows you to natively send and receive SMS messages is not an interconnected SMS app if all it is doing is providing an interface to your phone’s existing SMS capacity.

Many apps, such as Open Whisper Systems’ TextSecure, work like this. Android allows you to use a custom app as your phone’s SMS app, and it’s straightforward for an app to use SMS as a fallback while sending the messages it can through a private, non-interconnected network, as TextSecure does. Open Whisper similarly has apps that let you place and receive encrypted “phone calls” with your “phone number,” yet those apps are not interconnected VoIP, either. Again, they are simply using your phone number as a handy unique identifier.

What can be done about this? I really have no idea. I would prefer if apps just didn’t use phone numbers as IDs, so that it was easier for people to see the distinction between PSTN/phone/SMS messaging (universal, standard, perhaps slower to evolve) and private messaging systems. I think there is a place for both kinds of services. But that horse has bolted. The current received wisdom is that using existing identifiers on a new services (phone numbers, email addresses) is the simplest and best approach despite any confusion it might cause (and, in the case of phone numbers, the unpredictable ways different services handle it when users get a new phone and number, or try to use the service on multiple devices simultaneously).

Another approach might be to require that all messaging apps that are running on phones have the capacity to fall back to SMS, at least when people try to message 911. This might be possible under the FCC’s ancillary authority or some other theory though a statute might be clearer. But, this wouldn’t address what happens when people try to send such messages from tablets or other devices that lack in-built SMS functionality–should applications also have the ability to send and receive texts server-side the way that Google Voice (and a million “free texting” services) do?

One final problem relates to location. A network operator has a much surer idea of a user’s location on a wired or wireless network than an application, which generally can only try to guess based on some correlated information which may be inaccurate (e.g., IP address) or perhaps through some other means such as a phone’s built-in location services API. It is difficult to see how to push emergency functionality solely into applications without some means of applications receiving non-spoofable location information from the network.