Search

Phishing is by far the most common and disruptive type of cyber-attack faced by most organizations. Phishing messages may share common attributes such as the same or similar subject lines, the same sending infrastructure, similar URLs with certain parts slightly varied, and so on. Attackers use such strategies to evade sophisticated email filters, increasing the difficulty for computing support teams to identify and block all incoming emails during a phishing attack. Limited work has been done on grouping human-reported phishing emails, based on the underlying scam, to help the computing support teams better defend organizations from phishing attacks. In this paper, we explore the feasibility of using unsupervised clustering techniques to group emails into scams that could ideally be addressed together. We use a combination of contextual and semantic features extracted from emails and perform a comparative study on three clustering algorithms with varying feature sets. We use a range of internal and external validation methods to evaluate the clustering results on real-world email datasets. Our results show that unsupervised clustering is a promising approach for scam identification and grouping, and analyzing reported phishing emails is an effective way of mitigating phishing attacks and utilizing the human perspective.

When people receive malicious emails that claim to be from a trusted entity like their bank, they can be frightened and uncertain about how safe it is to ignore or delete the message. The uncertainty is hard on users and it may lead them to engage in unsafe actions like clicking on links ``just to check.'' In this work we look at how to provide quick and accurate support to people who report phishing so that they can confidentially take appropriate action. For this, we will build a phishing-advice tool, PhishEd, that allows people to report malicious emails that they encounter and get automatically generated advice in response that is contextual to the suspicious email. The advice is meant to both help them make an informed decision about the reported email as well as provide some education to help them in handling future malicious emails better.

In the past decade the usable privacy and security research community has extended its research to expert users such as software developers who have been shown to face challenges when working with privacy and security technologies. However, it is often challenging to run empirical studies with developers because they can be hard to recruit for interviews or surveys. Researchers have successfully used social media, crowdsourcing platforms, and computer science students for recruiting, but recruitment is still a significant pain point in many studies. This short paper reflects on our experience recruiting developers, particularly for empirical privacy and security research, for multiple studies from 2019 to 2022.

Given the difficulties of studying the shoulder surfing resistance of authentication systems in a live setting, researchers often ask study participants to shoulder surf authentications by watching two-dimensional (2D) video recordings of a user authenticating. How-ever, these video recordings do not provide participants with a realistic shoulder surfing experience, creating uncertainty in the value and validity of lab-based shoulder surfing experiments. In this work, we exploit the unique characteristics of virtual reality (VR) and study the use of non-immersive/immersive VR recordings for shoulder surfing research. We conducted a user study (N=18) to explore the strengths and weaknesses of such a VR-based shoulder surfing research approach. Our results suggest that immersive VR observations result in a more realistic shoulder surfing experience, in a significantly higher sense of being part of the authentication environment, in a greater feeling of spatial presence, and in a higher level of involvement than 2D video observations without impacting participants’ observation performance. This suggests that studying shoulder surfing in VR is advantageous in many ways compared to currently used approaches, e.g., participants can freely choose their observation angle rather than being limited to a fixed observation angle as done in current methods. We discuss the strengths and weaknesses of using VR for shoulder surfing research and conclude with four recommendations to help researchers decide when (and when not) to employ VR for shoulder surfing research in the authentication research domain.

Privacy tasks can be challenging for developers, resulting in privacy frameworks and guidelines from the research community which are designed to assist developers in considering privacy features and applying privacy enhancing technologies in early stages of software development. However, how developers engage with privacy design strategies is not yet well understood. In this work, we look at the types of privacy-related advice developers give each other and how that advice maps to Hoepman’s privacy design strategies.We qualitatively analyzed 119 privacy-related accepted answers on Stack Overflow from the past five years and extracted 148 pieces of advice from these answers. We find that the advice is mostly around compliance with regulations and ensuring confidentiality with a focus on the inform, hide, control, and minimize of the Hoepman’s privacy design strategies. Other strategies, abstract, separate, enforce, and demonstrate, are rarely advised. Answers often include links to official documentation and online articles, highlighting the value of both official documentation and other informal materials such as blog posts. We make recommendations for promoting the under-stated strategies through tools, and detail the importance of providing better developer support to handle third-party data practices.

We introduce code-level dark patterns in ad networks. These are official code samples provided by ad networks that will result in user-facing dark patterns, if copy-pasted by developers. Developers who do not carefully read the code for all the nuanced consequences may endanger users privacy by using these code samples. We present three code samples from Google and Amazon ad networks where the code samples do not provide a "I do not consent" option for location data collection, the consent form keeps reappearing until the user consents, and the inclusion of unnecessary permissions when they are presented as "optional'' in the surrounding text.

This document provides a concrete version of the survey used in the URL reading experiment conducted in April 2017 and reported in the associated paper to appear at CHI'20 on 25 April, 2020. This documentation serves two purposes. First, it helps readers of the associated paper to perceive what the experiment participants have seen. Second, it provides more concrete details than the main paper to enable accurate replications of the experiment by interested researchers. Researchers who wish to use this survey in replication studies are encouraged to read the design rationale in the associated paper. The document presents the 46 fictitious Unified Resource Locators (URL) designed to empirically evaluate web users ability to read URLs and the exact wording of the associated multiple-choice questions. Each URL is associated with two questions: where this URL goes and how safe it is to click on it. These 46 URL trials systematically vary the URL structure, the number and brand names appearing in the URL and the position of the brand name in the URL. More details about the experiment results, survey design process and rationale can be found in the associated paper: Sara Albakry, Kami Vaniea, and Maria Wolters. What is this URL’s Destination: Empirical Evaluation of Web Users’ URL Reading. In Proceedings of the SIGCHI Conference on Human Factors in computing systems. ACM, 2020., One PDF document is included. The document includes an introduction explaining the survey overall flow and a flow diagram followed by four main sections representing the survey building blocks: Introduction, Consent Statement, Instructions, URL Reading Trials, and Demographics and Post-Survey Questions.