Although continual online interaction is beneficial for an older adult with mild cognitive impairment, cybersecurity risks can become more pronounced. Prior work has touted the benefit of shared decision-making between care recipients and caregivers who may want to instill cybersecurity safeguards, particularly in the area of online safety and security. In this study we investigated the current online safety and security decision-making practices of care recipients with mild cognitive impairment and their spousal caregivers. We identified a gap between optative and actual decision-making: whereas couples expressed their desire to engage in shared decision-making, the actuality was most caregivers were compelled to take sole action. We further determined that shared-decision making was not feasible as there was a lack of suitable safeguarding options along a spectrum of care for the couple to choose from. We relate these findings to prior work that highlights similar challenges and discuss how there needs to be more offered than simply an illusion of choice.

Older adults are rapidly increasing their use of online services such as banking, social media, and email - services that come with subtle and serious security and privacy risks. Older adults with mild cognitive impairment (MCI) are particularly vulnerable to these risks because MCI can reduce their ability to recognize scams such as email phishing, follow recommended password guidelines, and consider the implications of sharing personal information. Older adults with MCI often cope with their impairments with the help of caregivers, including partners, children, and professional health personnel, when using and managing online services. Yet, this too carries security and privacy risks: sharing personal information with caregivers can create issues of agency, autonomy, and even risk embarrassment and information leakage; caregivers also do not always act in their charges' best interest. Through a series of interviews conducted in the US, we identify a spectrum of safeguarding strategies used and consider them through the lens of 'upside and downside risk' where there are tradeoffs between reduced privacy and maintaining older adults' autonomy and access to online services.

Customizing assistive technologies based on user needs, abilities, and preferences is necessary for accessibility, especially for individuals whose abilities vary due to a diagnosis, medication, or other external factors. Adaptive Assistive Technologies (AATs) that can automatically monitor a user's current abilities and adapt functionality and appearance accordingly offer exciting solutions. However, there is an often-overlooked privacy tradeoff between usability and user privacy when designing such systems. We present a general privacy threat model analysis of AATs and contextualize it with findings from an interview study with older adults who experience pointing problems. We found that participants had positive attitude towards assistive technologies that gather their personal data but also had strong preferences for how their data should be used and who should have access to it. We identify a need to seriously consider privacy threats when designing assistive technologies to avoid exposing users to them.

Adaptive assistive technologies can support the accessibility needs of people with changing abilities by monitoring and adapting to their performance over time. Despite their benefits, these systems can pose privacy threats to users whose data is collected. This issue is amplified by the ambiguity on how user performance data, which might reveal sensitive health data, is used by these applications and whether similar to medical data it is protected from unauthorized sharing with third-parties. In interviews with older adults who experience pointing difficulties, we found that participants felt a lack of agency over their collected pointing data and desired clear communication mechanisms to keep them informed about the privacy characteristics of adaptive assistive systems. Based on this input, we present an icon set, that can be used in online application stores or with the licensing agreements of adaptive systems, to visually communicate privacy characteristics to users.

In agile software development projects, software engineers prioritize implementation over documentation to eliminate needless documentation. Is the cost of missing documentation greater than the cost of producing unnecessary or unused documentation? Even without these documents, software engineers maintain other software artifacts, such as tickets in an issue tracking system (ITS) or source code committed to a version control system (VCS). Do these artifacts contain the necessary knowledge? In this paper, we examine undocumented knowledge in an agile software development project at NTT. For our study, we collected 159 commit logs in a VCS and 102 tickets in the ITS from the three-month period of the project. We propose a ticket-commit network chart (TCC) that visually represents time-series commit activities along with filed issue tickets. We also implement a tool to generate the TCC using both commit log and ticket data. Our study revealed that in 16% of all commits, software engineers committed source code to the VCS without a corresponding issue ticket in the ITS. Had these commits been based on individual issue tickets, these "unissued" tickets would have accounted for 20% of all tickets. Software users and requirements engineers also evaluated the contents of these commits and found that 42% of the "unissued" tickets were required for software operation and 23% of those were required for requirements modification.

Software systems are increasingly regulated. Software engineers therefore must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations arelegally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. In this paper, we examine how software engineers make these determinations using a multi-case study with three cases. Each case involves assessment of requirements for an electronic health record system that must comply with the US Health Insurance Portability and Accountability Act (HIPAA) and is measured against the evaluations of HIPAA compliance subject matter experts. Our first case examines how individual graduate-level software engineering students assess whether the requirements met or exceeded their HIPAA obligations. Our second case replicates the findings from our first case using a different set of participants. Our third case examines how graduate-level software engineering students assess requirements using the Wideband Delphi approach to deriving consensus in groups. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity.

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.

Businesses and organizations in jurisdictions around the world are required by law to provide their customers and users with information about their business practices in the form of policy documents. Requirements engineers analyze these documents as sources of requirements, but this analysis is a time-consuming and mostly manual process. Moreover, policy documents contain legalese and present readability challenges to requirements engineers seeking to analyze them. In this paper, we perform a large-scale analysis of 2,061 policy documents, including policy documents from the Google Top 1000 most visited websites and the Fortune 500 companies, for three purposes: (1) to assess the readability of these policy documents for requirements engineers; (2) to determine if automated text mining can indicate whether a policy document contains requirements expressed as either privacy protections or vulnerabilities; and (3) to establish the generalizability of prior work in the identification of privacy protections and vulnerabilities from privacy policies to other policy documents. Our results suggest that this requirements analysis technique, developed on a small set of policy documents in two domains, may generalize to other domains.

Software engineers regularly build systems that are required to comply with laws and regulations. To this end, software engineers must determine which requirements have met or exceeded their legal obligations and which requirements have not. Requirements that have met or exceeded their legal obligations are legally implementation ready, whereas requirements that have not met or exceeded their legal obligations need further refinement. Research is needed to better understand how to support software engineers in making these determinations. In this paper, we describe a case study in which we asked graduate-level software engineering students to assess whether a set of software requirements for an electronic health record system met or exceeded their corresponding legal obligations as expressed in regulations created pursuant to the U.S. Health Insurance Portability and Accountability Act (HIPAA). We compare the assessment made by graduate students with an assessment made by HIPAA compliance subject matter experts. Additionally, we contrast these results with those generated by a legal requirements triage algorithm. Our findings suggest that the average graduate-level software engineering student is ill-prepared to write legally compliant software with any confidence and that domain experts are an absolute necessity. Our findings also indicate the potential utility of legal requirements metrics in aiding software engineers as they make legal compliance decisions.

We describe a case study in which we evaluated an open-source Electronic Health Record (EHR) system’s requirements for compliance with the U.S. Health Insurance Portability and Accountability Act (HIPAA). Our findings suggest that legal compliance must be requirements-driven, while establishing due diligence under the law must be test-driven.