Why Telco APIs Aren’t as Simple as Web APIs

September 24, 2013

The telecom industry needs to treat APIs with the sensitivity of a finance industry.

If you don’t have an API as a business these days, then how are you going to integrate your service? Put another way, how can you build an ecosystem with all the nice marketing words of “creativity”, “innovation” and “value creation” without an API program?

It makes perfect sense then why carriers are moving into this space as well. Most known are probably Telefonica’s BlueVia, AT&T’s Developer Program and Deutsche Telekom’s Developer Garden. The industry seems ripe for some change in Telco APIs, and that is also notable by the events like Telecom Application Developer Summit (TADS) and Telecom APIs event just around the corner.

I’ve been looking into this space as well, on and off, trying to decide what secret formula can carriers use to get developers to use their APIs instead of the ones they get on Android and iOS. Not an easy question to answer.

One of the things that I usually bump into at the end of the day, is the information the carriers have on their subscribers and the behavior of their network and how that can be used. And that means taking security seriously:

  1. Apple can release a new iOS version with a security flaw enabling bypassing the lock screen – the effects of such a flaw is limited to a user at a time by a hacker/thief. A carrier with such a flaw opens the door to his millions of subscribers for a single hacker.
  2. Apple can also work faster on fixing such issues and deploying them than a carrier can patch up his network for similar flaws.

There were several interesting news items that caught my eye this month around security, APIs and telcos that I wanted to reflect here:

Vodafone got hacked. 2 million subscribers affected

This one comes from BusinessWeek, where Richard Weiss writes:

An intruder hacked into a Vodafone Group Plc (VOD) server in Germany, gaining access to 2 million customers’ personal details and banking information.

A person with insider knowledge stole data including names, addresses, birth dates, and bank account information, the world’s second-biggest mobile-phone carrier said in a statement today.

Not related to APIs, but APIs enable such large scale hacks to happen, so every API in question needs to address security properly.

Private API?

George Reese writes in O’Reilly about the myth of private APIs:

The flaw I exposed in the Tesla API results from Tesla placing the burden of managing authentication credentials entirely on the shoulders of end users. […] Tesla has no responsibility to make an unpublished API secure against third-party malfeasance or misfeasance.

If you think there’s something like an undocumented API and that that API can be left unsecure, then you are wrong. APIs will be found by developers, especially if your service is successful (I guess that’s the goal). When carriers start exposing their innards, they need to make sure that nothing gets past their security.

As a side note, I tried opening up in Google Drive a spreadsheet and have its URL configured as “visible to anyone with a link”. Within 5 minutes, there was another person viewing my spreadsheet – without me sharing the link in any way.

Don’t assume that things that aren’t documented don’t get accessed.

iPhone’s secure enclave

Smartphones, our most private devices got upgraded by Apple lately, and it isn’t just the Touch ID gizmo. It is more into how the innards of the phone now work with something called a “security enclave” which can be used to segregate data access in specific areas of the phone via hardware.

Don’t ask me what that means – just read Brian Roemmele’s answer on Quora.

These security measures that are taking place need to be done on both ends, especially for carriers adding payment APIs.

What strikes me as most interesting is The World’s Biggest Data Breaches on Information Beautiful. Would you want your company to have a large and intimidating circle in there?

data breaches

You may also like

Comment

Your email address will not be published. Required fields are marked

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}