”Sorry for bugging you so much.“ Exploring Developers’ Behavior Towards Privacy-Compliant Implementation

”Sorry for bugging you so much.“ Exploring Developers’ Behavior Towards Privacy-Compliant Implementation

Speakers: Stefan Albert Horstmann, Sandy Hong, David Klein, Raphael Serafini, Martin Degeling, Martin Johns

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=dJx1gLcnOOk

Overview

In an era defined by stringent data protection regulations such as the General Data Protection Regulation (GDPR) in the European Union and the California Consumer Privacy Act (CCPA), companies face significant legal and financial repercussions for mishandling user data. While legal departments set the compliance frameworks, the ultimate responsibility for implementing these requirements often falls squarely on the shoulders of software developers. This talk, presented by Stefan Albert Horstmann and his co-authors at IEEE S&P, delves into a critical yet underexplored area: how software developers actually navigate and implement privacy-compliant solutions in their daily work.

The research presented in "Sorry for bugging you so much." reveals a concerning gap between legal mandates and practical implementation. Developers, often lacking specialized legal knowledge and facing pressure to deliver functionality, struggle to integrate privacy considerations effectively. The study illuminates the challenges developers encounter, from a "functionality-first" mindset to difficulties in accessing and understanding privacy-related resources, and even hesitation in engaging with legal experts.

This talk is crucial because it highlights a systemic vulnerability in the privacy posture of organizations. Despite the existence of robust privacy laws and the potential for substantial fines—examples of which are frequently seen under GDPR—many software implementations remain non-compliant due to issues at the development stage. By examining developer behavior, the researchers provide actionable insights for improving developer support, streamlining privacy integration, and ultimately fostering a more secure and compliant software ecosystem.

Background

▶ Watch: Introduction: Developers' challenge with privacy laws (0:00)

The landscape of data privacy has been dramatically reshaped by comprehensive regulations like the GDPR and CCPA. These laws impose strict obligations on how organizations collect, process, store, and delete personal data, granting individuals greater control over their information. Non-compliance can lead to severe penalties, with GDPR fines, for instance, reaching tens of millions of euros or a percentage of global annual turnover. The increasing frequency and severity of these fines underscore the urgent need for organizations to embed privacy by design into all aspects of their operations, particularly software development.

Software developers are at the forefront of this challenge. They are the ones translating abstract legal requirements into concrete code, building the systems that handle sensitive user data. However, legal expertise is a specialized and costly skill, rarely possessed by software engineers. This disparity leaves developers in a precarious position: tasked with implementing complex legal mandates without adequate training or accessible resources. Traditional software development methodologies often prioritize functionality, performance, and security, with privacy sometimes treated as an afterthought or a separate compliance checklist item rather than an integral design principle.

Prior work in software engineering and privacy has often focused on privacy-enhancing technologies (PETs), formal methods for privacy verification, or high-level privacy-by-design principles. However, there has been less empirical research directly observing developer behavior in real-world or simulated development scenarios when confronted with privacy compliance tasks. The gap lies in understanding the practical difficulties, cognitive biases, and resource utilization patterns of developers when they are asked to make their software privacy-compliant. This study aims to fill that void by providing an empirical foundation for understanding the human factors involved in privacy-compliant software development, identifying why violations occur despite good intentions, and suggesting practical interventions.

Key Findings

▶ Watch: Three Study Groups: Control, prompted, and expert-supported (2:50)

The study's results painted a stark picture of the challenges developers face in achieving privacy compliance. Despite participants being generally proficient in functional implementation, their success in addressing privacy requirements was remarkably low across all groups.

Firstly, the overall privacy compliance rate was a mere 15% across all tasks and participants. This figure is particularly striking given that participants generally completed the functional aspects of the tasks with about 73% of solutions being functionally correct. Even more concerning, many participants had ample time remaining—an average of 1.5 hours—yet did not use this time to improve privacy compliance. This indicates that the problem is not merely a lack of time, but rather a deeper systemic issue in how privacy is perceived and integrated into the development workflow.

Secondly, a significant finding was the pervasive "functionality-first mindset" among developers. Participants explicitly stated that they would prioritize completing the core functionality of the application before even considering privacy aspects. One participant articulated this by saying they "would have started looking for this if they finished the tasks." This mindset inherently relegates privacy to an afterthought, ensuring that privacy issues often remain unaddressed or are only superficially tackled late in the development cycle, if at all.

Thirdly, developers expressed significant difficulty in finding and understanding privacy-related resources. The information available, whether from legal texts or online searches, was often described as "legal ease"—dense, jargon-filled, and challenging for individuals without a legal background to interpret and apply to code. This barrier to understanding contributes directly to the low compliance rates, as developers cannot effectively implement what they cannot comprehend. The study observed very few online searches regarding privacy, reinforcing the idea that developers either did not know where to look or found the existing resources unhelpful.

Fourthly, despite having access to a privacy expert, participants in the expert-supported group showed a surprising hesitation to engage with the expert. Only four out of ten participants in this group reached out for assistance. Even the participant who interacted the most with the expert felt compelled to apologize, stating, "Thanks again and sorry for bugging you so much lately." This highlights a potential communication barrier or a fear of appearing incompetent, preventing developers from leveraging valuable resources when available.

Finally, participants exhibited low confidence in the compliance of their solutions. On average, they rated their confidence at a mere 1.5 out of 5. This low confidence, coupled with the low utilization of available resources (like the privacy expert or online searches), suggests a self-perpetuating cycle: developers are unsure, but the perceived difficulty or social cost of seeking help prevents them from improving their understanding or solutions. The results clearly indicate that simply making resources available is not enough; the way these resources are presented and accessed needs fundamental improvement.

Technical Deep Dive

▶ Watch: Key Finding: Low privacy compliance despite functional solutions (4:20)

The core of this research lies in its meticulously designed empirical study, which sought to observe developer behavior in a controlled environment. The researchers created a lab setup to ensure they could monitor participants' interactions with various resources, including websites and large language models (LLMs), during task implementation.

The study recruited 30 participants, divided equally into three distinct groups of ten. Participant screening was rigorous, ensuring they possessed adequate programming skills and had no prior experience in studies specifically focused on privacy. This controlled recruitment aimed to minimize confounding variables and capture natural developer behavior. Each participant was compensated €315 for their involvement, with the study lasting a maximum of five hours.

Participants were tasked with implementing four distinct functions for a health application, a context chosen for its inherent sensitivity regarding personal data. Each task was designed to subtly embed specific privacy challenges:

1. Backup Function Error Fix: This served as a warm-up task. Participants were asked to fix an error in the application's backup function. Crucially, this task itself contained no immediate privacy issues, but it was intended to make participants aware of the backup mechanism, which would become highly relevant for the subsequent privacy-centric task.
2. Data Deletion Request: Following the warm-up, participants received a simulated data deletion request for one of the application's users. A compliant solution here required not only deleting or anonymizing the user's data within the live database but also ensuring that the data was appropriately handled within any existing backups. This task directly tested understanding of the "right to be forgotten" and the comprehensive scope of data deletion requirements.
3. Doctor Search Function: Participants were asked to implement a search function allowing doctors to look up patients' past treatments or diseases. A naive implementation would grant doctors access to data from all registered users. For a compliant solution, participants needed to implement filtering options to ensure doctors could only access data for patients they were authorized to treat, thereby addressing principles of access control and data minimization.
4. Automated Advertisement Emails: The final task involved creating an automated function to send advertisement emails to users. Since the application's users had not explicitly given consent for marketing communications, a compliant solution mandated the implementation of some form of consent management system. This task specifically targeted the GDPR's requirements for explicit consent for data processing activities like direct marketing.

To investigate developer behavior under different conditions, the 30 participants were divided into three experimental groups:

1. Control Group: This group received only the functional tasks with no explicit instructions or prompts regarding privacy. The goal was to observe their natural behavior towards privacy during software development, without any external influence.
2. Prompted Group: Participants in this group were explicitly informed that user privacy was "very important" and that all their solutions should be compliant with privacy regulations. This group aimed to assess how developers behave when they are aware of privacy requirements and are expected to identify and address issues independently.
3. Expert-Supported Group: This group received the same privacy prompt as the "Prompted Group" but also had access to an on-demand privacy expert via a chat function. The expert was available to answer any questions participants had regarding privacy and compliance. This group was designed to explore the types of questions developers ask, the effectiveness of expert consultation, and any barriers to communication.

Data collection involved a multi-faceted approach. Beyond observing their code and the resources they used, researchers conducted a short survey after task completion to gauge participants' confidence in their solutions' compliance. This was followed by an in-depth interview to delve into their thought processes, challenges, and reasons behind their decisions, particularly regarding their approach to privacy. This comprehensive methodological design allowed the researchers to gather both quantitative data on compliance rates and qualitative insights into the underlying cognitive and behavioral factors influencing privacy implementation.

Demo / Proof of Concept

▶ Watch: Reasons: Functionality-first, legal-ease, fear of bothering experts (6:00)

While the talk did not feature a traditional live demonstration of a software exploit or a new security tool, the entire experimental setup and its execution served as a powerful proof of concept for the researchers' central hypothesis: that developers struggle significantly with privacy compliance, even when aware of its importance. The study itself was the demonstration, showcasing developer behavior in a controlled, yet realistic, development environment.

The "demo" comprised participants actively coding and attempting to solve the four tasks, each embedded with subtle privacy challenges. The researchers observed in real-time how developers approached these tasks, which resources they consulted (or didn't consult), and their ultimate success or failure in achieving privacy compliance. For instance, the implementation of the doctor search function by participants vividly demonstrated the difference between a naive, non-compliant approach (granting access to all patient data) and a compliant one (implementing granular access controls). Similarly, the automated advertisement email task directly showed whether developers considered and implemented consent mechanisms or simply proceeded with sending emails without explicit user permission.

The interactions (or lack thereof) with the privacy expert in the expert-supported group further acted as a "demo" of the communication barriers that exist between technical and legal teams. The observed hesitation and even apologies for seeking help provided concrete evidence of the social and psychological factors that impede effective privacy integration. Thus, the "demo" was not a technical gadget, but a meticulously constructed human-centric experiment that provided empirical evidence of developer behavior and the systemic issues preventing privacy-by-design from becoming a widespread reality.

Defensive Implications

▶ Watch: Recommendations: Improve support for privacy in development (6:50)

The findings from "Sorry for bugging you so much." provide critical insights for organizations aiming to strengthen their privacy posture and avoid costly compliance failures. The implications for defenders, particularly those involved in security architecture, privacy engineering, and developer education, are profound.

Firstly, the pervasive "functionality-first mindset" necessitates a fundamental shift in development culture. Privacy cannot remain an afterthought; it must be integrated into the Software Development Life Cycle (SDLC) from the earliest design phases. Organizations should adopt Privacy-by-Design (PbD) principles, ensuring that privacy requirements are treated with the same priority as functional, performance, and security requirements. This means privacy should be part of initial requirement gathering, architectural design, and sprint planning, not merely a late-stage review. Regular privacy impact assessments (PIAs) should be mandatory for new features or data processing activities.

Secondly, the difficulty developers face in understanding "legal ease" demands the creation of developer-friendly privacy resources. Legal teams need to collaborate with technical writers and developer advocates to translate complex legal texts into actionable, concise, and code-centric guidelines. These resources should include:

• Clear, practical examples: How to implement specific GDPR articles (e.g., data deletion, consent management) in common programming languages or frameworks.
• Accessible documentation: Centralized, easily searchable wikis or internal portals containing privacy policies, compliance checklists, and best practices.
• Training modules: Short, focused training sessions or e-learning modules specifically designed for developers, explaining privacy principles with a technical lens.
• Automated tools: Integration of static analysis tools or linters that can flag common privacy anti-patterns in code, providing real-time feedback.

Thirdly, the observed hesitation to communicate with privacy experts highlights a need to foster an open and supportive communication culture between legal and development teams. Companies should actively encourage developers to consult with legal experts without fear of judgment or "bugging" them. Strategies could include:

• Dedicated privacy champions: Appointing privacy-savvy developers within teams who can act as first points of contact and liaisons with legal.
• Scheduled "privacy office hours": Regular, informal sessions where developers can drop in with questions for legal experts.
• Shared communication channels: Dedicated chat channels or forums where legal and development teams can collaborate on privacy issues.
• Cross-functional training: Legal teams understanding basic software development concepts, and developers understanding key legal principles.

Finally, while AI systems (like large language models) were not heavily used in this study, their increasing prevalence in development workflows presents both an opportunity and a risk. Defenders must be cautious: while AI could potentially assist developers in understanding privacy requirements or generating compliant code snippets, there's a significant risk of inaccurate or hallucinated information. Organizations must establish clear guidelines for using AI in privacy-sensitive development, emphasizing human oversight and verification of AI-generated code for compliance. This also implies a need for research into how to train and fine-tune AI models for accurate privacy compliance guidance.

By addressing these defensive implications, organizations can move beyond a reactive compliance mindset to proactive privacy engineering, embedding privacy as a core quality attribute of their software products.

Key Takeaways

• Privacy is an Afterthought: Developers overwhelmingly exhibit a "functionality-first" mindset, relegating privacy considerations to later stages of development, leading to low compliance rates (15%).
• Legal Jargon is a Barrier: Developers struggle to find and understand privacy-related legal information, often describing it as "legal ease," making it difficult to translate into code.
• Communication Gaps Exist: Even when privacy experts are available, developers are hesitant to seek help, indicating communication barriers and potential fear of "bugging" experts.
• Low Confidence in Compliance: Developers have very low confidence in the privacy compliance of their solutions (1.5 out of 5), yet often don't utilize available resources to improve.
• Proactive Integration is Key: Privacy must be integrated early into the Software Development Life Cycle (SDLC) and treated as a first-class requirement, not an add-on.
• Developer-Friendly Resources are Essential: Organizations need to provide clear, actionable, and technically relevant privacy guidelines and training to empower developers.

About the Speaker(s)

Stefan Albert Horstmann is the lead presenter of this paper, "Sorry for bugging you so much." He, along with his co-authors Sandy Hong, David Klein, Raphael Serafini, Martin Degeling, and Martin Johns, conducted this empirical research presented at the IEEE S&P conference. Their work focuses on understanding the human factors involved in privacy-compliant software development, identifying practical challenges developers face, and proposing solutions to better support them in implementing data protection regulations like GDPR and CCPA. The research contributes to the intersection of software engineering, privacy, and human-computer interaction, aiming to bridge the gap between legal requirements and developer practices.