Resilience: building better users and fair trade practices in information.

• Author: Matwyshyn, Andrea M.
• Position: Rough Consensus and Running Code: Integrating Engineering Principles into the Internet Policy Debates

1. WHAT IS RESILIENCE? A. Building Resilience in Systems: The Software Ecosystem B. Building Resilience in Users II. RESILIENCE, CONTRACTS, AND FAIR TRADE PRACTICES 1N INFORMATION A. Resilience and Contracts in Technology-Mediated Spaces B. Fair Trade Practices, Privacy, and Technology Contracts 1. Experience in Digital Contract: Creating a Plain English "Information License and Security Agreement". 2. Emotion in Digital Contract: Creating a Sense of Transparency in Formation with Summary Labeling 3. Modeling: Imposing Digital Reasonableness Standards 4. Feedback Loops in Digital Contract: Offering a Live Human to Negotiate and Explain Terms .... 408 III. CONCLUSION A long-running joke about the law asserts that that the practice of law would be more pleasant if it weren't for all those pesky clients. In the world of technology, a more terse version of this same sentiment exists: PEBKAC--Problem Exists Between Keyboard and Chair. Technologists often long for "better" users of their products. Naturally, the logical reaction to this type of statement is to encourage developers of products to engage in better usability testing of their products on actual consumers. However, a deeper question may lurk beneath the superficial flippancy of PEBKAC. Is there in fact a way that we can "build better users?" This Article argues that there is. Despite a long running discourse regarding the resilience of infrastructure and networks themselves, a portion of the discussion that has been neglected relates to human resilience--buttressing the resilience of users of technology and the role of law in furthering this goal. Borrowing lessons from developmental psychology and securities regulation, this Article expands the concept of resilience into the software and digital contracting ecosystem. It argues that technology law and policy can be tooled in part to adopt an explicit focus on building users' resilience and sense of self-efficacy, particularly in connection with data privacy and information security. Technology law and policy can help to train consumers to be confident users and bounce back from technology problems. With the assistance of strengthened fair trade practices in privacy, contract law offers one avenue for explicit trust-reinforcing mechanisms to assist consumers in becoming more resilient users.

1. WHAT IS RESILIENCE?

   Many of us have found ourselves in a situation where we did not understand how a piece of software worked behind the scenes on our machines. We wondered what exactly we had agreed to when we clicked "yes" on the user agreement, whether we could really trust the code, and whether we understood the extent to which data would be collected about us. For some of us, a mild panic followed. Yet, in these moments of privacy "freakout," we had no one to ask. Reading a privacy policy--to the extent we understood it--likely yielded only more questions. We found ourselves cursing the software product as "creepy" privacy-invasive code. Meanwhile, the technologists who write software frequently feel equally frustrated by the way we, the consumer base that uses their products, interact with these products. In other words, a perception gap exists between the way that builders of technology tools perceive their products and the way that average consumers perceive these same products. The reason for this disconnect can be understood as a deficit of what developmental psychologists might call resilience. This resilience, or ability to recover and flourish in the face of obstacles, is frequently absent on both sides of the software equation--both in the code writing process itself and in consumers' ability to overcome technology obstacles when using products.

   1. Building Resilience in Systems: The Software Ecosystem

      The concept of resilience has long been prevalent in systems literature. When applied to technological, human, and ecological systems, resilience refers to the ability of the system to restore and maintain itself in a functional state, providing all services, despite disruptive changes to the system. (1) As such, the concept of resilience springs from complexity theory and its focus on dynamic, emergent change and system evolution in response. (2) "The challenge [to a resilient system] ... is to conserve the ability to adapt to change, to be able to respond in a flexible way to uncertainty and surprises" and "to identify the properties and processes that shape the future." (3) By definition, resilience involves the ability of a system to evolve in advance of and in response to known vulnerabilities to avoid or minimize their impact. However, this enterprise of anticipation is always limited by human knowledge and other factors. (4)

      Resilient systems have been identified to possess three distinct types of properties or processes. First, the system is built with an eye to the future and possesses redundancy, which allows for bouncing back from destabilizing events to come. (5) In other words, they possess the ability to change. Second, the system demonstrates a shifting balance between stable and unstable forces, with internal controls intended to counterbalance external variability. (6) This means that the system is still capable of performing when an external force pushes on it. Third, the system demonstrates a dynamic, changing nature that compensates for vulnerability and persists. (7) In other words, the system possesses the ability to self-correct and return to a normal state.

      The concept of resilience has been applied in legal literature to various types of connected systems, including the environmental ecosystem, (8) tribal sovereignty, (9) agencies and social trust, (10) human communities (11) (such as families (12)), social decay, (13) disasters, (14) markets and financial systems, (15) technology, (16) and critical infrastructure (17) (such as electrical grids (18) and internet infrastructure (19)). This idea of resilience analysis of the software development lifecycle and ecosystem, however, presents a newer undertaking, and one to date almost entirely unexplored in the legal literature. (20) The software ecosystem, including the processes of software development, deployment, and repair, should be viewed as another type of system that warrants a resilience analysis. Why? The reason for this extension is the avoidability of much consumer harm, particularly with respect to privacy and information security concerns. A significant portion of consumer complaints arise because particular digital products cannot withstand the entirely foreseeable wear and tear of consumer use and foreseeable third party attacks.

      What users perceive to be unacceptable, privacy-invasive code frequently surprises even sophisticated companies. However, with adequate resiliency analysis beforehand, most consumer privacy and information security freakouts are entirely avoidable. Two recent examples of this underestimation of consumer reactions involve Google and Facebook. In early 2010, Google launched a product called Buzz. (21) By external appearances, Buzz seemed to be a type of crossover product between a Facebook-like interface and a Twitter feed. To assist in its adoption, Google decided to repurpose the data in users' Gmail e-mail account contact lists for their individual starter group of "followers" in Buzz, making these lists public by default. (22) Almost immediately, public outcry ensued. (23) Gmail address books for some users contained contact information for individuals who were unwelcome "followers." (24) In its zealousness to promote Buzz, Google had, according to press accounts, cut short its usual beta testing process and unintentionally triggered the "privacy invasion" sensitivity of some of its users. (25) This product shipping decision was subsequently labeled by a Federal Trade Commission (FTC)

      (authentication); what rights and privileges the requestor has (authorization); the ability to build historical evidence (auditing); and the management of configuration, sessions, and exceptions. See, e.g., OFFICIAL (ISC)2 GUIDE TO THE CISSP CBK (Harold F. Tipton & Kevin Henry eds., 2007); Kristin R. Eschenfelder & Anuj C. Desai, Software as Protest: The Unexpected Resiliency of U.S.-Based DeCSS Posting and Linking, 20 INFO. SOC'Y 101 (2004) (demonstrating the proliferation of U.S.-based websites either posting or linking to the DeCSS program over the course of Universal City Studios v. Corley, 273 F.3d 429 (2d Cir. 2001)). member as "irresponsible conduct" (26) and at least eleven U.S. lawmakers called for an FTC investigation. (27) Along similar lines, Facebook found itself in court because of its Beacon program, (28) which collected data regarding user behaviors on "partner" websites. (29) The Beacon program involved embedded code in partner sites that triggered a post regarding consumer conduct on those partner sites to be posted to some consumers' Facebook feeds. (30) Because some users did not understand how this information was being shared, and they considered the practice an invasion of their privacy. (31) This confusion resulted in what the media has termed a "public relations disaster" (32) and in a class action lawsuit against Facebook that resulted in a settlement in the amount of $9.5 million. (33)

      Both companies in question were surprised by the consumer reaction. However, in both cases this surprise was likely avoidable. More extensive usability testing on average consumers likely would have revealed the code's lack of resilience when embedded into the broader software ecosystem.

      That said, the lack of resilience of the developers' code in the two cases above was only part of the problem. It was undoubtedly exacerbated by some users' lack of individual resilience. Some consumers poorly adjust to new technology and experience potent emotions of stress and confusion with respect to even small changes in existing software. To understand this parallel consumer resilience side of this...