The Federal Trade Commission is sueing Facebook, alleging that they are illegally maintaining a monopoly on the personal social network space using a continued series of anticompetitive behavior. The suit includes a coalition of attorneys general of 46 states, bringing the latest wave of regulatory scrutiny into the social media platform, highlighting three main dimensions of how Facebook has engaged in a systematic strategy of anticompetitive practices that has resulted in their current dominant position online.
- Instagram - Facebook purchased Instagram to remove what they saw as one of the biggest threats they faced, while also purchasing market dominance in the image and photos sharing space.
- WhatsApp - Fsacebook purchased WhatsApp to remove what they saw as one of the biggest threats they faced, while also purchasing market dominance in the messaging space.
- API - Facebook used their API to cut off access to applications they saw as a threat, and to generally suffocate anything else they saw as a threat to their business model.
The anticompetitive nature of Facebook’s Instagram and WhatsApp purchase isn't really in my wheelhouse, but how the API was used for anticompetitive activity most definitely is my speciality. I am happy to see the FTC finally elevate the abuse that has been going on at Facebook via it’s APIs, not just because of the impact on the Facebook developer community, but more importantly the wider tech sector. Facebook’s approach hurts wider competition across the tech sector, but also hurts the space API sector--ultimately giving APIs a bad reputation. To help me speak intelligently to what is occurring as part of the FTC’s lawsuit, offer my advice on what a remedy might be, while also contributing to the future of regulation in the tech sector, I wanted to gather my thoughts in a post here on the blog.
Anticompetitive Conditioning Using The Facebook API
The acquisition of Instagram and WhatsApp by Facebook to neutralize threats in two keys areas are a critical part of this filing and Facebook’s strategy to dominate, but it is their API that has the biggest impact in suffocating out competition in the areas of photos and messaging, but every other dimension in which other companies can compete with Facebook via their own API. I think the FTC filing sums it up best in section 22 with the phrase “anticompetitive conditioning”
22. Anticompetitive Conditioning. In addition to its strategy of acquiring competitive threats to its personal social networking monopoly, Facebook has, over many years, announced and enforced anticompetitive conditions on access to its valuable platform interconnections, such as the application programming interfaces (“APIs”) that it makes available to third-party software applications.
This sums up the slow roll suffocation of competition that exists as part of the politics of APIs across not just Facebook, but also other leading platforms via their API ecosystems. Companies who view their API developer ecosystems as an asset use the API management layer of their APIs to incentivize developers, where companies like Facebook who have reached a size and scope where they view a significant portion of their API consumers as a threat will choose to engage in widespread anticompetitive conditioning via the management layer of their APIs.
Removing Facebook API Access for the Competition
The FTC filing focuses on the most overt and visible anticompetitive behavior from Facebook at the API layer, in particular the turning off of access to API consumers when they are viewed as a threat to their platform business. It is commonplace that API consumers have to register and obtain keys for access to API resources. This is a known aspect of API management, the API provider and consumer dance on Facebook and beyond, and it is common to revoke the API access keys of consumers who violate your terms of service. However, many API providers like Facebook also use this practice to “condition the competition”. The FTC filing focuses on two main consumers who Facebook cut off access, first in section 153 with Path.
153. First, Facebook targeted promising apps that provided personal social networking. For example, Facebook took actions against a personal social networking competitor, Path, which was founded by a former Facebook manager. In or around April 2013, Facebook terminated Path’s access to Facebook’s APIs, and Path’s growth subsequently slowed significantly.
After Path, there was another high profile competitor (Twitter) that was moving into their territory, which the FTC filing outlined in section 155.
155. Similarly, in January 2013, Facebook’s Director of Platform Partnerships and Operations wrote to colleagues: “[T]witter launched Vine today which lets you shoot multiple short video segments to make one single, 6-second video. As part of their NUX [new user experience], you can find friends via FB. Unless anyone raises objections, we will shut down their friends API access today. [W]e’ve prepared reactive PR, and I will let Jana know our decision.” Mr. Zuckerberg replied: “[Y]up, go for it.” By cutting off Vine, Facebook prevented it from accessing APIs that would have helped it grow.
Path and Vine were just the tip of the iceberg when it comes to Facebook’s campaign to cut off access to competitors when it came to their APIs, as the FTC filing outlines in section 156.
156. The third group of targets were promising apps that offered mobile messaging services, that were existing competitors of Facebook Messenger, and that ultimately threatened to develop into competitive threats to Facebook Blue. Throughout 2013, Facebook blocked mobile messaging apps from using commercially significant APIs. For example, in August 2013, Facebook undertook an enforcement strike against a number of messaging apps simultaneously, with the Head of Developer Enforcement directing colleagues to restrict them from “accessing any read APls beyond basic info[,]” instructing that “we will not be communicating with the [developers] in any way about these restrictions.”
This reflects direct action taken by Facebook to snuff out the competition by removing access to their increasingly valuable resources by the competition. It becomes much more difficult to measure the indirect chilling effect all of this had on developers within the Facebook API ecosystem who would self-censor, and avoid developing applications that may get the attention of Facebook, even if they weren’t directly competing with the giant. Sometimes you just didn’t know if what you were building was emulating Facebook features and it would be better to just not build your application at all.
Anticompetitive Tones Set By API Terms of Service
The terms of service (TOS) for API platforms always set the tone for engagement between API provider and consumer, but it is something that Facebook has wielded with great success when it comes to their anticompetitive practices across their developer community. There are several consecutive sections of the FTC filing that highlight the chilling effects TOS changes have had to the Facebook developer ecosystem,
138. From July 2011 until December 2018, Facebook publicly announced and imposed a set of anticompetitive conditions governing access to Facebook Platform.
139. On July 27, 2011, Facebook introduced a new policy that “Apps on Facebook may not integrate, link to, promote, distribute, or redirect to any app on any other competing social platform.”
141. Following that, Facebook imposed several other policies restricting app developers’ use of Facebook Platform, including Facebook APIs. Through these policies, Facebook used its control over APIs to deter and suppress competition.
142. September 2012: no exporting data to competitor social networks. On September 12, 2012, Facebook introduced a new policy: “Competing social networks: You [developers] may not use Facebook Platform to export user data into a competing social network without our permission[.]”
143. January 2013: no promotion / data export to any app that “replicates a core Facebook product or service.” On January 25, 2013, Facebook added a new condition to prevent developers from “replicating core functionality” (i.e., competing with Facebook), or assisting others who might do so: Reciprocity and Replicating core functionality: (a) Reciprocity: Facebook Platform enables developers to build personalized, social experiences via the Graph API and related APIs. If you use any Facebook APIs to build personalized or social experiences, you must also enable people to easily share their experiences back with people on Facebook. (b) Replicating core functionality: You may not use Facebook Platform to promote, or to export user data to, a product or service that replicates a core Facebook product or service without our permission. (Emphasis added.)
These types of TOS practices make for a very confusing environment within the Facebook developer ecosystem. As a developer using the API to develop an application you are faced with the task of trying to speculate on what constitutes a competing feature and what does not in a very fast moving sector. It also gives Facebook a pretty wide spectrum to choose from when it comes to determining which API consumers have violated their TOS, and which have not. Making for a pretty fraught relationship when it comes to building on the Facebook platform, and a pretty terrifying uphill battle when it comes to actually taking on the tech giant when it comes to any aspect of their current or future business.
The Role APIs Have Played in Facebook’s Dominance
The FTC filing does a great job outlining the role that the API community has played in Facebook’s evolution as a platform, and the role the platform plays in developing web and mobile applications across almost every business sector. As outlined in section 135 the API community was the vehicle for Facebook growth over the years and resulting dominance.
134. Further, third-party apps helped Facebook grow and provided other forms of value to Facebook by promoting Facebook around the internet, via the Facebook plug-ins and by directing social data, such as “Likes,” back to Facebook Blue. Since launching its Facebook Platform and Open Graph initiatives, Facebook has grown significantly, adding at least 150 million monthly users each year and serving over 2.7 billion monthly users worldwide today.
In the early years of Facebook, as with any platform, they needed their API developer community to build out new features, and deliver critical integrations with other platforms. But as the power of Facebook grew, it slowly, and then more rapidly began to assert the power it has over the trajectory of applications being developed by the community, as outlined in section 135.
135. With the success of Facebook Platform, Facebook became important infrastructure for third-party apps and obtained immense power over apps’ developmental trajectories, competitive decision-making, and investment strategies.
Fully aware of it’s increased power, and growing even more hungry for power, Facebook would begin to see innovation within its own community as a threat, rather than an asset as it had in earlier days. Weaponizing the very thing that had helped it grow from the tech giant it is today, eliminating anything it saw as a threat within its own community.
151. Moreover, Facebook knew and expected that API access was sufficiently important to affect the incentives of developers and the developmental trajectories of their apps. Developers were incentivized to make decisions that would not jeopardize their access to Facebook’s APIs. An internal Facebook slide deck dated January 2014 dealing with Facebook Platform policies directly acknowledged the importance of API access, asking whether Facebook was “[c]omfortable altering / killing prospects of many startups[.]”
In the early days of any platform your API management layer is designed to secure your digital resources, requiring developers to register and obtain access keys before they can begin making API calls from their applications. API management is about striking a balance between API provider and consumer, agreeing to fair and equitable terms of service, as well as sometimes a price for providing access to digital resources and capabilities. It is how much of the growth we’ve seen in Facebook, Twitter, and other leading platforms has been built out, but once a platform has seen enough growth, investment, and power accrue, there always seems to come a time where leaders begin to see the community as a threat--which is something Facebook has taken to entirely new levels.
The Weaponization of API Change Management
One of the greatest challenges any online platform or digital service will face comes in the form of managing change. Platform code and APIs are perpetually evolving, requiring some fairly advanced strategies for dealing with change using a well planned road map, while also actively addressing technical debt that accrues as part of legacy code that must be either evolved or deprecated. Version control is one way that platforms help manage and communicate change when it comes to making resources available via web APIs, helping manage the forward motion of a platform, while keeping API consumers moving along at the same speed. Change management is something Facebook has employed, but due to the overall tone being set by their leadership, they have also managed to weaponize something that is usually not so politically charged, as outlined in section 146.
146. May 2014: Platform 3.0 launches. A new approach—dubbed Platform 3.0—launched on May 2, 2014. At that time, Facebook terminated all apps’ access to certain APIs, which included restricting third-party apps from accessing information about their users’ friends who were not already using that third-party app.
Major releases are not that unusual, but deprecating legacy resources and forcing developers to migrate to a major release is less common. Versioning and change management is something that is hard under any circumstance, requiring a great deal of communication between API provider and consumer. It is something that is often further balanced by giving developers an extended period of time to make a migration, before older APIs are deprecated. Facebook is notorious in the API industry for committing many of the sins that we collectively agree upon in the industry should be avoided when it comes to striking a balance in our API ecosystems.
- Communication - Facebook long has a reputation of poor communication around it’s releases, ensuring API consumers are prepared for the future, and are given enough time to evolve their integrations to keep pace with the removal of services. Communication is essential for helping keep an API developer community moving at the same pace as the platform, and is something that can easily be weaponized when it comes to keeping some partners informed of what is happening, while keeping others in the dark, making it difficult for competitors to keep up.
- Velocity - Mark Zuckerberg crafted the phrase, “Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.” This mantra is reflected in how they run their APIs, moving fast, making lots of changes, and quickly disposing of technical debt. This is something that makes it difficult for the API developer community to keep pace with, especially without proper communication and notification of what the future may hold.
- Breaking Changes - One of the core tenets of API development is that you do not introduce breaking changes in the design of your API with a release, unless it is deemed a major release (ie. 1.0, 2.0, 30). Again, Facebook is notorious for releasing mysterious breaking changes as part of their release process without much communication between why, breaking integrations along the way. When you are the one breaking things it is easy to make sure your applications and integrations keep up, but if you aren’t, your applications are always going to be left behind and be unreliable.
- Deprecation - API providers have different views of how long you keep older versions of APIs around before you deprecate them. Google often gives 18 months, while others will support in perpetuity -- I believe Salesforce still supports many of its original APIs. However, Facebook regularly deprecates older versions of APIs shortly after the release of a newer version, giving developers months, weeks, or no notice before an API disappears, as Facebook did with their Audience Insight API in 2017, giving no heads up that the controversial API would disappear, something you won’t find in their road map or change log -- it just went away after regulatory scrutiny.
Being able to deal with change is how you remain competitive. Weaponizing change on your platform so that you can punish and introduce friction for competitors is how you unfairly stay ahead in a fast moving game. Facebook’s anticompetitive practices were not limited to cutting off access to APIs, and setting an anticompetitive tone within the API community. It is also about weaponizing change and making it impossible for not just the competition to keep up, but also making it difficult for other application and integration developers to even get a foothold with their new and novel contributions to the market--something that hurts everyone, including Facebook.
Finding a Remedy for Anticompetitive Behavior at the API Layer
Facebook’s anticompetive behavior is not original. It is a common abuse amongst platforms, and something I’ve seen and written about numerous times over the last decade. Facebook’s sins can be also seen on Twitter,and other platforms whose business models rely on advertising, rather than subscription or more direct approaches to revenue. The stakes are always higher when a platform is built using user-generated content and monetized via eyeballs and engagement. These are always the platforms whose APIs are wide open in the early days, and become more locked down and exploitative once the value, importance, and investment increases. APIs are a great way to build a platform, while incrementally over time ensuring that all or most of the value flows in your direction, and exploiting developers and end-users for the labor needed to generate all of the value.
As stated by section 29 in the FTC filing, Facebook has been savvy in backing off or at least being more secretive about some of its anticompetitive practices, and even if there are repercussions for their acquisition of Instagram and WhatsApp, there is nothing stopping Facebook from continuing with their strategy, and finds ways to morph their anticompetive behavior by obfuscating it at the API layer.
29. Today, Facebook’s course of conduct to unlawfully maintain its personal social networking monopoly continues, and must be enjoined. Facebook continues to hold and operate Instagram and WhatsApp, and continues to keep them positioned to provide a protective “moat” around its personal social networking monopoly. Facebook continues to look for competitive threats, and will seek to acquire them unless enjoined. Likewise, Facebook’s imposition of anticompetitive conditions on APIs continued until suspended—at least for the time being—in the glare of attention from governments and regulators around the globe. Facebook will resume those policies or equivalent measures unless enjoined.
Facebook is in the business of constant evolution. It will keep morphing and evolving its strategy for dominating the personal social network, photo sharing, messaging, and any other dimensions it sees a key to its success. Facebook’s API layer has been how the platform has done this in the past, and it will be key to how it does it in the future. APIs are how Salesforce, Amazon, Google, Twitter, and others have built their platforms, and it is how they, and other tech platforms deal with change, remain agile and nimble, and remain competitive in a digital landscape. To help make sense of this fast moving, ever changing digital landscape you have to use the same tools that these platforms are employing to make sense of what is happening. You have to employ the very same tooling Facebook and these providers are using to their advantage, tapping into the APIs, and more specifically the API management layer that already exists to begin stabilizing the Internet using regulation in the same ways we stabilized energy, telecommunication, automobile, and other critical industries our economy and society depends upon.
A Quick Primer on API Management
The infrastructure Facebook uses to manage developer access to their APIs is widely known as API management infrastructure across the tech sector. API management began as a formal approach to managing API consumption in 2006 with the introduction of a startup called Mashery, which was eventually sold to Intel, and then to Tibco. Shortly after Mashery launched a wave of API management providers emerged to help companies secure and manage APIs at scale. After some consolidation of API management providers by 2015, API management has quickly become something that is baked into the fabric of the cloud, and is a fundamental offering on Amazon Web Services, Microsoft’s Azure, Google, IBM, and other cloud infrastructure platforms.
API management is how you secure your digital assets and capabilities as an enterprise organization. It is how you strike a balance between making these resources accessible on the Internet and being able to retain control over who has access to these resources and the value that is generated around them. API management is defined by a couple of key features that you will find played a key role in shaping Facebook’s anticompetitive strategy.
- Accounts - Every developer is required to signup for an account if they expect to have access to an API, providing a minimum of name and email before they can gain access to any valuable API resources.
- Applications - Every developer is required to submit a definition of their application, providing a name and description of its purpose at a minimum, outlining what each developer will be building on top of an API.
- Keys - Once an account and application is approved, a set of keys are issued to a developer. These keys must accompany every request made to an API, providing essentially a user and password that authenticates a user, but also can be used to aggregate and report of usage by each developer.
- Plans - APIs can be organized into different access tiers or plans by the API provider. Providing a way to standardize access to digital resources and capabilities by different groups of API consumers. Defining what can be accessed by consumers, and what the business model (or lack of one) that will exist as part of the agreement between API provider and consumer.
- Rate Limiting - All API access is rate limited, allowing consumers to only access what their plan or access tier will allow. Ensuring that API consumers don’t overuse and abuse access to digital resources, without it being in alignment with the platform's goals, while also protecting end-users.
- Logging - All API calls are logged, including the API consumers keys used to make each call, and the fingerprint of the application behind the consumption. Keeping a record of every call made to each API, and the consumer application behind each request.
- Reporting - API management is all about providing awareness of who is accessing what API resources, allowing both the API provider and in some cases the API consumer a dashboard of how APIs are being put to use, which resources are being access, and a whole range of other data points that are gathered on a regular basis as part of API operations.
API management isn’t some new technological trend. It is a fundamental part of the cloud and how digital resources are made available in web, mobile, and device applications today. It is how digital resources are made available, while also keeping API consumers honest about how they are putting digital resources to work in their applications. API management quantifies and helps us visualize the value that is generated via platforms, measuring API activity in real time. API management is used to strike a balance with your API developer ecosystem, keeping a platform growing and evolving. It can also, as Facebook has demonstrated, be used to identify threats within your own ecosystem, then shut down or at least introduce friction into the applications you feel are a threat to your operations, making API management where you pull the knobs and levers of your anticompetitive digital strategy.
API Management Driving Anticompetitive Behavior
I have been studying APIs and API management for a decade now. I have seen this layer of platforms be used in many creative and innovative ways. I have also seen this layer of platforms be used in many anticompetitive ways. The API management layer is how Facebook sees the threats that exist on it’s own platform, and ultimately how it punishes it’s competitors. The API management layer is how Facebook requires API consumers to agree with it’s terms of service, and how it enforces it’s TOS. It is where Facebook decides to deprecate older versions of it’s APIs, while forcing everyone to migrate to newer versions. The API management layer is how, as the FTC filing states, Facebook is applying the anticompetitive conditioning portion of their business strategy. While the acquisition of Instagram and WhatsApp are the most visible outcomes of Facebook’s anti competitive strategy, the API management layer is where most of this behavior is playing out, and it where it will continue to morph and shape shift its strategy in coming years.
Lack of Observability Around API Access Onboarding
Facebook knows exactly how many developers it has access to their APIs. They also know exactly how many applications are accessing their APIs. The wider Facebook community, and government entities have no visibility into who does or does not have access to Facebook resources and capabilities via their APIs. There is no official accounting of who uses Facebook APIs outside of Facebook, helping shine a light on which countries applications operate in, what industries they are applied to, or any other insights about what the landscape, let alone the competitive landscape looks like across the Facebook ecosystem. All of this information exists at the API management layer within Facebook, it is just that there is no motivation for Facebook to share this information with the public, or with regulatory authorities.
Lack of Observability Around API Access Termination
Like onboarding with APIs, there is no observability into who gets their access to the Facebook APIs terminated. There is no accounting of who was terminated or why. All of this information exists at the API management layer at Facebook, but there is no incentive for Facebook to share this publicly or with regulators. There is no official accounting of who loses access to Facebook API, or whether or not this termination was justified or fair. There is no due process or official approach to contesting your loss of access to Facebook APIs. It is completely up to Facebook to terminate, and up to them whether they want to provide a reason, or whether the reason was honest and fully communicated. The API management layer provides us with everything we need to quantify whether Facebook, or any other platform is being fair and balanced in the termination of access to their APIs, we just need the will to make it available.
Observable Regulatory API Management as a Remedy
The answers we are looking for to help us understand in an ongoing way if Facebook, or other platforms are engaging in anticompetitive practices via their platforms exists today within the API management layer. The only thing lacking is that platforms are not compelled to make the outputs of their API management layer observable by outside interests. There is a precedent in the United Kingdom for a more observable regulatory version of API management, within the banking industry The UK government mandated that all banks adopt a set of standardized APIs across common resources like ATM locators, bank account, and credit card APIs, while also participating in an API management layer that is operated by a neutral entity, which brings the following elements to the regulatory table.
- API Definitions - Providing the definitions for each of the digital resources and capabilities being made available via APIs, so that which APIs are made available, as well as each version, are agreed upon in the interest of everyone involved.
- Accounts - API account signup and login are managed by a neutral authority, providing observability into who all of the actors are, as well as who onboards or is terminated as part of the regular goings on across the API ecosystem.
- Authentication - The authentication by developers with APIs is handled using a common set of industry standards as defined by the neutral entity, ensuring that all access is secured using common standards, and consistently applied across all APIs being regulated.
- Discovery - A directory of all API consumers is available, making a subset, as well as summary data available publicly, but also providing discoverability to regulators and other government stakeholders when it comes to defining the landscape of an API community.
- Management - The API management layer is standardized and externalized as part of the regulation of APIs. Each API provider, banks in this case, are required to implement the management layer as part of their operations, but the definition and oversight of what is API management is agreed upon and reported upon by the central body.
- Dispute Resolution - When API access is terminated, or other challenges arise within the API ecosystems, the central body provides dispute resolution between the provider and consumer, helping bring observability but also standardization and fairness to the discussion around termination or continuing the access to API resources by applications.
API management provides us with many of the controls we need to put in place to help regulate the API access to digital resources and capabilities--it is how leading platforms have gotten where they are. We also have a precedent for how this ubiquitous approach to managing APIs can be externalized and run in a neutral way through a public and private sector partnership. We have the makings for a pretty straightforward approach for helping prevent Facebook from engaging in the same anticompetitive behavior they have been engaged in for the last decade--we just need the will to properly begin regulating the tech industry using their own infrastructure.
Adding a Government Access Plan to API Management
API management service providers deliver their API provider customers with a dashboard, and ironically, API access to this layer of their infrastructure. Meaning there is an API for accessing the logs behind who is accessing APIs. There is no reason that a regulatory access tier could be added to the API management layer by default, providing a summary of what is going on across a platform. This can be done in a way that protects the intellectual property of a platform like Facebook, as well as the privacy of end-users. It can be done in a way that doesn’t impact the performance of applications, or introduces friction into the already challenging work API developers encounter each day. All of the answers the FTC seeks to understand if Facebook is continuing to engage in anticompetitive behavior already exists, we just lack the API management plan to give them the access they need.
Adding a Researcher Access Plan to API Management
Facebook is going to continue to innovate, move fast, and break things when it comes to their platform, and API ecosystem. The company has made it clear they have very little interest in changing their behavior, and have only gotten better at apologizing and obfuscating along the way to stay off the radar of regulators. Even if regulators did impose a more observable approach to API management, Facebook is going to continue to innovate in how they reward partners and punish competitors when it comes to doing business on their platform. The pace and speed at which Facebook and other platforms move it will be also necessary to mandate a research plan at the API management layer where approved researchers can gain access to platform wide digital resources access and usage at the API management layer. Allowing researchers from universities and other institutions to come in and help quantify and make sense of what is happening in real time, helping bring operations into focus, while also helping regulators keep pace with Facebook and their strategy. Providing a secure, observable way to make sense of what is going on in real-time, helping minimize future abuse.
All Access to Digital Resources and Capabilities Go Through APIs
The first thing any tech person in the know will say to everything I have laid out is that Facebook will just route access to digital resources and capabilities outside the view of API management. Providing direct database and system access to trust partners, applications, integrations, and ensuring that only above the board activity shows up with the API management layer. Fair enough. Then Facebook should be required to route ALL external access to their digital resources and capabilities through their APIs. APIs are already the preferred approach of platforms when it comes to moving digital bits around, and making them available to partners--there is no technical or business argument for stating that APIs can’t be used. Platforms will make claims that APIs will slow things down, but there are plenty of high speed solutions available in the API toolbox, and API management can be done without injecting latency into API activity at any scale. Again, we have what we need to solve this problem, we just need the will to mandate that observably managed APIs become the normal mode of doing business today.
Solving Platform Illnesses Beyond Just Anticompetitive Practices
While outside the scope of this FTC filing, the adoption of regulatory practices at the API management layer would have wider implications when it comes to addressing some of the illnesses that plague our online world today. Having a more observable API management layer would help address a couple of the top concerns we have when it comes to depending on platforms like Facebook.
- Data Exploitation - An observable, regulated API management layer would help reveal the type data exploitation of end users as we saw in the Cambridge Analytic scandal. To conduct it’s questionnaires and obtain access to the data of Facebook users, Cambridge Analytica had to sign up for API access, and provide a reason for their application. There is also an accounting of the number of OAuth tokens their applications would accrue every time a Facebook user provided access to Cambridge Analytica. The problem is Facebook wasn’t interested in punishing this type of behavior in the moment, until it became a problem for them. With a more observable API manamange layer, regulators and researchers could help identify these problems as they emerge, as opposed to willfully being blind as Facebook was because they were more concerned with their anticompetitive strategy, than they were with protecting end users.
- Breaches - If all digital resources are routed through APIs, and all API access is managed in a standard and observable way, the chances of a breach will be much lower. Breaches often occur via custom, unmaintained, and legacy infrastructure. If all applications and integrations are forced to go through a standardized API layer, possessing a standardized API management layer, situations like the Cambridge Analytica abuse which technically wasn’t a breach (but it was), and other malicious activity can be identified and addressed, even if it isn’t a priority of the platform provider.
Modern API management infrastructure has been proven to help standardize and streamline how data, content, media, algorithms, and infrastructure can be securely made available online. APIs are behind every major shift of the last twenty years, and are at the heart of how Facebook rose to dominance, and executed their anticompetitive strategy. Leveraging these approaches to managing APIs would help in ensuring personal social networking, photos, messaging, and every other area of our online lives that Facebook touches enjoy healthy competition--which we all can agree will be better for everyone involved.
Now Is the Time for Sensible, Observable Regulation of Technology Using APIs
I know that I am going to upset many people I know in the tech industry with this post. It is unforgivable in many libertarian corners of the tech sector to call for regulation of our industry. I disagree. Now is the time. If you look at other transformative industries like electricity, telecommunications, and transportation, which all were heavily technology driven, regulations have played an important role in not just taming and controlling industry, but also made them safer and more accessible for everyone. More importantly, it laid a more solid foundation for these industries to grow way beyond what their early entrepreneurs or investors envisioned. I am guessing that all of these people on the ground floors of these industries claimed the same thing in the early days of regulation of electricity, phones, and automobiles. Wildly missing the scope of how these technological advances impact our lives, and the role that government would play in actually making these the world changing industries they are today.
I am writing this post, not because I believe in regulation, or hate Facebook. I am writing this because I believe in the potential of APIs when they are done in a balanced and observable way. I have witnessed APIs invade and alter almost every aspect of our now online, but also our offline lives over the last twenty years. I could see the potential of APIs when it came to commerce, social, cloud, mobile, and other major recent shifts in how our world works by 2010. But, by 2015 I was witnessing some pretty alarming behavior by leading API providers like Facebook, Twitter, Google, and others. To the point where I am pretty embarrassed by helping be a spokesperson of this industry. I am not trying to stick it to the tech sector with this suggestion that we use APIs and API management to regulate things. I am trying to take back the positive outcomes of using APIs from the greedy clutches of a few short sighted technology platforms. Ultimately I am convinced that there is even more money to be made, and even more innovation to occur, if we get down to the business of installing sensible regulation for the technology sector, and in my opinion, APIs are the key to getting it done. I am not under any delusion that this will be a quick fix for all that ails us, and I am pretty sure that initial legislation will not be sufficient. Not because we don’t have the right tools in our toolbox, but because of the lack of will and understanding among politicians, and the control the tech sector has over our government. However, this won’t stop me from trying, and I am guessing, based upon my experience so far in working with folks in DC, that I will be writing many more of these posts over the years, and working with waves of lawmakers wishing to make any change, until we reach a point where we can balance things back out a little bit, and wrestle back control from the tech platforms who dominate our lives today.
