Skip to main content


TPP Threatens Security and Safety by Locking Down U.S. Policy on Source Code Audit

December 3, 2015

Multiple recent reports on serious security vulnerabilities in cable modems and routers paint a dire picture of the state of security of the devices that millions of users depend upon to connect to the Internet. Such vulnerabilities can be exploited to disable our access, snoop on our personal information, or launch malicious attacks on third parties. Other devices that are equally important for our security, or even to our physical health and safety—such as home alarm systems and, terrifyingly, a cardio server used in hospitals—have also been the subject of recent vulnerability disclosures.

One tool that security researchers can use to more quickly uncover and eliminate such vulnerabilities is having access to the source code of the software embedded in these devices. Of course, that can usually only be done if the source code is made available to them by the supplier. Many router manufacturers do make at least some of their devices' source code available, and often they do so because they are legally compelled to do this by the terms of the GNU General Public License, which applies to some of the core software upon which such devices are frequently based.

But that's not the only way that the manufacturers of critical devices could be compelled to release their code for public or peer review. There's also the option that a law or regulation could be made requiring the disclosure of such code, perhaps as a condition of the licensing of the products under applicable law. In fact, in October, 260 cybersecurity experts called upon the Federal Communications Commission to impose just such a requirement.

The TPP's Ban on Code Audit

Which brings us to the Trans-Pacific Partnership (TPP) agreement—which would prohibit such open source or code audit mandates being introduced in the future. Article 14.17 of the text of the Electronic Commerce chapter provides, “No Party shall require the transfer of, or access to, source code of software owned by a person of another Party, as a condition for the import, distribution, sale or use of such software, or of products containing such software, in its territory.”

As indicated above, this isn't just an issue confined to routers and modems. It could also apply to medical devices, smoke alarms, drink mixers, motor vehicles such as cars and tractors, wearables, and not to mention a myriad of pure software applications running on smartphones and PCs. Only devices and software used in bespoke applications (not for a mass market) or in critical infrastructure would be exempt under the terms of the TPP language, though the precise ambit of these exemptions remains unclear.

The provision would do more than merely outlaw open source code mandates. It would also prohibit any requirement that code be submitted for private review by regulatory authorities. Although we love free and open source software, it's not for everyone. So an alternative to requiring the vendors of proprietary software to release their code to the general public would be for them to have it audited by the responsible licensing authority, health and safety watchdog, or consumer protection agency. This possibility is also foreclosed by the TPP's strict language.

And the bad keeps on coming. Not only does the TPP foreclose rules that could require code to be open sourced or audited, it could also make it impossible for competition authorities to open up the market for the repair of products with embedded software. If the manufacturer of a car can't be required to give others access to the source code of the software that runs on its embedded computer systems, this seriously hinders an entire market for independent repair mechanics who could compete with its authorized repairers to work on that code, as well as markets for entrepreneurs to use their understanding of that code to make new devices that interoperate with vehicles, such as diagnostic tools and smartphone applications. This carries significant competition implications that the TPP negotiators, so far as we know, didn't even consider during their closed door negotiations in luxury hotels around the world.

What Was the USTR Thinking?

Why would the United States wish to tie its own hands in this way? On the face of it, in an environment where the Internet of Things is burgeoning and software quality is headline news, this restriction to our future regulatory capacity seems to make no sense at all.

The answer is found in this year's edition of the U.S. Trade Representative's (USTR) Special 301 Report, in which the USTR calls out China for measures requiring the disclosure of source code to the Chinese government (though oddly this complaint is only levied in the accompanying press release, and not in the PDF report itself).

Although described by the USTR as “new,” these requirements actually date from 2007 and are part of China's framework regulations for information security in critical infrastructure, known as the Multi-Level Protection Scheme (MLPS). The MLPS regulations limit products from being sold for use in Chinese information systems above a certain security level, unless their source code is disclosed to the government. Although this measure is presented as protection against security flaws and deliberate backdoors being inserted into critical software, it is also seen by U.S. companies as an impingement upon their ability to keep their code proprietary.

Assuming that this Chinese regulation is, in fact, a legitimate problem for U.S. companies, does the TPP actually address this very narrow problem? Not at all. First and most obviously, China is not a party to the TPP, and isn't likely to become one any time soon. But even if it were, the MLPS regulations only apply to software used in critical infrastructure—which is expressly exempted from the TPP provision anyway. So if anything, the provision makes even less sense than it seems to make at first glance.

No matter what you may think of the wisdom of laws or regulations requiring the disclosure of audit of source code in particular cases, we should all be able to agree that this is a complicated issue, and one that, as the Washington Post points out, shouldn't be resolved through a trade agreement negotiated behind closed doors. Since this controversial provision is actually touted by the USTR as a benefit to the tech industry from the deal, it goes to show once again what a mess they have made of this agreement by keeping actual users and innovators locked out of the negotiating room.


If you're in the United States, urge your lawmakers to call a hearing on the contents of the TPP that will impact your digital rights, and more importantly, to vote this deal down when it comes to them for ratification:

TPP action button
JavaScript license information