A Theory of Disclosure for Security and Competitive Reasons

From Cybersecurity Wiki
Jump to: navigation, search

Full Title of Reference

A Theory of Disclosure for Security and Competitive Reasons: Open Source, Proprietary Software, and Government Systems

Full Citation

Peter P. Swire, A Theory of Disclosure for Security and Competitive Reasons: Open Source, Proprietary Software, and Government Systems (Hous. L. Rev., Vol. 42, No. 5, Ohio State Public Law Working Paper No. 4, 2006). SSRN



Key Words

Communications Privacy Law, Disclosure Policy, Hacker, Software Vulnerability, Transparency


This article provides a general approach for describing the incentives of actors to disclose information about their software or systems. A chief point of this article is that the incentives of disclosure depend on two largely independent assessments—the degree to which disclosure helps or hurts security, and the degree to which disclosure creates competitive advantages or disadvantages for the organization.

The Model for When Disclosure Helps Security

This parts comes back on the author's work on when disclosure is socially optimal for security, taking into account the costs and benefits to all the parties involved. It continues the investigation of disclosure, looking at the incentives facing the key actors— those who design software or operate systems. In some settings, the incentives for key actors may lead to a large divergence between the socially optimal disclosure and the amount of disclosure actually made.

Security Breach Notification to Individuals

This part shows the incentive problems that exist when large databases are breached and the data of individuals is leaked. This sort of breach appears to be accompanied by significant externalities, so breach notification statutes or similar measures are likely appropriate. According to the author, to avoid both under- and over-disclosure, it makes sense to look at security breach as a systemic issue over time. First, there should likely be a sunset on breach notification statutes. We are at the early stages of knowing how to implement such statutes, and the sunset would likely spur better re-examination of the issue over time. Second, we should seriously consider a two-step regime. For more serious breaches, there would indeed be first-class mail notice to individuals, especially where there are concrete steps the individuals should take in response to the risks. For less serious breaches, which do not merit this individualized notice, there should be mandatory reporting to some agency such as the Federal Trade Commission. This sort of reporting would serve two major goals. It would mean that significant breaches, which do not merit notice to individuals, would be subject to action by the database holder. In this way, significant-but-not-major breaches would be addressed by data holders. In addition, it would allow the Federal Trade Commission to accumulate data about breaches, preparing the way for better re-examination of breach notification statutes over time.

Incentives for Disclosure and Secrecy for Security and Competitive Reasons

This part analyzes the incentives for disclosure or secrecy for security reasons and competitiveness reasons, for Open Source software, proprietary software, and government systems. It engages in a wider inquiry into incentives of system owners and software writers (“first parties”) to disclose information or keep it secret. A new concept here is that system owners have a distinct calculus based on two different motives, the “security motive” and the “competitive motive.” The security motive concerns the incentive of the first party to disclose or not based on achievement of the security goals of the first party and other parties. Notably, what is the rational calculus for when disclosure will help (“there is no security through obscurity”) or when instead secrecy will lead to better security (“loose lips sink ships”)? The competitive motive concerns the incentive of the first party to win in the marketplace against its competition. Notably, the first party will seek to determine when greater secrecy will help it competitively, such as with trade secrets, or when instead greater openness will win competitively, such as when use of an open standard attracts more business for a software writer.

Additional Notes and Highlights

Expertise Required: Logic - Low/Moderate


   A. The Security Disclosure Model
   B. Why Computer and Network Security Often Varies from Other Security
   A. Describing the Externality
   B. What, if Anything, to Do About the Externality?
   A. Case One: Security Incentives and Open Source Software
     1. When Hiddenness Can Help Open Source Security
     2. Implications of Hiddenness in Open Source Security
   B. Case Two: Competitive Incentives and Open Source Software
     1. The Openness of Open Source Software
     2. Hiddenness and the Competitive Incentives of Open Source Users
     3. The Puzzle of Why Corporations Invest in Producing Open Source Software
     4. Hiddenness and the Competitive Incentives of Open Source Developers
   C. Case Three: Security Incentives and Proprietary Software
     1. The Hiddenness of Proprietary Software
     2. Proprietary Software and a Monopoly Model for Information About Vulnerabilities
     3. The Importance of Market Structure
     4. Historical Experience and Implications
   D. Case Four: Competitive Incentives and Proprietary Software
     1. Network Effects and Disclosure for Standards
     2. Developer Mindshare and “Get Them While They’re Young”
     3. Overcoming Collective Action Problems
     4. Convergence of Open Source and Proprietary Approaches
   E. Case Five: Security Incentives and Government Agencies
     1. Government Agencies and National Security
     2. Information Sharing and Third-Party Effects
     3. Public Choice and the Weak Constraints on Government Secrecy
   F. Case Six: Competitive Incentives and Government