In Pakistan, where dating apps are subject to censorship, Facebook matrimony groups---also referred to as marriage groups---serve as alternative virtual spaces for members to search for potential life partners. To participate in these groups, members often share sensitive personal information such as photos, addresses, and phone numbers, which exposes them to risks such as fraud, blackmail, and identity theft. To better protect users of Facebook matrimony groups, we need to understand aspects related to user safety, such as how users perceive risks, what influences their trust in sharing personal information, and how they navigate security and privacy concerns when seeking potential partners online. In this study, through 23 semi-structured interviews, we explore how Pakistani users of Facebook matrimony groups perceive and navigate risks of sharing personal information, and how cultural norms and expectations influence their behavior in these groups.

Software developers face risks of leaking their software secrets, such as API keys or passwords, which can result in significant harm. Secret management tools (SMTs), such as HashiCorp Vault Secrets or Infisical, are highly recommended by industry, academia, and security guidelines to manage secrets securely. SMTs are designed to help developers secure their secrets in a central location, yet secrets leaks are still commonplace, and developers report difficulty in learning how to setup and use SMTs. While SMTs typically come with publicly available help resources (e.g., tool documentation and interfaces), it is unclear if these actually help developers learn to effectively use SMTs. Without usable help resources that onboards developers, quick adoption and effective use of SMTs may be unrealistic.

Vulnerability disclosures are necessary to improve the security of our digital ecosystem. However, they can also be challenging for researchers: it may be hard to find out who the affected parties even are, or how to contact them. Researchers may be ignored or face adversity when disclosing vulnerabilities. We investigate researchers' experiences with vulnerability disclosures, extract best practices, and make recommendations for researchers, institutions that employ them, industry, and regulators to enable effective vulnerability disclosures.

Ethical questions are discussed regularly in computer security. Still, researchers in computer security lack clear guidance on how to make, document, and assess ethical decisions in research when what is morally right or acceptable is not clear-cut. In this work, we give an overview of the discussion of ethical implications in current published work in computer security by reviewing all 1154 publications at top 4 security conferences published in 2024, finding inconsistent levels of ethics reporting with a strong focus of reporting institutional or ethics board approval, human subjects protection, and responsible disclosure, and a lack of discussion of balancing harms and benefits. We further report on the results of a semi-structured interview study with 24 computer security and privacy researchers (among whom were also: reviewers, ethics committee members, and/or program chairs) and their ethical decision-making both as authors and during peer review, finding a strong desire for ethical research, but a lack of consistency in considered values, ethical frameworks (if articulated), decision-making, and outcomes. We present an overview of the current state of the discussion of ethics and current de-facto standards in computer security research, contributing suggestions to improve the state of ethics in computer security research.

Digital security advice is the focus of much research, with unsatisfying results: End users do not follow experts' security advice, and users and experts struggle to prioritize existing advice. Several studies point out that users are over-whelmed by the amount of available security advice, and make recommendations on how to improve existing advice. Nevertheless, we still do not know how to effectively give security advice. Inspired by daily habit apps, we developed a set of 30 pieces of short and actionable advice, and the Security App, an Android smartphone app to provide this advice to end users, to reduce mental effort, and to build secure habits. We conducted a 30-day online end-user (N=74) study to evaluate whether the set of advice is actionable and meaningful to users, whether users adopt the advice, and whether the app has an impact on security awareness and behavior. Our results show that the app is an appropriate tool to provide security advice to end users. Participants perceive the majority of tasks as comprehensible, actionable, and useful, and we show that the app in fact introduces secure behaviors. Our results can serve as a basis for future research on security advice and creating secure habits, and the possibility to effectively teach secure behavior.

Reusable software libraries, frameworks, and components, such as those provided by open source ecosystems and third-party suppliers, accelerate digital innovation. However, recent years have shown almost exponential growth in attackers leveraging these software artifacts to launch software supply chain attacks. Past well-known software supply chain attacks include the SolarWinds, log4j, and xz utils incidents. Supply chain attacks are considered to have three major attack vectors: through vulnerabilities and malware accidentally or intentionally injected into open source and third-party dependencies/components/containers ; by infiltrating the build infrastructure during the build and deployment processes; and through targeted techniques aimed at the humans involved in software development, such as through social engineering. Plummeting trust in the software supply chain could decelerate digital innovation if the software industry reduces its use of open source and third-party artifacts to reduce risks. This article contains perspectives and knowledge obtained from intentional outreach with practitioners to understand their practical challenges and from extensive research efforts. We then provide an overview of current research efforts to secure the software supply chain. Finally, we propose a future research agenda to close software supply chain attack vectors and support the software industry.

The Russian Invasion of Ukraine in 2022 resulted in a rapidly changing cyber threat environment globally and incentivized the sharing of security and privacy advice on social media. Previous research found a strong impact of online security advice on end-user behavior.

This paper investigates the digital security experiences of four at-risk user groups in Germany, including older adults (70+), teenagers (14-17), people with migration backgrounds, and people with low formal education. Using computer-assisted telephone interviews, we sampled 250 participants per group, representative of region, gender, and partly age distributions. We examine their device usage, concerns, prior negative incidents, perceptions of potential attackers, and information sources. Our study provides the first quantitative and nationally representative insights into the digital security experiences of these four at-risk groups in Germany. Our findings show that participants with migration backgrounds used the most devices, sought more security information, and reported more experiences with cybercrime incidents than other groups. Older adults used the fewest devices and were least affected by cybercrimes. All groups relied on friends and family and online news as their primary sources of security information, with little concern about their social circles being potential attackers. We highlight the nuanced differences between the four at-risk groups and compare them to the broader German population when possible. We conclude by presenting recommendations for education, policy, and future research aimed at addressing the digital security needs of these at-risk user groups.

Moving to a new country often means that people leave their "known environment" and interact with new entities, often sharing sensitive and personal information. This exposes them to various risks. In this study, we investigate the challenges and concerns related to security, privacy, and data-sharing for people who have recently moved to the United States. Through semi-structured interviews (n=25), we find that most participants feel uncomfortable sharing documents containing their personal and sensitive information for the visa process e.g., their financial information and proof of relationship. Sharing this information makes participants concerned about their safety and privacy and sometimes violates their cultural information-sharing norms. Moving to a new environment, particularly to the US, also makes people vulnerable to fraud, specifically fraudulent online renting posts and scam calls. Those who move also navigate bureaucratic, administrative, and technical challenges that exacerbate their perceived security and privacy concerns. We further find a power imbalance that compels visa applicants to share all required information—to avoid getting their visa rejected—without feeling fully informed about the requirements and safeguards in place. Our study highlights the need for more guidance, transparency, and respect for individuals’ privacy from embassies and for technology designers to better support and protect those moving countries.

To ensure data-privacy compliance, it is common for companies to consult privacy experts for the identification and communication of privacy requirements to software developers. However, developers often fail to fulfill those requirements resulting in companies regularly being fined for violations due to non-compliance with privacy data regulations. To investigate why software developers struggle with the implementation of privacy requirements and explore their communication modality, we conducted a qualitative semi-structured interview study with 30 participants involving 10 software developers, 10 privacy experts, and 10 team coordinators with an average experience of nine years in the privacy communication and implementation process within a company context. We found a communication gap between software developers and privacy experts, suggesting a lack of proper procedural steps during the software development process to guarantee that the privacy requirements have been adequately addressed. We also uncovered that since privacy requirements were mostly communicated in a uni-directional manner, they were often perceived as a hindrance during software development, thus fostering an adversarial relationship between privacy experts and developers. Therefore, in order to fulfill the experts' requirements, software developers requested concrete steps to take during the software development process, as observed in the security field. However, privacy experts often lacked the technical knowledge to provide such instructions. This work contributes an explanatory theory on the communication gap between software developers and privacy experts. We discuss common obstacles in the communication of privacy experts and software developers and provide guidance on how to address them.

Multi-Factor Authentication is intended to strengthen the security of password-based authentication by adding another factor, such as hardware tokens or one-time passwords using mobile apps.

Usable and secure authentication on the web and beyond is mission-critical. While password-based authentication is still widespread, users have trouble dealing with potentially hundreds of online accounts and their passwords. Alternatives or extensions such as multi-factor authentication have their own challenges and find only limited adoption. Finding the right balance between security and usability is challenging for developers. Previous work found that developers use online resources to inform security decisions when writing code. Similar to other areas, lots of authentication advice for developers is available online, including blog posts, discussions on Stack Overflow, research papers, or guidelines by institutions like OWASP or NIST.

Misconceptions about digital security and privacy topics in the general public frequently lead to insecure behavior. However, little is known about the prevalence and extent of such misconceptions in a global context. In this work, we present the results of the first large-scale survey of a global population on misconceptions: We conducted an online survey with n = 12, 351 participants in 12 countries on four continents. By investigating influencing factors of misconceptions around eight common security and privacy topics (including E2EE, Wi-Fi, VPN, and malware), we find the country of residence to be the strongest estimate for holding misconceptions. We also identify differences between non-Western and Western countries, demonstrating the need for region-specific research on user security knowledge, perceptions, and behavior. While we did not observe many outright misconceptions, we did identify a lack of understanding and uncertainty about several fundamental privacy and security topics.

The 2020 Solarwinds attack was a tipping point that caused a heightened awareness about the security of the software supply chain and in particular the large amount of trust placed in build systems. Reproducible Builds (R-Bs) provide a strong foundation to build defenses for arbitrary attacks against build systems by ensuring that given the same source code, build environment, and build instructions, bitwise-identical artifacts are created. Unfortunately, much of the software industry believes R-Bs are too far out of reach for most projects. The goal of this paper is to help identify a path for R-Bs to become a commonplace property.To this end, we conducted a series of 24 semi-structured expert interviews with participants from the Reproducible-Builds.org project, finding that self-effective work by highly motivated developers and collaborative communication with upstream projects are key contributors to R-Bs. We identified a range of motivations that can encourage open source developers to strive for R-Bs, including indicators of quality, security benefits, and more efficient caching of artifacts. We also identify experiences that help and hinder adoption, which often revolves around communication with upstream projects. We conclude with recommendations on how to better integrate R-Bs with the efforts of the open source and free software community.

Security and privacy are often neglected in software development, and rarely a priority for developers. This insight is commonly based on research conducted by researchers and on developer populations living and working in the United States, Europe, and the United Kingdom. However, the production of software is global, and crucial populations in important technology hubs are not adequately studied. The software startup scene in Turkey is impactful, and comprehension, knowledge, and mitigations related to software security and privacy remain understudied. To close this research gap, we conducted a semi-structured interview study with 16 developers working in Turkish software startups. The goal of the interview study was to analyze if and how developers ensure that their software is secure and preserves user privacy. Our main finding is that developers rarely prioritize security and privacy, due to a lack of awareness, skills, and resources. We find that regulations can make a positive impact on security and privacy. Based on the study, we issue recommendations for industry, individual developers, research, educators, and regulators. Our recommendations can inform a more globalized approach to security and privacy in software development.

Cybercafes remain a popular way to access the Internet in the developing world as many users still lack access to personal computers. Coupled with the recent digitization of government services, e.g. in Kenya, many users have turned to cybercafes to access essential services. Many of these users may have never used a computer, and face significant security and privacy issues at cybercafes. Yet, these challenges as well as the advice offered remain largely unexplored. We investigate these challenges along with the security advice and support provided by the operators at cybercafes in Kenya through n = 36 semi-structured interviews (n = 14 with cybercafe managers and n = 22 with customers). We find that cybercafes serve a crucial role in Kenya by enabling access to printing and government services. However, most customers face challenges with computer usage as well as security and usability challenges with account creation and password management. As a workaround, customers often rely on the support and advice of cybercafe managers who mostly direct them to use passwords that are memorable, e.g. simply using their national ID numbers or names. Some managers directly manage passwords for their customers, with one even using the same password for all their customers. These results suggest the need for more awareness about phone-based password managers, as well as a need for computer training and security awareness among these users. There is also a need to explore security and privacy advice beyond Western peripheries to support broader populations.

Open source components are ubiquitous in companies’ setups, processes, and software. Utilizing these external components as building blocks enables companies to leverage the benefits of open source software, allowing them to focus their efforts on features and faster delivery instead of writing their own components. But by introducing these components into their software stack, companies inherit unique security challenges and attack surfaces: including code from potentially unvetted contributors and obligations to assess and mitigate the impact of vulnerabilities in external components.In 25 in-depth, semi-structured interviews with software developers, architects, and engineers from industry projects, we investigate their projects’ processes, decisions, and considerations in the context of external open source code. We find that open source components play an important role in many of our participants’ projects, that most projects have some form of company policy or at least best practice for including external code, and that many developers wish for more developer-hours, dedicated teams, or tools to better audit included components. Based on our findings, we discuss implications for company stakeholders and the open source software ecosystem. Overall, we appeal to companies to not treat the open source ecosystem as a free (software) supply chain and instead to contribute towards the health and security of the overall software ecosystem they benefit from and are part of.

Categorization via gender is omnipresent throughout society, and thus also computing; gender identity is often requested of users before they use software or web services. Despite this fact, no research has explored how software developers approach requesting gender disclosure from users. To understand how developers think about gender in software, we present an interview study with 15 software developers recruited from the freelancing platform Upwork as well as Twitter. We also collected and categorized 917 threads that contained keywords relevant to gender from programming-related sub-forums on the social media service Reddit. 16 posts that discussed approaches to gender disclosure were further analyzed. We found that while some developers have an understanding of inclusive gender options, programmers rarely consider when gender data is necessary or the way in which they request gender disclosure from users. Our findings have implications for programmers, software engineering educators, and the broader community concerned with inclusivity.

In the system and network administration domain, gender diversity remains a distant target. The experiences and perspectives of sysadmins who belong to marginalized genders (non cis-men) are not well understood beyond the fact that sysadmin work environments are generally not equitable. We address this knowledge gap in our study by focusing on the ways in which sysadmins from marginalized genders manage their work in men-dominated sysadmin work spaces and by understanding what an inclusive workplace would look like. Using a feminist research approach, we engaged with a group of 16 sysadmins who are not cis-men via six online focus groups. We found that managing the impact of gender identity in the sysadmin workplace means demonstrating excellence and going above and beyond in system administration tasks, and also requires performing additional care work not expected from cis men. Furthermore, our participants handle additional layers of work due to gender considerations and to actively find community in the workplace. We found that sysadmins manage by going above and beyond in their tasks, performing care work and doing extra layers of work because of gender considerations, and finding community in the workplace. To mitigate this additional workload, we recommend more care for care work. For future research, we recommend the use of feminist lenses when studying sysadmin work in order to provide more equitable solutions that ultimately contribute to improving system security by fostering a just workplace.

Hurricanes can cause catastrophic damage; it is critical for those affected to access information about conditions, loved ones, and resources. Prior work in the HCI and CSCW communities has focused on how social media can be vital during natural disasters; non-social media technologies have been under-researched. To understand how technology other than social media can support or harm people during crises, we explore hurricane survivors' use and disuse of multiple kinds of technologies in online surveys with 138 US participants. We find substantial technology use supporting survivors' comfort and safety other than social media. We also observe that designing technologies for high-resource environments--as with many mainstream apps--causes users to decrease use of potentially critical technologies during utility outages, which are common during hurricanes. With themes of both (a) broad technology use and (b) conditions preventing technology use, we make recommendations for technical design, policy, and research to empower communities susceptible to hurricanes.

For software to be secure in practice, users need to be willing and able to appropriately use security features. These features are usually implemented by software professionals during the software development process (SDP), who may be unable to consider the usability of these mechanisms. While research has made progress in supporting developers in creating secure software products, very little attention has been paid to whether and how these security features are made usable. In a semi-structured interview study with 25 software professionals (software developers, designers, architects), we explored how they and other decision-makers encounter and deal with security and usability during the software development process in their companies. Based on 37 hours of interview recordings, we qualitatively analyzed and investigated 23 distinct development contexts in detail. In addition to individual awareness and factors that directly influence the implementation phase, we identify a high impact of contextual factors, such as stakeholder pressure, presence of expertise, and collaboration culture, and the specific implementation of the SDP on usable security in software products. We conclude our work by highlighting important gaps, such as studying and improving contextual factors that contribute to usable security and discussing potential improvements of the status quo.

Timing attacks are among the most devastating side-channel attacks, allowing remote attackers to retrieve secret material, including cryptographic keys, with relative ease. In principle, “these attacks are not that hard to mitigate the basic intuition, captured by the constant-time criterion, is that control-flow and memory accesses should be independent from secrets. Furthermore, there is a broad range of tools for automatically checking adherence to this intuition. Yet, these attacks still plague popular cryptographic libraries twenty-five years after their discovery, reflecting a dangerous gap between academic research and cryptographic engineering. This gap can potentially undermine the emerging shift towards high-assurance, formally verified cryptographic libraries. However, the causes for this gap remain uninvestigated. To understand the causes of this gap, we conducted a survey with 44 developers of 27 prominent open-source cryptographic libraries. The goal of the survey was to analyze if and how the developers ensure that their code executes in constant time. Our main findings are that developers are aware of timing attacks and of their potentially dramatic consequences and yet often prioritize other issues over the perceived huge investment of time and resources currently needed to make their code resistant to timing attacks. Based on the survey, we identify several shortcomings in existing analysis tools for constant-time, and issue recommendations that can make writing constant-time libraries less difficult. Our recommendations can inform future development of analysis tools, security-aware compilers, and cryptographic libraries, not only for constant-timeness, but in the broader context of side-channel attacks, in particular for micro-architectural side-channel attacks, which are a younger topic and too recent as focus for this survey.

The usage of mobile loan applications has proliferated in developing countries. This is due to the ease and speed in which they disburse small loans to users, compared to traditional financial institutions, such as banks, that only offer similar loans based on existing customer relationship or collateral. As mobile loan apps are a relatively new industry, these apps are mostly unregulated and therefore tend to charge extremely high interest rates. Further, they collect and sometimes misuse sensitive user data through the course of verifying customers and ensuring loan repayment, such as users’ contacts and SMS communications through the mobile device permission system. Yet, the reasons for usage as well as privacy concerns with these mobile loan apps in the developing world, and specifically in Kenya, remain largely unexplored. To investigate mobile loan apps, we conducted semi-structured interviews (n = 20) with loan app users in Kenya, and we find that most users generally have privacy concerns, particularly regarding access to their phones’ contacts. However, they often overlook these concerns as this outweighs their need to procure loans. At the same time, we find that users struggle to understand the use of permissions by these mobile loan apps (and mobile apps generally), confirming prior research on comprehension of Android permissions. Our results highlight privacy risks, concerns and behavior with the emerging mobile loan app marketplace in the developing world, and we offer recommendations that can help protect their users’ security and privacy, including the need for transparent communication by these apps on how they collect, use and secure their users’ data.

Email is one of the main communication tools and has seen significant adoption in the past decades. However, emails are sent in plain text by default and allow attackers easy access. Users can protect their emails by end-to-end encrypting them using tools such as S/MIME or PGP.Although PGP had already been introduced in 1991, it is a commonly held belief that email encryption is a niche tool that has not seen widespread adoption to date. Previous user studies identified ample usability issues with email encryption such as key management and user interface challenges, which likely contribute to the limited success of email encryption.However, so far ground truth based on longitudinal field data is missing in the literature. Towards filling this gap, we measure the use of email encryption based on 27 years of data for 37,089 users at a large university. While attending to ethical and data privacy concerns, we were able to analyze the use of S/MIME and PGP in 81,612,595 emails.We found that only 5.46% of all users ever used S/MIME or PGP. This led to 0.06% encrypted and 2.8% signed emails. Users were more likely to use S/MIME than PGP by a factor of six. We saw that using multiple email clients had a negative impact on signing as well as encrypting emails and that only 3.36% of all emails between S/MIME users who had previously exchanged certificates were encrypted on average.Our results imply that the adoption of email encryption is indeed very low and that key management challenges negatively impact even users who have set up S/MIME or PGP previously.

Open Source Software plays an important role in many software ecosystems. Whether in operating systems, network stacks, or as low-level system drivers, software we encounter daily is permeated with code contributions from open source projects. Decentralized development and open collaboration in open source projects introduce unique challenges: code submissions from unknown entities, limited personpower for commit or dependency reviews, and bringing new contributors up-to-date in projects’ best practices & processes.In 27 in-depth, semi-structured interviews with owners, maintainers, and contributors from a diverse set of open source projects, we investigate their security and trust practices. For this, we explore projects’ behind-the-scene processes, provided guidance & policies, as well as incident handling & encountered challenges. We find that our participants’ projects are highly diverse both in deployed security measures and trust processes, as well as their underlying motivations. Based on our findings, we discuss implications for the open source software ecosystem and how the research community can better support open source projects in trust and security considerations. Overall, we argue for supporting open source projects in ways that consider their individual strengths and limitations, especially in the case of smaller projects with low contributor numbers and limited access to resources.

Password managers are tools to support users with the secure generation and storage of credentials and logins used in online accounts. Previous work illustrated that building password managers means facing various security and usability challenges. For strong security and good usability, the interaction between password managers and websites needs to be smooth and effortless. However, user reviews for popular password managers suggest interaction problems for some websites. Therefore, to the best of our knowledge, this work is the first to systematically identify these interaction problems and investigate how 15 desktop password managers, including the ten most popular ones, are affected. We use a qualitative analysis approach to identify 39 interaction problems from 2,947 user reviews and 372 GitHub issues for 30 password managers. Next, we implement minimal working examples (MWEs) for all interaction problems we found and evaluate them for all password managers in 585 test cases.Our results illustrate that a) password managers struggle to correctly implement authentication features such as HTTP Basic Authentication and modern standards such as the autocomplete-attribute and b) websites fail to implement clean and well-structured authentication forms. We conclude that some of our findings can be addressed by either PWM providers or web-developers by adhering to already existing standards, recommendations and best practices, while other cases are currently almost impossible to implement securely and require further research.

The positive effect of security information communicated to developers through API warnings has been established. However, current prototypical designs are based on security warnings for end-users. To improve security feedback for developers, we conducted a participatory design study with 25 professional software developers in focus groups. We identify which security information is considered helpful in avoiding insecure cryptographic API use during development. Concerning console messages, participants suggested five core elements, namely message classification, title message, code location, link to detailed external resources, and color. Design guidelines for end-user warnings are only partially suitable in this context. Participants emphasized the importance of tailoring the detail and content of security information to the context. Console warnings call for concise communication; further information needs to be linked externally. Therefore, security feedback should transcend tools and should be adjustable by software developers across development tools, considering the work context and developer needs.

Android applications are frequently plagiarized or repackaged, and software obfuscation is a recommended protection against these practices. However, there is very little data on the overall rates of app obfuscation, the techniques used, or factors that lead to developers to choose to obfuscate their apps. In this paper, we present the first comprehensive analysis of the use of and challenges to software obfuscation in Android applications. We analyzed 1.7 million free Android apps from Google Play to detect various obfuscation techniques, finding that only 24.92% of apps are obfuscated by the developer. To better understand this rate of obfuscation, we surveyed 308 Google Play developers about their experiences and attitudes about obfuscation. We found that while developers feel that apps in general are at risk of plagiarism, they do not fear theft of their own apps. Developers also report difficulties obfuscating their own apps. To better understand, we conducted a follow-up study where the vast majority of 70 participants failed to obfuscate a realistic sample app even while many mistakenly believed they had been successful. These findings have broad implications both for improving the security of Android apps and for all tools that aim to help developers write more secure software.

Mobile apps are increasingly created using online application generators (OAGs) that automate app development, distribution, and maintenance. These tools significantly lower the level of technical skill that is required for app development, which makes them particularly appealing to citizen developers, i.e., developers with little or no software engineering background. However, as the pervasiveness of these tools increases, so does their overall influence on the mobile ecosystem's security, as security lapses by such generators affect thousands of generated apps. The security of such generated apps, as well as their impact on the security of the overall app ecosystem, has not yet been investigated. We present the first comprehensive classification of commonly used OAGs for Android and show how to fingerprint uniquely generated apps to link them back to their generator. We thereby quantify the market penetration of these OAGs based on a corpus of 2,291,898 free Android apps from Google Play and discover that at least 11.1% of these apps were created using OAGs. Using a combination of dynamic, static, and manual analysis, we find that the services' app generation model is based on boilerplate code that is prone to reconfiguration attacks in 7/13 analyzed OAGs. Moreover, we show that this boilerplate code includes well-known security issues such as code injection vulnerabilities and insecure WebViews. Given the tight coupling of generated apps with their services' backends, we further identify security issues in their infrastructure. Due to the blackbox development approach, citizen developers are unaware of these hidden problems that ultimately put the end-users sensitive data and privacy at risk and violate the user's trust assumption. A particular worrisome result of our study is that OAGs indeed have a significant amplification factor for those vulnerabilities, notably harming the health of the overall mobile app ecosystem.

All major web browsers include a private browsing mode that does not store browsing history, cookies, or temporary files across browsing sessions. Unfortunately, users have misconceptions about what this mode does. Many factors likely contribute to these misconceptions. In this paper, we focus on browsers» disclosures, or their in-browser explanations of private browsing mode. In a 460-participant online study, each participant saw one of 13 different disclosures (the desktop and mobile disclosures of six popular browsers, plus a control). Based on the disclosure they saw, participants answered questions about what would happen in twenty browsing scenarios capturing previously documented misconceptions. We found that browsers» disclosures fail to correct the majority of the misconceptions we tested. These misconceptions included beliefs that private browsing mode would prevent geolocation, advertisements, viruses, and tracking by both the websites visited and the network provider. Furthermore, participants who saw certain disclosures were more likely to have misconceptions about private browsing»s impact on targeted advertising, the persistence of lists of downloaded files, and tracking by ISPs, employers, and governments.

Third-party libraries in Android apps have repeatedly been shown to be hazards to the users' privacy and an amplification of their host apps' attack surface. A particularly aggravating factor to this situation is that the libraries' version included in apps are very often outdated.

Despite security advice in the official documentation and an extensive body of security research about vulnerabilities and exploits, many developers still fail to write secure Android applications. Frequently, Android developers fail to adhere to security best practices, leaving applications vulnerable to a multitude of attacks. We point out the advantage of a low-time-cost tool both to teach better secure coding and to improve app security. Using the FixDroid IDE plug-in, we show that professional and hobby app developers can work with and learn from an in-environment tool without it impacting their normal work; and by performing studies with both students and professional developers, we identify key UI requirements and demonstrate that code delivered with such a tool by developers previously inexperienced in security contains significantly less security problems. Perfecting and adding such tools to the Android development environment is an essential step in getting both security and privacy for the next generation of apps.

Potentially dangerous cryptography errors are well-documented in many applications. Conventional wisdom suggests that many of these errors are caused by cryptographic Application Programming Interfaces (APIs) that are too complicated, have insecure defaults, or are poorly documented. To address this problem, researchers have created several cryptographic libraries that they claim are more usable, however, none of these libraries have been empirically evaluated for their ability to promote more secure development. This paper is the first to examine both how and why the design and resulting usability of different cryptographic libraries affects the security of code written with them, with the goal of understanding how to build effective future libraries. We conducted a controlled experiment in which 256 Python developers recruited from GitHub attempt common tasks involving symmetric and asymmetric cryptography using one of five different APIs. We examine their resulting code for functional correctness and security, and compare their results to their self-reported sentiment about their assigned library. Our results suggest that while APIs designed for simplicity can provide security benefits - reducing the decision space, as expected, prevents choice of insecure parameters - simplicity is not enough. Poor documentation, missing code examples, and a lack of auxiliary features such as secure key storage, caused even participants assigned to simplified libraries to struggle with both basic functional correctness and security. Surprisingly, the availability of comprehensive documentation and easy-to-use code examples seems to compensate for more complicated APIs in terms of functionally correct results and participant reactions, however, this did not extend to security results. We find it particularly concerning that for about 20% of functionally correct tasks, across libraries, participants believed their code was secure when it was not. Our results suggest that while new cryptographic libraries that want to promote effective security should offer a simple, convenient interface, this is not enough: they should also, and perhaps more importantly, ensure support for a broad range of common tasks and provide accessible documentation with secure, easy-to-use code examples.

Online programming discussion platforms such as Stack Overflow serve as a rich source of information for software developers. Available information include vibrant discussions and oftentimes ready-to-use code snippets. Previous research identified Stack Overflow as one of the most important information sources developers rely on. Anecdotes report that software developers copy and paste code snippets from those information sources for convenience reasons. Such behavior results in a constant flow of community-provided code snippets into production software. To date, the impact of this behaviour on code security is unknown. We answer this highly important question by quantifying the proliferation of security-related code snippets from Stack Overflow in Android applications available on Google Play. Access to the rich source of information available on Stack Overflow including ready-to-use code snippets provides huge benefits for software developers. However, when it comes to code security there are some caveats to bear in mind: Due to the complex nature of code security, it is very difficult to provide ready-to-use and secure solutions for every problem. Hence, integrating a security-related code snippet from Stack Overflow into production software requires caution and expertise. Unsurprisingly, we observed insecure code snippets being copied into Android applications millions of users install from Google Play every day. To quantitatively evaluate the extent of this observation, we scanned Stack Overflow for code snippets and evaluated their security score using a stochastic gradient descent classifier. In order to identify code reuse in Android applications, we applied state-of-the-art static analysis. Our results are alarming: 15.4% of the 1.3 million Android applications we analyzed, contained security-related code snippets from Stack Overflow. Out of these 97.9% contain at least one insecure code snippet.

Android security and privacy research has boomed in recent years, far outstripping investigations of other appified platforms. However, despite this attention, research efforts are fragmented and lack any coherent evaluation framework. We present a systematization of Android security and privacy research with a focus on the appification of software systems. To put Android security and privacy research into context, we compare the concept of appification with conventional operating system and software ecosystems. While appification has improved some issues (e.g., market access and usability), it has also introduced a whole range of new problems and aggravated some problems of the old ecosystems (e.g., coarse and unclear policy, poor software development practices). Some of our key findings are that contemporary research frequently stays on the beaten path instead of following unconventional and often promising new routes. Many security and privacy proposals focus entirely on the Android OS and do not take advantage of the unique features and actors of an appified ecosystem, which could be used to roll out new security mechanisms less disruptively. Our work highlights areas that have received the larger shares of attention, which attacker models were addressed, who is the target, and who has the capabilities and incentives to implement the countermeasures. We conclude with lessons learned from comparing the appified with the old world, shedding light on missed opportunities and proposing directions for future research.

Vulnerabilities in Android code -- including but not limited to insecure data storage, unprotected inter-component communication, broken TLS implementations, and violations of least privilege -- have enabled real-world privacy leaks and motivated research cataloguing their prevalence and impact. Researchers have speculated that appification promotes security problems, as it increasingly allows inexperienced laymen to develop complex and sensitive apps. Anecdotally, Internet resources such as Stack Overflow are blamed for promoting insecure solutions that are naively copy-pasted by inexperienced developers. In this paper, we for the first time systematically analyzed how the use of information resources impacts code security. We first surveyed 295 app developers who have published in the Google Play market concerning how they use resources to solve security-related problems. Based on the survey results, we conducted a lab study with 54 Android developers (students and professionals), in which participants wrote security-and privacy-relevant code under time constraints. The participants were assigned to one of four conditions: free choice of resources, Stack Overflow only, official Android documentation only, or books only. Those participants who were allowed to use only Stack Overflow produced significantly less secure code than those using, the official Android documentation or books, while participants using the official Android documentation produced significantly less functional code than those using Stack Overflow. To assess the quality of Stack Overflow as a resource, we surveyed the 139 threads our participants accessed during the study, finding that only 25% of them were helpful in solving the assigned tasks and only 17% of them contained secure code snippets. In order to obtain ground truth concerning the prevalence of the secure and insecure code our participants wrote in the lab study, we statically analyzed a random sample of 200,000 apps from Google Play, finding that 93.6% of the apps used at least one of the API calls our participants used during our study. We also found that many of the security errors made by our participants also appear in the wild, possibly also originating in the use of Stack Overflow to solve programming problems. Taken together, our results confirm that API documentation is secure but hard to use, while informal documentation such as Stack Overflow is more accessible but often leads to insecurity. Given time constraints and economic pressures, we can expect that Android developers will continue to choose those resources that are easiest to use, therefore, our results firmly establish the need for secure-but-usable documentation.

Despite the security community's best effort, the number of serious vulnerabilities discovered in software is increasing rapidly. In theory, security audits should find and remove the vulnerabilities before the code ever gets deployed. However, due to the enormous amount of code being produced, as well as a the lack of manpower and expertise, not all code is sufficiently audited. Thus, many vulnerabilities slip into production systems. A best-practice approach is to use a code metric analysis tool, such as Flawfinder, to flag potentially dangerous code so that it can receive special attention. However, because these tools have a very high false-positive rate, the manual effort needed to find vulnerabilities remains overwhelming. In this paper, we present a new method of finding potentially dangerous code in code repositories with a significantly lower false-positive rate than comparable systems. We combine code-metric analysis with metadata gathered from code repositories to help code review teams prioritize their work. The paper makes three contributions. First, we conducted the first large-scale mapping of CVEs to GitHub commits in order to create a vulnerable commit database. Second, based on this database, we trained a SVM classifier to flag suspicious commits. Compared to Flawfinder, our approach reduces the amount of false alarms by over 99 % at the same level of recall. Finally, we present a thorough quantitative and qualitative analysis of our approach and discuss lessons learned from the results. We will share the database as a benchmark for future research and will also provide our analysis tool as a web service.

Previous research showed that the SSL infrastructure is a fragile system: X.509 certificate validation fails for a non-trivial number of HTTPS-enabled websites resulting in SSL warning messages presented to users. Studies revealed that warning messages do not provide easy-to-understand information or are ignored by webbrowser users. SSL warning messages are a critical component in the HTTPS infrastructure and many attempts have been made to improve these warning messages. However, an important question has not received sufficient attention yet: Why do webmasters (deliberately) deploy non-validating, security-critical X.509 certificates on publicly available websites? In this paper, we conduct the first study with webmasters operating non-validating X.509 certificates to understand their motives behind deploying those certificates. We extracted the non-validating certificates from Google's webcrawler body of X.509 certificates, informed webmasters about the problem with the X.509 certificate configuration on their website and invited a random sample of the respective webmasters to participate in our study. 755 webmasters participated, allowing us insight into their motives. While one third of them admitted to having misconfigured their webserver accidentally, two thirds of them gave reasons for deliberately using a non-validating X.509 certificate.

The ecological validity of password studies is a complex topic and difficult to quantify. Most researchers who conduct password user studies try to address the issue in their study design. However, the methods researchers use to try to improve ecological validity vary and some methods even contradict each other. One reason for this is that the very nature of the problem of ecological validity of password studies is hard to study, due to the lack of ground truth. In this paper, we present a study on the ecological validity of password studies designed specifically to shed light on this issue. We were able to compare the behavior of 645 study participants with their real world password choices. We conducted both online and laboratory studies, under priming and non-priming conditions, to be able to evaluate the effects of these different forms of password studies. While our study is able to investigate only one specific password environment used by a limited population and thus cannot answer all questions about ecological validity, it does represent a first important step in judging the impact of ecological validity on password studies.