The new ACCESS Act is a good start. Here’s how to make sure it delivers.

The ACCESS Act is one of the most exciting pieces of federal tech legislation this session. Today’s tech giants grew by taking advantage of the openness of the early Internet, but have designed their own platforms to be increasingly inhospitable for both user freedom and competition. The ACCESS Act would force these platforms to start to open up, breaking down the high walls they use to lock users in and keep competitors down. It would advance the goals of competition and interoperability, which will make the internet a more diverse, more user-friendly place to be.

We’ve praised the ACCESS Act as “a step towards a more interoperable future.” However, the bill currently before Congress is just a first step, and it’s far from perfect. While we strongly agree with the authors’ intent, some important changes would make sure that the ACCESS Act delivers on its promise.

Strong Consent and Purpose Limitation Requirements

One of the biggest concerns among proponents of interoperability is that a poorly thought-out mandate could end up harming privacy. Interoperability implies more data sharing, and this, skeptics argue, increases the risk of large-scale abuse. We addressed this supposed paradox head-on in a recent whitepaper, where we explained that interoperability can enhance privacy by giving users more choice and making it easier to switch away from services that are built on surveillance.

Requiring large platforms to share more data does create very real risks. In order to mitigate those risks, new rules for interoperability must be grounded in two principles: user consent and data minimization. First, users should have absolute control over whether or not to share their data: they should be able to decide when to start sharing, and then to rescind that permission at any time. Second, the law must ensure that data which is shared between companies in order to enable interoperability—which may include extremely sensitive data, like private messages—is not used for secondary, unexpected purposes. Relatedly, the law must make sure that “interoperability” is not used as a blanket excuse to share data that users wouldn’t otherwise approve of.

The ACCESS Act already has consent requirements for some kinds of data sharing, and it includes a “non-commercialization” clause that prevents both platforms and their competitors from using data for purposes not directly related to interoperability. These are a good start. However, the authors should amend the bill to make it clear that every kind of data sharing is subject to user consent, that they can withdraw that consent at any time, and that the purpose of “interoperability” is limited to things that users actually want. 

Which brings us to our next suggestion…

Define “Interoperability”

The law should say what interoperability is, and what it isn’t. In the original, senate-introduced version of the bill from 2019, large platforms were required to support “interoperable communications with a user of a competing communications provider.” This rather narrow definition would have limited the scope of the bill to strictly inter-user communications, such as sharing content on social media or sending direct messages to friends. 

The new version of the bill is more vague, and doesn’t pin “interoperability” to a particular use case. The term isn’t defined, and the scope of the activities implicated in the newer bill is much broader. This leaves it more open to interpretation.

Such vagueness could be dangerous. Advertisers and data brokers have recently worked to co-opt the rhetoric of interoperability, arguing that Google, Apple, and other developers of user-side software must keep giving them access to sensitive user data in order to promote competition. But as we’ve said before, competition is not an end in itself—we don’t want the ACCESS Act to help more companies compete to exploit your data. Instead, the authors should define interoperability in a way that includes user-empowering interoperability, but explicitly excludes use cases like surveillance advertising.

Let the People Sue

Time and again, we’ve seen well intentioned consumer protection laws fail to be effective because of a lack of meaningful enforcement. The easiest way to fix that is to give enforcement power to those who would be most affected by the law: the users. That’s why the ACCESS Act needs a private right of action. 

In the House draft of the bill, the FTC would be in charge of enforcing the law. This is a lot of responsibility to vest in an agency that’s already overtaxed. Even if the FTC enforces the law in good faith, it may not have the resources to go toe-to-toe with the biggest corporations in the world. And this kind of regulatory enforcement could open the door to regulatory capture, in which giant corporations successfully lobby to fill enforcement agencies with personnel who’ll serve their interests. 

The way to make sure that the bill’s policy turns into practice is to give those who might be harmed – users – the right to sue. Users whose privacy and security are compromised because of interfaces opened by the ACCESS Act should be able to take those responsible to court, whether it’s the large platforms or their would-be competitors who break the law.

As we wrote: “Put simply: the ACCESS Act needs a private right of action so that those of us stuck inside dominant platforms, or pounding on the door to innovate alongside or in competition with them, are empowered to protect ourselves.”

Bring back delegability

One of the best ideas from the original version of the ACCESS act was “delegability.” A delegability mandate would require large platforms to open up client-side interfaces so that users, hobbyist developers, and small companies could create tools that work on top of the platforms’ existing infrastructure. Users would then be free to “delegate” some of their interactions with the large platforms to trusted agents who could help make those platforms serve users’ needs. This type of “follow-on innovation” has been a hallmark of new tech platforms in the past, but it’s been sorely lacking in the ecosystem around today’s tech giants, who assert tight control over how people use their services.

Unfortunately, the version of the ACCESS Act recently introduced in the House has dropped the delegability requirement entirely. This is a major exclusion, and it severely limits the kinds of interoperability that the bill would create. The authors should look to the older version of the bill and re-incorporate one of the most important innovations that 2019’s ACCESS Act produced.

Government standards as safe harbors, not mandates

The ACCESS Act would establish a multi-stakeholder technical committee which would make recommendations to the FTC about the technical standards that large platforms need to implement to allow interoperability. Many consumer advocates may be tempted to see this as the best way to force big companies to do what the Act tells them. Advocates and lawmakers are (rightly) skeptical of giving Facebook and friends any kind of leeway when it comes to complying with the law.

However, forcing big platforms to use new, committee-designed technical standards may do more harm than good. It will ensure that the standards take a long time to create, and an even longer time to modify. It could mean that platforms that are forced to use those standards must lobby for government approval before changing anything at all, which could prevent them from adding new, user-positive features. It could also mean that the interfaces created in the first round of regulation—reflecting the tech platforms as they exist today—are unable to keep up as the internet evolves, and that they fail to serve their purpose as time goes on. And such clunky bureaucracy may give the tech giants ammunition to argue that the ACCESS act is a needless, costly tax on innovation.

It’s not necessarily bad to have the government design, or bless, a set of technical standards that implement ACCESS’ requirements. However, the platforms subject to the law should also have the freedom to implement the requirements in other ways. The key will be strong enforcement: regulators (or competitors, through a private right of action) should aggressively scrutinize the interfaces that big platforms design, and the law should impose strict penalties when the platforms build interfaces that are inadequate or anti-competitive. If the platforms want to avoid such scrutiny, they should have the choice to implement the government’s standards instead.

About That Standardization Process

At EFF, we’re no strangers to the ways that standardization processes can be captured by monopolists, and so we’ve paid close attention to the portions of the ACCESS Act that define new technical standards for interoperability. We have three suggestions:

1. Fix the technical committee definition. The current draft of the bill calls for each committee to have two or more reps from the dominant company; two or more reps from smaller, competing companies; two or more digital rights/academic reps; and one rep from the National Institute for Standards and Technology. This may sound like a reasonable balance of interests, but it would in theory allow a committee consisting of 100 Facebook engineers, 100 Facebook lawyers, two engineers from a small startup, two academics and a NIST technologist. Congress should better-define the definition of the technical committee with maximum numbers of reps from the dominant companies and fix the ratio of dominant company reps to the other groups represented at the committee.
2. Subject the committee work to public scrutiny and feedback. The work of the technical committee—including access to its mailing lists and meetings, as well as discussion drafts and other technical work—should be a matter of public record. All committee votes should be public. The committee’s final work should be subject to public notice and commentary, and the FTC should ask the committee to revise its designs based on public feedback where appropriate.
3. Publish the committee’s final work. The current draft of the ACCESS Act limits access to the committee’s API documentation to “competing businesses or potential competing businesses.” That’s not acceptable. We have long fought for the principle that regulations should be in the public domain, and that includes the ACCESS Act’s API standards. These must be free of any encumbrance, including copyright (and para-copyrights such as anti-circumvention), trade secrecy, or patents, and available for anyone to re-implement. Where necessary, the committee should follow the standardization best practice of requiring participants to covenant not to enforce their patents against those who implement the API.

Conclusion

Ultimately, it’s unlikely that every one of these pieces of policy will make it into the bill. That’s okay—even an imperfect bill can still be a step forward for competition. But these improvements would make sure the new law delivers on its promise, leading to a more competitive internet where everyone has a chance for technological self-determination.