Considering Net Neutrality and API Access

[This article was written by John Mueller.]

 By now, you’ve heard a lot about net neutrality. The FCC has voted to classify Internet service providers as Title II common carriers. ISPs no longer have the right to provide preferential treatment to some customers or to throttle bandwidth for others. The FCC now has all sorts of means to ensure everyone has equal access to the Internet, or do they? Of course, that’s just one of the questions the FCC must answer because there isn’t any clear way to enforce the rules (interestingly enough, several sites for testing net neutrality have sprung up so that you can check access speed against several servers). In addition, some carriers are fighting back by reducing planned service expansions. You can expect lawsuits and all sorts of analysis by various industry pundits as everyone tries to figure the situation out. In the meantime, you have an application to build and that means having access to APIs. The problem is that no one is really talking about your needs or your rights as a developer, which means that you might not even have a clear idea of how the vote affects you.

Gaining Access

A problem you need to consider is the whole issue of what equal access actually means. According to various sources, equal access will mean that if you pay for a particular connection type that you’ll have the same access to it as anyone else with that connection type. However, if you pay for a connection with a higher quality of service, than you’ll actually have better access than someone with a lower quality of service. Likewise, if you pay for a high-speed connection, then you’ll be able to transfer information faster than a low-speed connection. Therefore, it’s not precisely the same sort of access provided by a telephone carrier, as some people would lead you to believe—it’s not as if everyone will have precisely the same access. The term, equal access, means equal as long as you pay for a particular kind of connection that someone else also purchases. The speed of the connection still determines application speed and quality of service still determines application reliability.

Net neutrality also doesn’t affect API neutrality. If an API provider decides to provide discriminatory access to a competitor, you can’t do anything about it. For example, the new ruling wouldn’t affect business decisions such as the one in which Twitter cut off Tumblr from its API. The net neutrality ruling is akin to providing open access to the streets and sidewalks connecting houses in a town. Anyone can walk up to any house and knock on the door. However, the house owner (the API), still controls whether you can enter the door and access the house. If an ISP wants to make net neutrality difficult, it could still buy up APIs and force discriminatory access outside the FCC ruling (and it could very well happen).

Impacting Access Speeds

You’re sitting in traffic. Suddenly, you hear sirens. It takes an abnormally long time for the sirens to arrive, pass, and go on their way. You notice that no one gives the emergency vehicles the right of way—everything proceeds precisely as it did before the emergency started. In the meantime, a house burns down. The fire trucks could have saved it if they had only gone at a faster speed, but they kept to the same speed as everyone else. What’s wrong with this picture? It’s what happens when everyone has precisely the same access to the road and the FCC has to consider the problem as part of implementing net neutrality.

There is some concern about equal access as defined now, even if all of these other factors work out perfectly. The problem is that some applications do require high-speed access. For example, an application that monitors someone’s health or the code required to make self-driving cars possible are two examples of critical applications that require preferential treatment. Unfortunately, the new ruling doesn’t allow such treatment, so there is a potential for push back when users begin to understand the ramifications of equal access. More importantly, the fact that the emergency vehicle-like calls from certain applications have the same access as everyone else means that lives could be lost and companies will most definitely lose money.

Creating Reliable Connections

Reliable access and access speed are two essential goals for net neutrality. Yes, you need both for any application you develop, especially when that application relies on a number APIs. However, of the two, reliable connections are probably the more important. You can advise users about slow connections and it’s less likely that you’ll receive a torrent of complaints than when the application fails completely. However, like everything else about net neutrality, the reliable connection only refers to the connection between your application and the API. The owner of the API still has the final word as to whether you obtain the answer to a query. Given that some vendors may choose to boycott net neutrality with shutdowns and other perfectly legal measures, you want to check with your API provider to ensure the API will remain reliable even while net neutrality is contested in the courts.

Avoiding Censorship and Discrimination

Many people associate censorship and discrimination with free speech. However, both occur with all sorts of data. A competitor could want to cause unfair slowdowns for any data that mentions your product. Perhaps the packets will simply disappear en route to the API for processing. ISPs could decide to block any data that a competitor might find useful or simply deny access to the competitor. All sorts of scenarios come to mind—all of them bad for your application. Net neutrality is supposed to protect against censorship and discrimination and it’s possibly one of the areas in which it will succeed best because both issues become obvious quickly, are easy to document, and are relatively easy to enforce.

Bottom Line

Some developers are viewing net neutrality as a sledgehammer applied to situation best answered with a screwdriver. The main push appears to have come from a lack of choice for consumers and the FCC’s desire to keep broadband providers in check. However, the decision affects everyone. If you write applications that rely on third party APIs or require Internet access to interface with any online entity, the decision affects you directly. Even in those situations where you aren’t affected directly, you’ll end up paying the price when it comes to working with others that do. API access won’t be the same for some segment of the market with net neutrality in place and it’s a good idea for you to determine precisely what that affect will be. In short, you need to test application speed and reliability once the net neutrality rules are completely implemented to assess the effect on your applications and determine how users will react to those changes.