Peter P. Swire

Identifying and classifying ambiguity for regulatory requirements

Software engineers build software systems in increasingly regulated environments, and must therefore ensure that software requirements accurately represent obligations described in laws and regulations. Prior research has shown that graduate-level software engineering students are not able to reliably determine whether software requirements meet or exceed their legal obligations and that professional software engineers are unable to accurately classify cross-references in legal texts. However, no research has determined whether software engineers are able to identify and classify important ambiguities in laws and regulations. Ambiguities in legal texts can make the difference between requirements compliance and non-compliance. Herein, we develop a ambiguity taxonomy based on software engineering, legal, and linguistic understandings of ambiguity. We examine how 17 technologists and policy analysts in a graduate-level course use this taxonomy to identify ambiguity in a legal text. We also examine the types of ambiguities they found and whether they believe those ambiguities should prevent software engineers from implementing software that complies with the legal text. Our research suggests that ambiguity is prevalent in legal texts. In 50 minutes of examination, participants in our case study identified on average 33.47 ambiguities in 104 lines of legal text using our ambiguity taxonomy as a guideline. Our analysis suggests (a) that participants used the taxonomy as intended: as a guide and (b) that the taxonomy provides adequate coverage (97.5%) of the ambiguities found in the legal text.

A legal cross-references taxonomy for reasoning about compliance requirements

Companies must ensure their software complies with relevant laws and regulations to avoid the risk of costly penalties, lost reputation, and brand damage resulting from non-compliance. Laws and regulations contain internal cross-references to portions of the same legal text, as well as cross-references to external legal texts. These cross-references introduce ambiguities, exceptions, as well as other challenges to regulatory compliance. Requirements engineers need guidance as to how to address cross-references in order to comply with the requirements of the law. Herein, we analyze each external cross-reference within the U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule, the Gramm–Leach–Bliley Act (GLBA), and the GLBA Financial Privacy Rule to determine whether a cross-reference either introduces a conflicting requirement, a conflicting definition, or refines an existing requirement. Herein, we propose a legal cross-reference taxonomy to aid requirements engineers in classifying cross-references as they specify compliance requirements. Analyzing cross-references enables us to address conflicting requirements that may otherwise thwart legal compliance. We identify five sets of conflicting compliance requirements and recommend strategies for resolving these conflicts.

A legal cross-references taxonomy for identifying conflicting software requirements

Companies must ensure their software complies with relevant laws and regulations to avoid the risk of costly penalties, lost reputation, and brand damage resulting from noncompliance. Laws and regulations contain internal cross-references to portions of the same legal text, as well as cross-references to external legal texts. These cross-references introduce ambiguities, exceptions, as well as other challenges to regulatory compliance. Requirements engineers need guidance as to how to address cross-references in order to comply with the requirements of the law. Herein, we analyze each external cross-reference within the U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule to determine whether a cross-reference either: introduces a conflicting requirement, a conflicting definition, and/or refines an existing requirement. Herein, we propose a legal cross-reference taxonomy to aid requirements engineers in classifying cross-references as they specify compliance requirements. Analyzing cross-references enables us to address conflicting requirements that may otherwise thwart legal compliance. We identify five sets of conflicting compliance requirements and recommend strategies for resolving these conflicts.

Managing changing compliance requirements by predicting regulatory evolution

Over time, laws change to meet evolving social needs. Requirements engineers that develop software for regulated domains, such as healthcare or finance, must adapt their software as laws change to maintain legal compliance. In the United States, regulatory agencies will almost always release a proposed regulation, or rule, and accept comments from the public. The agency then considers these comments when drafting a final rule that will be binding on the regulated domain. Herein, we examine how these proposed rules evolve into final rules, and propose an Adaptability Framework. This framework can aid software engineers in predicting what areas of a proposed rule are most likely to evolve, allowing engineers to begin building towards the more stable sections of the rule. We develop the framework through a formative study using the Health Insurance Portability and Accountability (HIPAA) Security Rule and apply it in a summative study on the Health Information Technology: Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology.

Elephants and Mice Revisited: Law and Choice of Law on the Internet

By definition, an essential question of cyberlaw is to define when law will affect actions in cyberspace. Such law might be uniform, such as where nations have entered into a treaty or have adopted the same legal rule. Or, such law might be diverse, such as where nations adopt different legal rules. Diversity of law often does not matter for physical acts, such as where the criminal law of one country simply does not apply to acts performed in a foreign country. On the Internet, however, diversity of law poses a fundamental challenge. Each surfer on a website might be from a foreign jurisdiction, with laws unknown to the owner of the site. Similarly, each website visited by a surfer might be hosted in a foreign jurisdiction, with laws unknown to the surfer. Every encounter in cyberspace, therefore, raises the possibility that diverse laws will apply. The rules for choosing among diverse laws—the subject of this part of the Symposium on “Choice of Law and Jurisdiction on the Internet”—thus appear uniquely important for cyberspace. Surprisingly, however, the number of actual cases addressing choice of law on the Internet is far, far lower than the initial analysis would suggest. Although there is the possibility of diverse national laws in every Internet encounter, some mysterious mechanisms are reducing the actual conflicts to a handful of cases. This Article seeks to explain those mysterious mechanisms. It does not primarily address the prescriptive task of saying what the optimal rules should be for resolving conflicting national laws that affect the Internet. Instead, it takes on a descriptive task. It treats choice of law on the Internet as a dependent variable; the task is to explain when and how choice-of-law rules actually matter on the Internet.

Encryption and Globalization

During the explosive growth of the Internet in the 1990s, encryption was quite likely the single most passionate area of legal and policy debate. Law enforcement and national security agencies supported limits on the export of strong encryption, fearing that encryption would block their ability to protect public safety and national security. Supporters of strong encryption most basically argued that encryption was essential to securing communication over the Internet. During the “crypto wars” of the 1990’s, government policy initially supported surveillance, with the Clipper Chip proposal and a policy of escrowing encryption keys. The administration shifted position in 1999, allowing export largely without restrictions. After this shift in policy, encryption law and policy largely faded from view.Encryption is now resurfacing as a major issue, most visibly in India and China. Indian law currently forbids the use of encryption keys longer than 40 bits, which is far below international standards. China, meanwhile, insists that hardware and software made or used in China only employ cryptosystems developed in China.The article seeks to fill an important gap in the literature. Because the U.S. encryption problem was “solved” in 1999, a new generation of policy makers, lawyers, and technologists has emerged with little or no experience in the area of encryption policy.Part I of this article offers a short history of wiretaps for phone and Internet data, illustrating why communications across the Internet are far more vulnerable than traditional phone calls, unless encryption is used. Part II provides a primer on basic encryption concepts that are relevant to the subsequent legal and policy analysis.Part III highlights key lessons learned from the U.S. crypto wars of the 1990s, informed by the perspective of one of the authors, who chaired the White House Working Group on Encryption in the lead-up to the 1999 change in U.S. encryption policy.Part IV builds on the U.S. experience, and proposes two additional reasons why effective encryption becomes even more important when the debate shifts from one country to a globalized setting. The first is the large and growing importance of cybersecurity for nations around the world. In cybersecurity today, the “offense” (in the form of thousands of attacks per day) is significantly ahead of the “defense.” Cryptography is quite possibly the largest category of effective defensive tool. In a globalized world, security holes in major countries (such as India or China) directly lead to security holes elsewhere. Globalization also leads to what we call the “least trusted country problem -- the level of trust placed in data traveling through the Internet becomes that of the country that we trust least.Part V synthesizes the key reasons supporting effective encryption in today’s globalized world, despite the security objections of law enforcement and national security agencies, and the trade interests of some countries. By examining the relevant history, technology, law, and policy, this article explains why it is vital to assure the widespread and global availability of strong encryption for our data and communications.

Security market: incentives for disclosure of vulnerabilities

A previous paper by the author proposed a model for when disclosure helps or hurts security, and provided reasons why computer security is often different in this respect than physical security. This paper examines the incentives of actors to disclose vulnerabilities. A chief point of this paper 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 advantages or disadvantages for the organization competitively.The paper presents a 2x3 matrix, where disclosure for security and competition are assessed for three types of systems or software: Open Source; proprietary software; and government systems. Surprisingly, the paper finds significant convergence on disclosure between Open Source and proprietary software. For instance, Open Source security experts often do not disclose configurations and settings, and Open Source programmers often rely on trade secrets (i.e., lack of disclosure) to gain competitive advantage. Similarly, proprietary software often uses more disclosure than assumed. For security, large purchasers and market forces often lead to disclosure about proprietary software. For competitive reasons, proprietary software companies often disclose a great deal in order to seek to become a standard in a competitive space.Despite this greater-than-expected convergence of practice for Open Source and proprietary software, there are strong reasons to believe that less-than-optimal disclosure happens for government systems. The tradition of military secrecy, and the concern about tipping off attackers, leads to a culture of secrecy for government security. Competition for turf, such as the FBIs reputation for not sharing with local law enforcement, further reduces agency incentives to share information about vulnerabilities.

Privacy excerpt from “Towards Digital eQuality: the U.S. Government working group on electronic commerce”

I direct the Secretary of Commerce and the Director of the Office of Management and Budget to encourage private industry and privacy advocacy groups to develop and adopt within the next 12 months effective codes of conduct, industry developed rules, and technological solutions to protect privacy on the Internet consistent with the Privacy Principles issued by the Information Infrastructure Task Force (IITF) Privacy Working Group. I further direct the Director of OMB to develop recommendations on the appropriate role of government consistent with A Framework For Global Electronic Commerce. I further direct the Secretary and the Director to ensure that means are developed to protect the privacy of children.

A pedagogic cybersecurity framework

A proposal for teaching the organizational, legal, and international aspects of cybersecurity.