Yesterday’s Trouble with the TPP post examined some of the uncertainty created by the surprising e-commerce provision that involves restrictions on source code disclosures. KEI notes that governments have not been shy about requiring source code disclosures in other contexts, such as competition worries. Yet this rule will establish new restrictions, creating concerns about the implications in areas such as privacy. For example, security and Internet experts have been sounding the alarm on the risks associated with exploited wifi routers and pointing to source code disclosures as potential solution.

Dave Farber, former Chief Technologist of the Federal Communications Commission, warns:

Today, there are hundreds of millions of Wi-Fi routers in homes and offices around the globe with severe software flaws that can be easily exploited by criminals. While we agree with the FCC that the rules governing these devices must be updated, we believe the proposed rules laid out by the agency lack critical accountability for the device manufacturers.

How to address the issue?

Experts such as Vint Cerf, one of the founders of the Internet, recommend several precautions including source code disclosure:

Any vendor of software-defined radio (SDR), wireless, or Wi-Fi radio must make public the full and maintained source code for the device driver and radio firmware in order to maintain FCC compliance. The source code should be in a buildable, change-controlled source code repository on the Internet, available for review and improvement by all.

The TPP may create a barrier for this solution. If companies are unwilling to voluntarily release the source code, TPP governments will be restricted in their ability to mandate disclosure (absent a claim that all wifi routers are now critical infrastructure, a definition that renders the term largely meaningless).  The source code provision is unprecedented in an established trade agreement, fostering new worries about how it may limit the available responses to a growing privacy and security threat.

(prior posts in the series include Day 1: US Blocks Balancing Provisions, Day 2: Locking in Digital Locks, Day 3: Copyright Term Extension, Day 4: Copyright Notice and Takedown Rules, Day 5: Rights Holders “Shall” vs. Users “May”, Day 6: Price of Entry, Day 7: Patent Term Extensions, Day 8: Locking in Biologics Protection, Day 9: Limits on Medical Devices and Pharma Data Collection, Day 10: Criminalization of Trade Secret Law, Day 11: Weak Privacy Standards, Day 12: Restrictions on Data Localization Requirements, Day 13: Ban on Data Transfer Restrictions, Day 14: No U.S. Assurances for Canada on Privacy, Day 15: Weak Anti-Spam Law Standards, Day 16: Intervening in Internet Governance, Day 17: Weak E-commerce Rules, Day 18: Failure to Protect Canadian Cultural Policy, Day 19: No Canadian Side Agreement to Advance Tech Sector, Day 20: Unenforceable Net Neutrality Rules, Day 21: U.S. Requires Canadian Anti-Counterfeiting Report Card, Day 22: Expanding Border Measures Without Court Oversight, Day 23: On Signing Day, What Comes Next?, Day 24: Missing Balance on IP Border Measures, Day 25: The Treaties With the Treaty, Day 26: Why It Limits Canadian Cultural Policies, Day 27: Source Code Disclosure Confusion)