Welcome to my old blog, which I no longer maintain.

For details of my current professional services and activities see www.martingeddes.com.

April 5, 2006

Tulips for telcos

As I type, I'm in Schiphol airport in Amsterdam between flights on my way home from Washington. I used to commute here a few years ago, and now I remember why I;m not fond of this airport despite its convenience and efficiency. There's never a moment's peace and refuge -- the travelator is engaged in an endless Dutch announcement torture of "mind your step", and the PA system continually blares demands for late passengers to hurry up on flights 1/4 mile away from your gate.

(For Dutch readers, the good news is the rest of the country more than makes up for the deficiencies of the airport.)

Oh, and there's no Wi-Fi.

But the absence of opportunity to waste time checking emails and surfing the web does give me time to think. Imagine there was Wi-Fi. Rather than having to whip out my credit card, and all the transaction friction that involved (think: yet another expense receipt and line item), I'd much rather bill my Wi-Fi access to my mobile phone account.

Since I'm not using my mobile itself for access, my laptop can't authenticate to the network without my mobile operator issuing me some new stand-alone credentials. Not likely to be a pretty process.

Yet my mobile is in my laptop bag under the table. It has a Bluetooth radio. My laptop has a Bluetooth radio. Bits can in principle flow from A to B. There's no need for the authentication capabilities of my SIM card to be physically limited to the phone itself. In fact, it's a powerful "personal authentication artifact" that could, with a dab of extra technology, be useful in all sorts of contexts. Imagine if your car unlocks just because you walk up with your phone, for example.

In this case, one of the weaknesses of Bluetooth could become a strength. The standard is fairly vertically integrated, with no clean separation of connectivity from application service. (The illusion of connectivity is created by emulating a serial modem as a separate application service of its own. Not nice.) "Profiles" that support headsets, file transfer etc. are standardised centrally. It wouldn't be a big deal to create a remote authentication profile. Maybe there's one already -- heh, not that I can check, becuase I'm disconnected, remember?

The telecom industry offers a compact with the public. In return for slow innovation and high prices, it offers standardisation (not merely standards) and "super-distribution" where everyone gets to have interoperable stuff (at least in principle). It's a very different model to the bottom-up building of markets in the Internet model where everything is driven by competing ideas and incremental growth of adoption one-by-one until one idea dominates and becomes the standard.

A cartel? But it's hard to argue that there's no public benefit if we're deluged by a massive network effect of something the public really values. And since there's active competition from the other side of the fence by Internet players, there are market forces to keep the telcos honest.

This authentication moment is also interesting for another reason. It falls outside the Internet Protocol/stupid network paradigm (which only says how to exchange packets and demands you don't mess with them). Yes, there are protocols like 802.1 that enable authentication for IP networks, but it's not the same thing. If telcos can make business out of authenticating to all sorts of foreign networks, the "dumb pipe problem" just isn't relevant, and you've finessed it away by creating value along some other orthogonal axis.

It's these chinks in the Internet Protocol abstraction that offer light at the end of the tunnel for telcos: payment, location, identity, retail, distribution, logistics, support, and integration.

Perhaps I need a companion blog, Teleresurrection, to document this stuff!

Posted by Martin Geddes at 1:44 PM
Trackback Pings

TrackBack URL for this entry:
http://www.telepocalypse.net/cgi-sys/cgiwrap/mgeddes/MT/mt-tb.cgi/691