Here at ProgrammableWeb, we are often asked to provide consultative input to companies that are just beginning their journeys with APIs. As much as I love public APIs, I invariably tell these organizations not to start with a public API program. The idea that if you launch a public API, that all sorts of goodness will follow— everything from unanticipated innovation to massive new streams of revenue — is fool’s gold. I’m not saying “don’t take your API public” (even though, for many organizations, it’s still not a great idea). I’m emphatically stating “don’t start public.” The number of organizations that have really capitalized on public APIs pales in comparison to the number that have not (including those like Edmunds whose public API programs have been shut down).
But today, on the heels of news about concerns regarding the use of certain fitness technologies that could reveal confidential military troop and base locations, comes an entirely different spectrum of issues to consider before allowing for public or partner consumption of your APIs. I’ve yet to see these issues being discussed in the context of today’s news. But an industry-wide conversation across the API economy is certainly merited.
If you’re a fitness buff like I am, then you are no stranger to the application — Strava — being cited in today’s news as being one that potentially reveals important information about the location of military personnel. It’s important to note that there’s really no wrongdoing here on behalf of Strava. Strava is one of many web applications that can tap into the fitness data collected by a wide range of popular products from companies like Apple, Fitbit, Garmin, Samsung and Polar; products that millions of people including military personnel use.
As these devices collect information about your workouts, Strava picks that information up at the API level, aggregates it, and then provides you with summaries of your workouts including distances covered, the routes you took, calories burned, etc. Strava also takes the friction out of sharing this information with friends that also use Strava as well as friends on other social networks like Facebook. Today’s concern centers on a Strava feature known as a Global Heat Map.
The way the Washington Post put it, “The Strava app’s Global Heat Map shows blazes of light in cities with millions of users. But in war zones and sensitive sites, it is virtually dark except for scattered pinpricks of activity — presumably because American soldiers and personnel are using fitness trackers as they move around.” Thus, the heightened level of concern because, with military personnel bringing their own fitness devices to the job, the Pentagon can’t be certain what confidential information is being shared, when it’s being shared, and ultimately, who that information is being shared with.
But in my view, while the stakes are certainly very high for the military and no one involved can lose site of those risks, we’re talking about a series of issues that go well beyond troop and base locations. It involved all organizations and people and poses some incredibly important questions for all stakeholders in the API economy.
The crux of the matter lies at the intersection of the API provider, the third-party applications that consume that API, and third-party developer that built that application.
For example, take the ongoing controversy over antivirus solutions from Kapersky Lab. Millions of PCs including some government systems are (or were) protected by Kapersky’s solutions. In July 2017, Bloomberg reported that the Moscow-headquartered Kapersky Lab had been working with Russian Intelligence. Although the company pushed back on any allegations that it was some sort of pipeline of confidential information between Kapersky-protected systems and Russian intelligencia, the controversy was ratcheted to a new level of concern when it was learned that Russian hackers hijacked the Kapersky software found on an NSA contractor’s personal system in order to compromise classified material.
The response was swift. Kapersky’s solutions were banned from government systems. Organizations of all sizes switched antivirus providers. Just last week, Reuters reported that Facebook was phasing out internal use of Kapersky’s antivirus solution.
While Kapersky vehemently denies any wrongdoing, the bigger point that we really have no idea who we’re doing business with when we as organizations or people use software should not be lost.
Take Strava for example. While the company is probably perfectly innocent of any wrongdoing, how many of us thought twice about who owns Strava before downloading it and giving it access to a whole bunch of our personal information? Or who the company is connected to? Or where the company’s servers are? Or, what the company has done to secure it’s entire infrastructure or encrypt our data?
And that’s just the blind faith on the end-user side.
What about API providers like FitBit that offer a public API? Third party apps must be vetted by Fitbit before they make it into Fitbit’s new App Gallery and there are some strict terms of service that developers agree to during the developer onboarding workflow. But in all fairness, can we really expect Fitbit or any other API provider to do the sort of extreme vetting that flush-out a third party developer with nefarious intentions or demonstrably weak security?
Of course not.
It’s the soft-white underbelly of the API economy. On one end of the food chain, you’ve got API providers trying to activate a business model. On the other, end-users that will try anything with virtually wreckless abandon (especially if their friends are using it). In the middle? The applications and the developers behind them in which all stakeholders are placing absolute blind faith.
Such trust is going to get us into trouble if it hasn’t already. Money will be stolen. Secrets will be breached. People will die. All sorts of bad things will happen. Yes, technology and best practices — especially on the security front — can address part of the risk. But there’s only so far they can take us.
Which again, is why I say, don’t rush into public APIs. There’s no hurry to be a link in that chain. There are so many benefits that can be had and so many things that can be learned from starting with internal APIs and then maybe picking partner developers very carefully before you tread into the public API economy.