-
"Against the Void": An Interview and Survey Study on How Rust Developers Use Unsafe Code
Authors:
Ian McCormack,
Tomas Dougan,
Sam Estep,
Hanan Hibshi,
Jonathan Aldrich,
Joshua Sunshine
Abstract:
The Rust programming language is an increasingly popular choice for systems programming, since it can statically guarantee memory safety without automatic garbage collection. Rust provides its safety guarantees by restricting aliasing and mutability, but many key design patterns, such as cyclic aliasing and multi-language interoperation, must bypass these restrictions. Rust's $\texttt{unsafe}$ key…
▽ More
The Rust programming language is an increasingly popular choice for systems programming, since it can statically guarantee memory safety without automatic garbage collection. Rust provides its safety guarantees by restricting aliasing and mutability, but many key design patterns, such as cyclic aliasing and multi-language interoperation, must bypass these restrictions. Rust's $\texttt{unsafe}$ keyword enables features that developers can use to implement these patterns, and the Rust ecosystem includes useful tools for validating whether $\texttt{unsafe}$ code is used correctly. However, it is unclear if these tools are adequate for all use cases. To understand developers' needs, we conducted a mixed-methods study consisting of semi-structured interviews followed by a survey. We interviewed 19 Rust developers and surveyed 160 developers$\unicode{x2013}$all of whom engaged with $\texttt{unsafe}$ code. We found that 77% of survey respondents and a majority of interview participants were motivated to use $\texttt{unsafe}$ code because they were unaware of a safe alternative. Developers typically followed best-practices such as minimizing and localizing their use of $\texttt{unsafe}$ code, but only 23% were always certain that their encapsulations were sound. Limited tooling support for inline assembly and foreign function calls prevented developers from validating $\texttt{unsafe}$ code, and differences between Rust and other languages made foreign functions difficult to encapsulate. Verification tools were underused, and developers rarely audited their dependencies. Our results indicate a pressing need for production-ready tools that can validate the most frequently used $\texttt{unsafe}$ features.
△ Less
Submitted 17 April, 2024; v1 submitted 2 April, 2024;
originally announced April 2024.
-
Observations From an Online Security Competition and Its Implications on Crowdsourced Security
Authors:
Alejandro Cuevas,
Emma Hogan,
Hanan Hibshi,
Nicolas Christin
Abstract:
The crowd sourced security industry, particularly bug bounty programs, has grown dramatically over the past years and has become the main source of software security reviews for many companies. However, the academic literature has largely omitted security teams, particularly in crowd work contexts. As such, we know very little about how distributed security teams organize, collaborate, and what te…
▽ More
The crowd sourced security industry, particularly bug bounty programs, has grown dramatically over the past years and has become the main source of software security reviews for many companies. However, the academic literature has largely omitted security teams, particularly in crowd work contexts. As such, we know very little about how distributed security teams organize, collaborate, and what technology needs they have. We fill this gap by conducting focus groups with the top five teams (out of 18,201 participating teams) of a computer security Capture-the-Flag (CTF) competition. We find that these teams adopted a set of strategies centered on specialties, which allowed them to reduce issues relating to dispersion, double work, and lack of previous collaboration. Observing the current issues of a model centered on individual workers in security crowd work platforms, our study cases that scaling security work to teams is feasible and beneficial. Finally, we identify various areas which warrant future work, such as issues of social identity in high-skilled crowd work environments.
△ Less
Submitted 26 April, 2022;
originally announced April 2022.
-
Ask the Experts: What Should Be on an IoT Privacy and Security Label?
Authors:
Pardis Emami-Naeini,
Yuvraj Agarwal,
Lorrie Faith Cranor,
Hanan Hibshi
Abstract:
Information about the privacy and security of Internet of Things (IoT) devices is not readily available to consumers who want to consider it before making purchase decisions. While legislators have proposed adding succinct, consumer accessible, labels, they do not provide guidance on the content of these labels. In this paper, we report on the results of a series of interviews and surveys with pri…
▽ More
Information about the privacy and security of Internet of Things (IoT) devices is not readily available to consumers who want to consider it before making purchase decisions. While legislators have proposed adding succinct, consumer accessible, labels, they do not provide guidance on the content of these labels. In this paper, we report on the results of a series of interviews and surveys with privacy and security experts, as well as consumers, where we explore and test the design space of the content to include on an IoT privacy and security label. We conduct an expert elicitation study by following a three-round Delphi process with 22 privacy and security experts to identify the factors that experts believed are important for consumers when comparing the privacy and security of IoT devices to inform their purchase decisions. Based on how critical experts believed each factor is in conveying risk to consumers, we distributed these factors across two layers---a primary layer to display on the product package itself or prominently on a website, and a secondary layer available online through a web link or a QR code. We report on the experts' rationale and arguments used to support their choice of factors. Moreover, to study how consumers would perceive the privacy and security information specified by experts, we conducted a series of semi-structured interviews with 15 participants, who had purchased at least one IoT device (smart home device or wearable). Based on the results of our expert elicitation and consumer studies, we propose a prototype privacy and security label to help consumers make more informed IoT-related purchase decisions.
△ Less
Submitted 11 February, 2020;
originally announced February 2020.
