There is lots of talk this week about regulating Facebook after the Cambridge Analytica story broke. Individuals, businesses, lawmakers, and even Facebook are talking about how we begin to better regulate not just Facebook, but the entire data industry. From my perspective, as the API Evangelist, the mechanisms are already in place, they just aren’t being used to their fullest by providers, with no sufficient policy in place at the federal level to incentivize healthy behavior by API providers, data brokers, and 3rd party application developers.
API Management Is Already In Place
Modern API platforms, Facebook included, leverage what is called an API management layer, to help manage the applications being developed on their platforms. Every developer who wants to access platform APIs has to sign up, submit the name and details of their application(s), and then receive an API key which they have to include with each call they make to a platform’s API when requesting ANY data, content, or usage of an algorithm. This means that all the platforms should already be in tune with every application that is using their platform, unless they allow internal groups, and specific partners to bypass the API management layer.
An Application Review Process
Every application submitting for API keys has to go through some sort of review process. The bar for this review process might be as low as requiring you to have an email address, or as high as submitting drivers and business licenses, and verify how you are storing your data. Facebook has an application review process in place, and is something they are promising to tighten up a bit in response to Cambridge Analytica. How loose, or tight a platform is with their application review process is always in alignment with the platform’s business model, and how the value their user’s privacy and security.
Govern Data Access OAuth Using Scopes
Most platforms use a standard called OAuth for enabling 3rd party developers access to a platform user’s data. Each quiz, game, and application has to ask a user to authorize access to their data, and OAuth scopes govern how much, or how little data can be accessed. OAuth scopes are defined by the platform, and negotiated by 3rd party developers, and end-users. Facebook has tightened their OAuth scopes in recent years, but has more work ahead of them to make sure they protect end user’s interest, and that 3rd party developers are properly following OAuth healthy practices, and end-users are aware and literate of what they are doing when participating in OAuth flows.
Logging Of Every API Access
When it comes to API access, everything is logged, and you know exactly who has accessed what, and when. Everything an application does with Facebook, or any other platform’s data via their API is logged. This is standard practice across the industry. Since every application passes their API key with each call, you know the details of what each application is doing in real time. Saying you aren’t aware of what an application is doing with user’s data doesn’t exist in an API-driven world, it just means that you aren’t actively paying attention to, and responding to log activity in real time.
Analysis And Reporting Of Usage
Detailed analysis and reporting is baked into API management, providing visual dashboards for API platforms, application developers, and end-users to understand how data is being accessed and put to use by applications. Understanding activity at the API management layer is one of the fundamental elements of striking a balance between access and control over platform data consumption. APIs aren’t secure if nobody is paying attention to what is happening, and actively responding to bad behavior, and undesirable access. Platforms, 3rd party developers, as well as end-users should all be equipped, and educated regarding the analysis and reporting that is available via all any platform in which they operate on.
Application Directory And Showcase
Many API platforms actively showcase the applications that are built upon their APIs, sharing the interesting applications that are available, and allowing consumers to put them to use. When it comes to regulation, this existing practice just needs expanded upon, requiring ALL applications to be registered, whether for internal, partner, or external use. Then also expanding upon the data that is required and published as part of the application submission, review, and operation practice. Additionally, the application directory and showcase should be operated and audited by external entities, who aren’t beholden to platform interest, providing a more transparent, observable, and accountable approach to understanding what an application’s motivations are, and fairly reporting upon all platform usage.
Recurring Application Auditing Practices
Building on the existing application review process, and in conjunction with the application directory, all active applications should be subject to a recurring review process triggered by time, and by different levels of consumption. You already see some of this from providers like Twitter who limit applications to 1M OAuth tokens, which then you are subject to further scrutiny. This is something that should happen regularly for all applications, pushing for annual review and audit of their operations, as well as at 10K, 100K, and 1M OAuth token levels, pushing to further understand the data gathering, storage, funding, and partner relationships in play behind the scenes with each application built on top of a platform’s API.
Breach Notifications And Awareness
Every platform should be required to communicate with users, and the public regarding any breach that occurs within a 72 hour period. We see this practice taking hold in Europe around the GDPR regulation, and is something that needs to be adopted throughout the United States. This shouldn’t be limited to large scale, and malicious breaches, and also include any terms of service, privacy, or security violations incurred by individual applications. Publishing and sharing the details of the incident as part of the application directory and showcase. Highlighting not just the healthy behavior on the platform, but being open and transparent regarding the bad behavior that occurs. Bringing bad actors out of the shadows, and holding platforms, as well as 3rd party developers accountable for what goes on behind the scenes.
API Access For API Management Layer
All aspects of a platform should have APIs. Every feature available in the UI for a web or mobile application, should have a corresponding API. This applies to the platform as well, requiring that the entire API management, logging, and application directory layers outlined above all have APIs. Providing access to all applications who are accessing a platform, as well as understanding how they are putting API resources to work, and consuming valuable data and content. Making the platform more observable and accountable, allowing it to be audited by 3rd party research, journalists, regulators, and other industry level actors. Of course, not everyone would gain access to this layer by default, requiring different tiers of access, but still holding ALL API consumers to the same levels of accountability, no matter which tier they are working at.
Service Composition For Different Types Of Users
Another fundemental aspect of API management that exists across the tech sector, but isn’t always discussed or understood, is the different tiers of access available, depending on who you are. API service composition at the API management layer is what dictates that new API consumers only get access to a limited amount of resources, while more trusted partner, and internal groups get access to higher volumes, as well as additional number of API resources. Service composition is what limits the scope of API terms of service, privacy, and security breaches, and also allows for the trusted auditing, reporting, and analysis of how a platform operates by researchers, regulators, and other 3rd party actors. Every platform has different levels of API access as defined through their service composition at the API management layer. Sometimes this is reflected on their plans and pricing pages, but often times when there is no clear business models, these levels of access operate in the shadows.
Looking At Existing Solutions When it Comes To Platform Regulations
The cat is out of the bag. APIs have been used to measure, understand, and police the access to data, content, and algorithms at the API level for over a decade. Nothing I’ve outline is groundbreaking, or suggests anything new be developed. The only changes required are at the government policy level, and a change in behavior at the platform level. The tooling and services to implement the regulations of platforms already exists, and in most cases are already in place–it just happens that they are serving the platform masters, and have not be enlisted to serve end-users, and most definitely not at the regulatory level. API management is how platforms like Facebook, Twitter, and others have gotten to where they are, by incentivizing development and user growth via API integrations, the problem is this often involves turning the API faucet completely on, and not limiting access based upon privacy or security, and only in service of the business model when it makes sense.
Facebook has the ability to understand what Cambridge Analytic was doing. They can identify healthy and not so healthy practices via API consumption long before they become a problem. The problem is that their business model hasn’t been in alignment with taking control of things at the API management level–it encourages bad behavior, not limits it. There also isn’t any API access to this API management layer, and no observability into the applications that are built on top of existing APIs. There is no understanding at the regulatory level that these things are possible, and there are no policies in place requiring platforms have APIs, or provide industry level regulatory access to their API management layers. You can see the beginning of this emerge with banking regulatory efforts out of the UK, and requiring the API management layer be operated by a 3rd part entity, with all actors be registered in the API management directory, and accountable to the community, and the industry. Setting a precedent for regulatory change at the API management layer, and providing a working blueprint for how this can work.
API management is over a decade old, and something that is baked into the Amazon, Azure, and Google Clouds. It is standard practice across all leading API providers like Facebook, Twitter, Google, Amazon, and others. The concept of regulating data, content, and algorithmic access and usage at the API layer isn’t anything new. The only thing missing is the policy, and regulatory mandate to make it so. Americans are acting like this is something new, but we see a precent already being set in Europe through GDPR, and PSD2 in banking. The CFPB in DC was already working on moving this conversation forward until the Trump White House began unraveling things at the agency. Regulating our personal data won’t be a technical, or business challenge to solve, it will ultimately be about the politics of how we operate our platforms in a more sustainable way, and truly begin protecting the privacy and security of users (or not).
