The ineffable iffiness of SMS
The Short Messaging Service has become the lowest common denominator for 2SV processes. At first pass it seems like a good idea with a useful side-effect, you get a valuable piece of information about your user which requires some form of real-world identity. The security reasoning seems sound too: SMS does not use the same channel as web applications, delivery is handled by the baseband OS not the primary OS so there is an additional layer. It almost makes one forget about the number one reason for using SMS, that it is almost universal.
As is obvious from the title of this post, I have come to bury SMS not to praise it. However, Wobe uses SMSes for registration and we are likely to continue to use it. But I don’t have to like it.
Lets start with the good. You don’t need to spend anytime researching whether your market has access to SMS. It does. Nor do you need to get your hands dirty with actually dealing with the baseband OS. You could use a service like Twilio or Nexmo and pretend that SMS is just a ReST API as far as your code is concerned. You could even outsource the whole problem of phone verification. Wobe is in the business of building a marketplace and all marketplaces are vulnerable to being gamed. It is harder for a seller to mount a successful Sybil attack when a unique mobile number is required for each account. Its not impossible or even particularly hard to circumvent this.
The bad is that when something goes wrong there is almost no diagnostic information. Many third-party providers have some form of delivery receipts. However, there are a multitude of failure modes. The Twilio API lists 10, Nexmo lists 15, including the catch all code 99. Below these failures is a rabbit warren of country specific rules. Note that these are legitimate failures assuming that you and your provider have done everything right. Some of the failures like Nexmo’s error 8 (EAGAIN), might require you to perform some processing at your end. This may become a problem when you are building a service at scale and the concept of user state becomes almost ineffable in a synchronous context.
The ugly is that it is pretty much the end of the road in terms of the SMS feature set. The problems with SMS aren’t going to get any better. If you are thinking of using SMSes globally, you must look at Twilio’s informative deliverability report and read Nexmo’s post on the top 5 reasons SMSes aren’t delivered. For something that was a bolted onto unused signalling capacity its had a good run. One wonders what Hillebrand and Ghillebaert think of the gallons of ink spilt over longer tweets.
It is easy to pour scorn on something, all it takes is a modicum of writing talent. Does this post have anything constructive in it? We are trying out Firebase messaging (erstwhile GCM) in our app. The use cases have a fair overlap with SMS and the interaction paradigm is suited to asynchronous services. We have not been using it long enough in production to write up a detailed technical report. As for whether one should trust Google, that question has been answered but do feel free to pick at old scabs in the comments.
