It’s not enough to say that the Internet is built on interoperability. The Internet is interoperability. Billions of machines around the world use the same set of open protocols—like TCP/IP, HTTP, and TLS—to talk to one another. The first Internet-connected devices were only possible because phone lines provided interoperable communication ports, and scientists found a way to send data, rather than voice, over those phone lines.

In the early days of the Internet, protocols dictated the rules of the road. Because the Internet was a fundamentally decentralized, open system, services on the Internet defaulted to acting the same way. Companies may have tried to build their own proprietary networking protocols or maintain unilateral control over the content on the network, but they ultimately failed. The ecosystem was fast-moving, chaotic, and welcoming to new ideas.

Today, big platforms are ecosystems unto themselves. Companies create accounts on Twitter, Facebook, and YouTube in order to interact with consumers. Platforms maintain suites of business-facing APIs that let other companies build apps to work within the boundaries of those platforms. And since they control the infrastructure that others rely on, the platforms have unilateral authority to decide who gets to use it.

This is a problem for competition. It means that users of one platform have no easy way of interacting with friends on other services unless the platform’s owners decide to allow it. It means that network effects create enormous barriers to entry for upstart communications and social networking companies. And it means that the next generation of apps that would work on top of the new ecosystems can only exist at big tech’s pleasure.

That’s where interoperability can help. In this post, we’ll discuss how to bring about a more interoperable ecosystem in two ways: first, by creating minimum standards for interoperability that the tech giants must support; and second, by removing the legal moat that incumbents use to stave off innovative, competitive interoperators.

Interoperability is corporate entropy. It opens up space for chaotic, exciting new innovations, and erodes the high walls that monopolies build to protect themselves.

If Facebook and Twitter allowed anyone to fully and meaningfully interoperate with them, their size would not protect them from competition nearly as much as it does. But platforms have shown that they won’t choose to do so on their own. That’s where governments can step in: regulations could require that large platforms offer a baseline of interoperable interfaces that anyone, including competitors, can use. This would set a “floor” for how interoperable very large platforms must be. It would mean that once a walled garden becomes big enough, its owner needs to open up the gates and let others in.

Requiring big companies to open up specific interfaces would only win half the battle. There are always going to be upstarts who find new, unexpected, and innovative ways to interact with platforms—often against the platforms’ will. This is called “adversarial interoperability” or “competitive compatibility.” Currently, U.S. law gives incumbents legal tools to shut down those who would interoperate without the big companies’ consent. This limits the agency that users have within the services that are supposed to serve them, and it creates an artificial “ceiling” on innovation in markets dominated by monopolists. 

It’s not enough to create new legal duties for monopolists without dismantling the legal tools they themselves use to stave off competition. Likewise, it’s not enough to legalize competitive compatibility, since the platforms have such an advantage in technical resources that serious competitors’ attempts to interoperate face enormous engineering challenges. To break out of the big platforms’ suffocating hold on the market, we need both approaches. 

Mandating Access to Monopolist Platforms: Building a Floor

This post will look at one possible set of regulations, proposed in the bipartisan ACCESS Act, that would require platforms to interoperate with everyone else. At a high level, the ACCESS Act provides a good template for ensuring upstart competitors are able to interoperate and compete with monopolists. It won’t level the playing field, but it will ensure smaller companies have the right to play at all.

We’ll present three specific kinds of interoperability mandate, borrowed from the ACCESS Act’s framing. These are data portability, back-end interoperability, and delegability. Each one provides a piece of the puzzle: portability allows users to take their data and move to another platform; back-end interoperability lets users of upstart competitors interact with users of large platforms; and delegability allows users to interact with content from the big platforms through an interface of their choosing. All three address different ways that large platforms consolidate and guard their power. We’ll break these concepts down one at a time.

Data Portability

Data portability is the idea that users can take their data from one service and do what they want with it elsewhere. Portability is the “low-hanging fruit” of interoperability policy. Many services, Facebook and Google included, already offer relatively robust data portability tools. Furthermore, data portability mandates have been included in several recent data privacy laws, including the General Data Privacy Regulation (GDPR) and the California Consumer Privacy Act (CCPA). 

Portability is relatively uncontroversial, even for the companies subject to regulation. In 2019, Facebook published a whitepaper supporting some legal portability mandates. For its part, Google has repeatedly led the way with user-friendly portability tools. And Google, Facebook, Microsoft, Twitter, and Apple have all poured resources into the Data Transfer Project, a set of technical standards to make data portability easier to implement.

The devil is in the details. Portability is hard at the edges, because assigning “ownership” to data is often hard. Who should have access to a photo that one person takes of another’s face, then uploads to a company’s server? Who should be able to download a person’s phone number: just the owner, or everyone they’re friends with on Facebook? It is extremely difficult for a single law to draw a bright line between what data a user is entitled to and what constitutes an invasion of another’s privacy. While creating portability mandates, regulators should avoid overly prescriptive orders that could end up hurting privacy. 

Users should have a right to data portability, but that alone won’t be enough to loosen the tech giants’ grip. That’s because portability helps users leave a platform but doesn’t help them communicate with others who still use it.

Back-end Interoperability

The second, more impactful concept is back-end interoperability. Specifically, this means enabling users to interact with one another across the boundaries of large platforms. Right now, you can create an account on any number of small social networks, like diaspora or mastodon. But until your friends also move off of Facebook or Twitter, it’s extremely difficult to interact with them. Network effects prevent upstart competitors from taking off. Mandatory interoperability would force Facebook to maintain APIs that let users on other platforms exchange messages and content with Facebook users. For example, Facebook would have to let users of other networks post, like, comment, and send messages to users on Facebook without a Facebook account. This would enable true federation in the social media space.

Imagine a world where social media isn’t controlled by a monopoly. There are dozens of smaller services that look kind of like Facebook, but each has its own policies and priorities. Some services maintain tight control over what kind of content is posted. Others allow pseudonymous members to post freely with minimal interference. Some are designed for, and moderated by, specific cultural or political communities. Some are designed to share and comment on images; others lend themselves better to microblogs; others still to long textual exchanges.

Now imagine that a user on one platform can interact with any of the other platforms through a single interface. Users on one service can engage freely with content hosted on other services, subject to the moderation policies of the hosting servers. They don’t need to sign up for accounts with each service if they don’t want to (though they are more than free to do so). Facebook doesn’t have an obligation to host or promote content that violates its rules, but it does have a duty to connect its users to people and pages of their choosing on other networks. If users don’t like how the moderators of one community run things, they can move somewhere else. That’s the promise of federation.

Open technical standards to federate social networking already exist, and Facebook already maintains interfaces that do most of what the bill would require. But Facebook controls who can access its interfaces, and reserves the right to restrict or revoke access for any reason. Furthermore, Facebook requires that all of its APIs be accessed on behalf of a Facebook user, not a user of another service. It offers “interoperability” in one direction—flowing into Facebook—and it has no incentive to respect users who host their data elsewhere. An interoperability mandate, and appropriate enforcement, could solve both of these problems.

Delegability

The third and final piece of the legislative framework is delegability. This is the idea that a user can delegate a third-party company, or a piece of third-party software, to interact with a platform on their behalf. Imagine if you could read your Facebook feed as curated by a third party that you trust. You could see things in raw chronological order, or see your friends’ posts in a separate feed from the news and content companies that you follow. You could calibrate your own filters for hate speech and misinformation, if you chose. And you could assign a trusted third party to navigate Facebook’s twisted labyrinth of privacy settings for you, making sure you got the most privacy-protective experience by default.

A great deal of the problems caused by monopolistic platforms are due to their interfaces. Ad-driven tech companies use dark patterns and the power of defaults to get users’ “consent” for much of their rampant data collection. In addition, ad-driven platforms often curate information in ways that benefit advertisers, not users. The ways Facebook, Twitter, and Youtube present content are designed to maximize engagement and drive up quarterly earnings. This frequently comes at the expense of user well-being.

A legal mandate for delegability would require platforms to allow third-party software to interface with their systems in the same way users do. In other words, they would have to expose interfaces for common user interactions—sending messages, liking and commenting on posts, reading content, and changing settings—so that users could delegate a piece of software to do those things for them. At a minimum, it would mean that platforms can leave their tech the way it is—after all, these functions are already exposed through a user interface, and so may be automated—and stop suing companies that try to build on top of it. A more interventionist regulation could require platforms to maintain stable, usable APIs to serve this purpose.

This is probably the most interventionist of the three avenues of regulation. It also has the most potential to cause harm. If platforms are forced to create new interfaces and given only limited authority to moderate their use, Facebook and Twitter could become even more overrun with bots. In addition, any company that is able to act on a user’s behalf will have access to all of that person’s information. Safeguards need to be created to ensure that user privacy is not harmed by this kind of mandate.

Security, Privacy, Interoperability: Choose All Three

Interoperability mandates are a heavy-duty regulatory tool. They need to be implemented carefully to avoid creating new problems with data privacy and security. 

Mandates for interoperability and delegability have the potential to exacerbate the privacy problems of existing platforms. Cambridge Analytica acquired its hoard of user data through Facebook’s existing APIs. If we require Facebook to open those APIs to everyone, we need to make sure that the new data flows don’t lead to new data abuses. This will be difficult, but not impossible. The key is to make sure users have control. Under a new mandate, Facebook would have to open up APIs for competing companies to use, but no data should flow across company boundaries until users give explicit, informed consent. Users must be able to withdraw that consent easily, at any time. The data shared should be minimized to what is actually necessary to achieve interoperability. And companies that collect data through these new interoperable interfaces should not be allowed to monetize that data in any way, including using it to profile users for ads.

Interoperability may also clash with security. Back-end interoperability will mean that big platforms need to keep their public-facing APIs stable, because changing them frequently or without notice could break the connections to other services. However, once a service becomes federated, it can be extremely difficult to change the way it works at all. Consider email, the archetypal federated messaging service. While end-to-end encryption has taken off on centralized messaging services like iMessage and WhatsApp, email servers have been slow to adopt even basic, point-to-point encryption with STARTTLS. It’s proven frustratingly difficult to get stakeholders on the same page, so inertia wins, and many messages are sent using the same technology we used in the ‘90s. Some encryption experts have stated, credibly, that they believe federation makes it too “slow” to build a competitive encrypted messaging service.  

But security doesn’t have to take a backseat to interoperability. In a world with interoperability mandates, standards don’t have to be decided by committee: the large platform that is subject to regulation can dictate how its services evolve, as long as it continues to grant fair access to everyone. If Facebook is to make its encrypted chat services interoperable with third parties, it must reserve the right to aggressively fix bugs and patch vulnerabilities. Sometimes, this will make it difficult for competitors to keep up, but protocol security is not something we can afford to sacrifice. Anyone who wants to be in the business of providing secure communications must be ready to tackle vulnerabilities quickly and according to industry best practices.

Interoperability mandates will present new challenges that we must take seriously. That doesn’t mean interoperability has to destroy privacy or undermine security. Lawmakers must be careful when writing new mandates, but they should diligently pursue a path that gives us interoperability without creating new risks for users.

Unlocking Competitive Compatibility: Removing the Ceiling

Interoperability mandates could make a great floor for interoperability. By their nature, mandates are backward-looking, seeking to establish competitive ecosystems instead of incumbent monopolies. No matter how the designers of these systems strain their imaginations, they can never plan for the interoperability needs of all the future use-cases, technologies, and circumstances.

Enter “competitive compatibility,” or ComCom, which will remove the artificial ceiling on innovation imposed by the big platforms. A glance through the origin stories of technologies as diverse as cable TV, modems, the Web, operating systems, social media services, networks, printers, and even cigarette-lighter chargers for cellphones reveals that the technologies we rely on today were not established as full-blown, standalone products, but rather, they started as adjuncts to the incumbent technologies that they eventually grew to eclipse. When these giants were mere upstarts, they shouldered their way rudely into the market by adding features to existing, widely used products, without permission from the companies whose products they were piggybacking on.

Today, this kind of bold action is hard to find, though when it’s tried, it’s a source of tremendous value for users and a real challenge to the very biggest of the Big Tech giants. 

Competitive compatibility was never rendered obsolete. Rather, the companies that climbed up the ComCom ladder kicked that ladder away once they had comfortably situated themselves at the peak of their markets. 

They have accomplished this by distorting existing laws into anti-competitive doomsday devices. Whether it’s turning terms of service violations into felonies, making independent repair into a criminal copyright violation, banning compatibility altogether, or turning troll with a portfolio of low-grade patents, it seems dominant firms are never more innovative than when they're finding ways to abuse the law to make it illegal to compete with them.

Big Tech’s largely successful war on competitive compatibility reveals one of the greatest dangers presented by market concentration: its monopoly rents produce so much surplus that firms can afford to pursue the maintenance of their monopolies through the legal system, rather than by making the best products at the best prices.

EFF has long advocated for reforms to software patents, anti-circumvention rules, cybersecurity law, and other laws and policies that harm users and undermine fundamental liberties. But the legal innovations on display in the war on competitive compatibility show that fixing every defective tech law is not guaranteed to restore a level playing field. The lesson of legal wars like Oracle v. Google is that any ambiguity in any statute can be pressed into service to block competitors. 

After all, patents, copyrights, cybersecurity laws, and other weapons in the monopolist’s arsenal were never intended to establish and maintain industrial monopolies. Their use as anti-competitive weapons is a warning that a myriad of laws can be used in this way.

The barriers to competitive compatibility are many and various: there are explicitly enumerated laws, like section 1201 of the DMCA; then there are interpretations of those laws, like the claims that software patents cover very obvious "inventions" if the words "with a computer" are added to them; and then there are lawsuits to expand existing laws, like Oracle's bid to stretch copyright to cover APIs and other functional, non-copyrightable works. 

There are several ways to clear the path for would-be interoperators. These bad laws can be worked around or struck down, one at a time, through legislation or litigation. Legislators could also enshrine an affirmative right to interoperate in law that would future-proof against new legal threats. Furthermore, regulators could require that entities receiving government contracts, settling claims of anticompetitive conduct, or receiving permission to undertake mergers make binding covenants not to attack interoperators under any legal theory.

Comprehensively addressing threats to competitive compatibility will be a long and arduous process, but the issue is urgent. It’s time we got started.