As the usage and complexity of software grows, the importance of security research has grown with it. It’s through diligent research that we uncover and fix bugs — like Heartbleed and POODLE — that can cause serious security issues for web users around the world.

The time and effort it takes to uncover bugs is significant, and the marketplace for these vulnerabilities is competitive. That’s why we provide cash rewards for quality security research that identifies problems in our own products or proactive improvements to open-source products. We’ve paid more than $4 million to researchers from all around the world - our current Hall of Fame includes researchers from Germany, the U.S., Japan, Brazil, and more than 30 other countries.

The Commerce Department's proposed rules stem from U.S. membership in the Wassenaar Arrangement, a multilateral export control association. Members of the Wassenaar Arrangement have agreed to control a wide range of goods, software, and information, including technologies relating to "intrusion software" (as they've defined that term).

We believe that these proposed rules, as currently written, would have a significant negative impact on the open security research community. They would also hamper our ability to defend ourselves, our users, and make the web safer. It would be a disastrous outcome if an export regulation intended to make people more secure resulted in billions of users across the globe becoming persistently less secure.

Google comments on proposed rules

Earlier today, we formally submitted comments on the proposed rules to the United States Commerce Department’s Bureau of Industry and Security (BIS). Our comments are lengthy, but we wanted to share some of the main concerns and questions that we have officially expressed to the U.S. government today:

Rules are dangerously broad and vague. The proposed rules are not feasible and would require Google to request thousands - maybe even tens of thousands - of export licenses. Since Google operates in many different countries, the controls could cover our communications about software vulnerabilities, including: emails, code review systems, bug tracking systems, instant messages - even some in-person conversations! BIS’ own FAQ states that information about a vulnerability, including its causes, wouldn’t be controlled, but we believe that it sometimes actually could be controlled information.

You should never need a license when you report a bug to get it fixed. There should be standing license exceptions for everyone when controlled information is reported back to manufacturers for the purposes of fixing a vulnerability. This would provide protection for security researchers that report vulnerabilities, exploits, or other controlled information to any manufacturer or their agent.

Global companies should be able to share information globally. If we have information about intrusion software, we should be able to share that with our engineers, no matter where they physically sit.

Clarity is crucial. We acknowledge that we have a team of lawyers here to help us out, but navigating these controls shouldn’t be that complex and confusing. If BIS is going to implement the proposed controls, we recommend providing a simple, visual flowchart for everyone to easily understand when they need a license.

These controls should be changed ASAP. The only way to fix the scope of the intrusion software controls is to do it at the annual meeting of Wassenaar Arrangement members in December 2015.

We’re committed to working with BIS to make sure that both white hat security researchers’ interests and Google users’ interests are front of mind. The proposed BIS rule for public comment is available here, and comments can also be sent directly to publiccomments@bis.doc.gov. If BIS publishes another proposed rule on intrusion software, we’ll make sure to come back and update this blog post with details.