Adam J. Aviv’s research while affiliated with George Washington University and other places

Apple introduced privacy labels in Dec. 2020 as a way for developers to report the privacy behaviors of their apps. While Apple does not validate labels, they also require developers to provide a privacy policy, which offers an important comparison point. In this paper, we fine-tuned BERT-based language models to extract privacy policy features for 474,669 apps on the iOS App Store, comparing the output to the privacy labels. We identify discrepancies between the policies and the labels, particularly as they relate to data collected linked to users. We find that 228K apps' privacy policies may indicate data collection linked to users than what is reported in the privacy labels. More alarming, a large number (97%) of the apps with a Data Not Collected privacy label have a privacy policy indicating otherwise. We provide insights into potential sources for discrepancies, including the use of templates and confusion around Apple's definitions and requirements. These results suggest that significant work is still needed to help developers more accurately label their apps. Our system can be incorporated as a first-order check to inform developers when privacy labels are possibly misapplied.

We draw on the Protection Motivation Theory (PMT) to design interventions that encourage users to change breached passwords. Our online experiment ( n =1,386) compared the effectiveness of a threat appeal (highlighting the negative consequences after passwords were breached) and a coping appeal (providing instructions on changing the breached password) in a 2×2 factorial design. Compared to the control condition, participants receiving the threat appeal were more likely to intend to change their passwords, and participants receiving both appeals were more likely to end up changing their passwords. Participants’ password change behaviors are further associated with other factors, such as their security attitudes (SA-6) and time passed since the breach, suggesting that PMT-based interventions are useful but insufficient to fully motivate users to change their passwords. Our study contributes to PMT’s application in security research and provides concrete design implications for improving compromised credential notifications.

We draw on the Protection Motivation Theory (PMT) to design nudges that encourage users to change breached passwords. Our online experiment (n=1,386) compared the effectiveness of a threat appeal (highlighting negative consequences of breached passwords) and a coping appeal (providing instructions on how to change the breached password) in a 2x2 factorial design. Compared to the control condition, participants receiving the threat appeal were more likely to intend to change their passwords, and participants receiving both appeals were more likely to end up changing their passwords; both comparisons have a small effect size. Participants' password change behaviors are further associated with other factors such as their security attitudes (SA-6) and time passed since the breach, suggesting that PMT-based nudges are useful but insufficient to fully motivate users to change their passwords. Our study contributes to PMT's application in security research and provides concrete design implications for improving compromised credential notifications.

Data dashboards are designed to help users manage data collected about them. However, prior work showed that exposure to some dashboards, notably Google’s My Activity dashboard, results in significant decreases in perceived concern and increases in perceived benefit from data collection, contrary to expectations. We theorize that this result is due to the fact that data dashboards currently do not sufficiently “connect the dots” of the data food chain, that is, by connecting data collection with the use of that data. To evaluate this, we designed a study where participants assigned advertising interest labels to their own real activities, effectively acting as a behavioral advertising engine to “connect the dots.” When comparing pre- and post-labeling task responses, we find no significant difference in concern with Google’s data collection practices, which indicates that participants’ priors are maintained after more exposure to the data food chain (differing from prior work), suggesting that data dashboards that offer deeper perspectives of how data collection is used have potential. However, these gains are offset when participants are exposed to their true interest labels inferred by Google. Concern for data collection dropped significantly as participants viewed Google’s labeling as generic compared to their own more specific labeling. This presents a possible new paradox that must be overcome when designing data dashboards, the generic paradox, which occurs when users misalign individual, generic inferences from collected data as benign compared to the totality and specificity of many generic inferences made about them.

To protect their security, users are instructed to use unique passwords for all their accounts. Password managers make this possible, as they can generate, store, and autofill passwords within a user's browser. Unfortunately, prior work has identified usability issues which may deter users from using password managers. In this paper, we measure the prevalence of usability issues affecting four popular password managers (Chrome, Safari, Bitwarden, and Keeper). We tested these password managers with their out-of-the-box settings on 60 randomly sampled websites. We show that users are likely to encounter issues using password managers during account registration and authentication. We found that usability issues were widespread, but varied by password manager. Common issues included password managers not prompting the user to generate passwords, autofilling web forms incorrectly or not at all, and generating passwords that were incompatible with websites' password policies. We found that Chrome and Safari had fewer interaction issues than the other password managers we tested. We conclude by suggesting ways that websites and password managers can improve their compatibility with each other. For example, we recommend that password managers tailor their passwords to websites' requirements (like Chrome and Safari), or adopt alphanumeric-only password generation by default (like Bitwarden).