Enhancing Privacy, Neglecting Harms: An Analysis of Real-World Digital Privacy Incidents

1 Introduction

• PET deployments have increased, but people continue to experience harms such as exposure of sensitive location data and resulting harassment or resignation.Examples include app data used to identify a priest’s visits to gay bars and Wi-Fi location data used in student misconduct trials.Source: §1 · p. 1
• Privacy-by-design principles offer designers a basis for action, but no clear connection links particular strategies to the harms they might prevent.The paper notes that privacy technology development is often motivated by regulatory pressure and enabling functionality while maintaining trust, rather than harm prevention.Source: §1 · p. 1
• 257 real-world privacy incidents are analyzed with a model connecting privacy violations to resulting harms and enabling assessment of harm-preventing measures.The analysis examines relationships between threat actors and harms, complex information flows, and potential mitigation while preserving system functionality.Source: §1 · p. 2
• The authors argue that consent remains an established concern, while system functionality itself can imply harms that privacy-enhancing technologies may still permit.They also identify disincentives to interventions among entities capable of enacting change and call for regulatory changes to shift priorities.Source: §1 · p. 2

2 Related Work

• Prior threat models either omit resulting harms or constrain their analysis to one threat actor, limiting representation of multi-entity actions that combine to cause harm.The MAP framework captures harms but not relationships among multiple entities whose actions combine, which matter when evaluating interventions.Source: §2 · p. 2
• Contextual integrity identifies inappropriate information flows but provides little information about an incident’s downstream ramifications.The paper’s model captures flows leading to violations and subsequent harms.Source: §2 · p. 2
• Prior work also studies specific technologies or domains, whereas this model emphasizes the breadth of technologies and services that result in privacy harms.Other work has applied privacy theories to incidents or compiled technology-specific cases, including AI and robotics.Source: §2 · pp. 2–3
• The authors extend prior mitigation research by assessing technical and regulatory interventions for both users and system providers, alongside barriers to adoption.Prior adoption work has emphasized usability, social factors, trust, awareness, and the costs of privacy protections.Source: §2 · p. 3
• Unlike prior analyses of privacy news reporting, this study focuses on the reported incidents themselves.Earlier work examined sentiment and regional variation in privacy-media coverage.Source: §2 · p. 3

3 Methodology Overview

• Content analysis of news articles is used to iteratively derive a model of privacy-based attacks, followed by analysis of technological and regulatory mitigation.The approach is presented as a systematic way to describe and analyze incidents and assess how identified harms can be mitigated.Source: §3 · p. 3

Scope.

• A privacy violation is an action or inaction outside accepted practices that causes an entity to lose control over how, when, or how extensively its personal information is communicated.The definition combines control over personal information with information-flow concepts.Source: Scope · p. 3
• The analysis includes incidents where a harm is explicitly stated and clearly results from the privacy violation.Harm is treated as impairment or disruption, including negative impacts on individuals, groups, or society.Source: Scope · p. 3
• The study excludes security incidents and other cases where digital systems do not function as intended, including bugs, malware, and data breaches.The authors limit inclusion to non-breach events to keep the scope specific to the research questions.Source: Scope · p. 3
• The 257 incidents are modeled by identifying entities, their actions or inactions, and the information flows connecting them.The article analysis uses an inductive approach to develop a unified view that supports further analysis.Source: Article Analysis · pp. 3–4

Analysis of Interventions.

• For intervention analysis, the authors identify entities’ intended purposes and assess whether those purposes can be achieved while mitigating harm.The analysis considers the system, relevant entities’ purposes, and resulting harms.Source: Analysis of Interventions · p. 4

Sources.

• Articles were drawn from two news sources in each of the US, UK, and Australia and published during 2024.The six sources were The New York Times, WIRED, The Times, The Register, The Sydney Morning Herald, and ABC.Source: Sources · p. 4, Search Criteria · p. 4

Exclusion Criteria.

• Articles were excluded if they were not standard text-based news or concerned irrelevant topics such as security incidents, promotions, real estate, or tutorials.Ambiguous cases were resolved through group consensus.Source: Exclusion Criteria · p. 4, §4.1 · p. 4

Inclusion Criteria.

• Included articles had to describe a digital privacy incident outside accepted practices with a stated harm; the collection results are summarized by step in Table 2.Accepted-practice indicators included concerns about the practice, illegality or proposed restrictions, legal action, or non-consensual explicit imagery.Source: Inclusion Criteria · p. 4

Limitations.

• Data collection was limited to English-speaking regions to avoid machine translation, so results primarily concern WEIRD societies.The authors leave coverage of more diverse populations as future work.Source: Limitations · p. 5
• The study excludes some potentially harm-mitigable scenarios, including data breaches, dis/misinformation, and Internet shutdowns, and its public-reporting sample may favor newsworthy events.Only 21.2% of attacks involved notable people or people performing noticeable actions.Source: Limitations · p. 5

Model Development.

• The incident model was developed iteratively from Csomor’s model, revising roles and actions until it captured the data flows in the dataset.Contextual properties were also developed to describe conditions under which information flows occur.Source: Model Development · p. 5

Qualitative Analysis.

• The authors began with predetermined codes based on model roles, actions, and context, then expanded them inductively and grouped them into higher-level categories.Coding was manual, with team discussion, a second pass applying criteria consistently, and a final review for consensus.Source: Qualitative Analysis · p. 5

Applicability of Model and Codes.

• The model’s roles and actions stabilized after 20 articles and were then applied to the remaining 158; the authors expect the structure to transfer across sources, while codes may vary with new technologies or time periods.Inter-rater reliability measures are described as incompatible with the consensus-based coding approach.Source: Applicability of Model and Codes · pp. 5–6

5 Our Model of Privacy-Based Attacks

• Across 178 articles, the dataset contains 257 privacy incidents and 341 privacy-based attacks; incidents include at least one harm, while attacks trace the complete data flow.Source: §5 · p. 6

Role–Action Model.

• The model links data subjects, privacy violations, attackers, and harms through intermediate entities and actions that describe how data flows.Its core components are the data subject, privacy violation, attacker, and harm.Source: Role–Action Model · p. 6
• Roles identify the data subject, initial sharer and receiver, data handlers, violation initiator, and attacker, who is always last in the flow.Source: Role–Action Model · p. 6
• Data access, data sharing, and data transfer distinguish how entities obtain, provide, or jointly initiate a transfer of data.Source: Role–Action Model · p. 6
• In the driving-app example, the app sends unexpectedly collected data through a broker to an insurer, which raises premiums for aggressive driving.The app and broker initiate the violation; the insurer is the attacker because it uses the data to increase premiums.Source: Role–Action Model · p. 6

Contextual Information.

• Context records data, entity, and technology types, plus the data subject’s consent category for the first transfer.Consent categories include unknowing, uncontrolled, required for service, under pressure or coercion, and voluntary.Source: Contextual Information · p. 6
• The model also records attacker power, targeting, violation type, and harm type, including NCEI and mass surveillance.Power ranges from resources available to an average individual to those of a government or significant corporation.Source: Contextual Information · p. 7

NCEI, Psychological, and Physical Harms.

• Low-power attacks causing NCEI, psychological, and physical harms were difficult to prevent technologically or regulatorily, despite requiring little sophistication or resources.These harms also appeared in targeted scenarios, including synthetic NCEI, online harassment, stalking, intimate partner violence, and sextortion-related suicides.Source: NCEI, Psychological, and Physical Harms · p. 7

Economic Harms.

• Economic harms were associated with a range of targeting codes and medium-power attacks, including job loss, higher insurance costs, and fraud or extortion.In the sample, these attacks were generally more accessible than attacks causing NCEI, psychological, or physical harms.Source: Economic Harms · p. 7

Reputational and Autonomy Harms.

• Reputational and autonomy harms spanned targeted and untargeted scenarios, while targeted advertising and mass surveillance generally involved untargeted, medium- or high-power attacks.The authors note that targeted advertising was classified as an autonomy harm and may be overrepresented in that category.Source: Reputational and Autonomy Harms · pp. 7–8

Discrimination Harms.

• All nine discrimination attacks in the sample targeted a subgroup and were mostly high-power; the authors caution that their coding likely undercounts such cases.Discrimination was recorded only when articles mentioned it directly; the identified attacks included varied AI systems.Source: Discrimination Harms · p. 8

Complex Data Flows.

• Attacks involved up to six data transfers, one violation could produce up to five harms, and up to three violations could combine to produce one harm.Nearly all harms materialized regardless of whether or how much consent was provided; preexisting data access could leave no opportunity to consent.Source: Complex Data Flows · p. 8, §6.2 · p. 8

Additional Actors.

• The model captures actors beyond the entity that ultimately causes harm, including cases where an attacker indirectly targets someone or uses a service for collateral purposes.In the example, a gamer’s disclosure of a teenager’s IP address preceded harassment and repeated food deliveries to the teenager’s home.Source: Additional Actors · p. 8

6.3 Discussion of Incident Analysis

• The sample supports the argument that consent is insufficient: harms can follow later transfers, and preexisting relations can prevent consent altogether.As data moves among entities, protecting privacy interests becomes less clear; the model identifies meaningful roles without assigning responsibility, and an entity causing harm may not intend it.Source: §6.3 · p. 9

7 System Intervention Analysis

• The analysis distinguishes user-based technical and self-regulatory interventions from provider-based self-regulatory and privacy-engineering interventions.Users can change technologies or how they use them, while providers can redesign systems; provider self-regulation need not require design changes.Source: §7 · p. 9

System Analysis Protocol.

• For each incident, the researchers analyze one primary system interaction, usually the one involving the data subject or, when undefined, the privacy violation.For a preexisting relation, they instead focus on the interaction involving the initial sharer, or the privacy violation if that is undefined.Source: System Analysis Protocol · pp. 9–10

Enumerating Intended Purposes.

• The analysis checks whether interventions mitigate harm while preserving each relevant entity’s purposes, including whether an intervention restricts those purposes.Technical interventions are scoped broadly to include any relevant technology that mitigates harm, not only standard PETs; financial-gain purposes receive a separate secondary analysis.Source: Enumerating Intended Purposes · p. 10
• Some intervention feasibility judgments require domain-specific knowledge, and the researchers mark cases where it is insufficient as “Not Enough Information.”Cases where an entity’s purpose itself implies harm are excluded from the purpose-preservation analysis, with an exception when the data subject posted the original images on social media.Source: Enumerating Intended Purposes · pp. 10–11

Positionality and Reliability.

• Three experienced team members assessed interventions independently, requiring agreement from at least two and generally taking the union of insights with the more positive decisions.Source: Positionality and Reliability · p. 11

8.1 Purposes Implying Harm

• Systems whose purposes implied harm were excluded from further analysis, leaving 94 systems with analyzable purposes.The excluded set was almost exclusively systems where an entity's purpose implied the harm; the analysis also excluded many stalking, abuse, mass-surveillance, and related scenarios.Source: §8.1 · p. 11

8.2 Potential Interventions

• 59 of 94 systems had an intervention that could completely mitigate harm, and 85 had one that could apply or partially mitigate it.System-based interventions existed more often than user-based interventions; user-side self-regulatory and technical means applied in a minority of considered cases.Source: §8.2 · p. 11
• Among the 94 systems, four cases had no relevant intervention, including public-content redistribution leading to harassment or economic harm and employee monitoring leading to job loss.The other examples involved rental-payment databases contributing to housing denial and YouTube content used to train AI services, harming creators’ job prospects.Source: §8.2 · p. 11
• Potential mitigations include finer-grained access control, transparency and consent in some cases, identity detachment, and data minimization, but consent and anonymity are insufficient in general.Self-regulation can completely mitigate harms, while privacy engineering more often partially mitigates them; technical interventions alone are insufficient without addressing incentives and power dynamics.Source: §8.2 · pp. 11–12

Profit vs Harm Prevention.

• Including financial gain as a system purpose severely limits potential interventions; Figure 4 compares intervention types before and after that purpose is considered.Aggregation-based approaches can partially mitigate harms while often restricting provider profits, and may exacerbate discrimination against some groups.Source: Profit vs Harm Prevention · p. 12, Figure 4 · p. 12
• Interventions impose distinct restrictions: users may lose utility, usability, or freedom for adjacent tasks, while providers may face limits on surveillance, process efficiency, or research.For example, turning off WiFi or spoofing GPS can prevent tracking in some scenarios but restrict use of other applications or features; other interventions can constrain automated processes or research.Source: Profit vs Harm Prevention · pp. 12–13

Functionality-Enabled Harms.

• Some harms arise from functionality that is not a system’s primary intention, and addressing them requires considering interventions that restrict functionality, not only protect confidentiality or anonymity.The analysis excluded many systems whose purposes implied harm, making their enabled purposes a subject for deeper exploration.Source: Functionality-Enabled Harms · p. 13
• Misaligned provider incentives cannot be resolved solely through technical means; meaningful consequences for providers that fail to prevent harms may shift incentives toward data subjects.Even when incentives are aligned, harms can result from privacy not being prioritized or from a lack of awareness or concern.Source: Functionality-Enabled Harms · p. 13

9 Conclusion

• Complex data flows reveal why consent can be inadequate and why harms arise from interactions among entities and actions.The analysis identifies a gap between privacy technology research focused on enabling functionality and the prevention of harms inherent in that functionality.Source: §9 · p. 13
• The parties best positioned to deploy harm-preventing measures are often least incentivized to do so.Technological solutions alone cannot reconfigure misaligned incentives.Source: §9 · p. 13
• Systems whose functionalities imply harm reveal a fundamental barrier to harm prevention and a need to reconceptualize PETs.Source: §9 · p. 13
• Regulatory changes are necessary to introduce consequences for enabling harms.Source: §9 · p. 13

Ethical Considerations

• No private information was used in the study’s data.Source: Ethical Considerations · p. 14
• Data collection and analysis relied only on publicly available information.Source: Ethical Considerations · p. 14
• Researchers had regular check-ins, frequent breaks, and the option to opt out of reading an article.These measures addressed the sensitive and distressing nature of some article topics.Source: Ethical Considerations · p. 14

A.1 Data Collection

• The team searched six US, UK, and Australian news sources for articles published in 2024, using privacy and surveillance keywords alongside source-specific search tools.The team used NexisUni for additional Times and Sydney Morning Herald articles and Google Advanced Search for some Sydney Morning Herald results.Source: §A.1 · p. 21

A.1.1 Initial Criteria

• Initial criteria adapted and required a technology-facilitated privacy violation plus an attacker or harm; researchers refined the rules and resolved uncertainties through review and group discussion.The initial criteria defined a violation as loss of control over personal-information communication outside accepted practices.Source: §A.1.1 · pp. 21–22, §A.1.2 · p. 22

A.1.3 Final Criteria

• Final inclusion required an actual privacy incident outside accepted practices, related harm, and digital technology; explicit harm was generally required, with specified practice-based exceptions.Non-consensual explicit imagery, targeted advertising, and mass surveillance did not require additional concrete harm elaboration.Source: §A.1.3 · pp. 22–23

A.1.4 Cross-Validation

• Cross-validation used independent re-screening with source-dependent samples, followed by consensus discussions; a later recheck revisited at least all included articles for consistency.Samples included random subsets for some sources, all keyword results for ABC, and an estimated sample of title-approved WIRED articles.Source: §A.1.4 · p. 23, §A.1.5 · p. 23

A.2 Article Analysis

• The team iteratively revised the attack model and codes to capture observed data flows, sometimes combining relevant information from duplicate or linked same-source articles within the target date range.The final model and code set are described in §5 and Appendix C, respectively.Source: §A.2 · p. 23

A.2.1 First pass

• In the first coding pass, two groups of three revised codes as needed, resolved uncertain applications through review or group discussion, and removed articles found ineligible.The teams added, removed, and redefined codes when existing codes missed important incident aspects or recurring themes.Source: §A.2.1 · p. 23

A.2.2 Second pass

• A second pass had all six researchers revisit a subset for consistency and disagreement, followed by two researchers checking every incident for errors and consistent code use.These passes also led to code changes and the addition or removal of articles.Source: §A.2.2 · p. 24, §A.2.3 · p. 24

A.3 Model Differences from [28]

• The study retained Csomor’s role–action structure but distinguished initial receipt from violation causation and added a new system-intervention analysis.For example, a data handler—not the platform that first received images—could cause a later privacy-violating transfer.Source: §A.3 · p. 24, §A.3.1 · p. 24

A.3.1 Initial Receiver, Initiator of the Privacy Violation, and Privacy Violation

• The model allows violations on any transfer and separates the first data recipient from the entity causing the violation, which may be a sharer/receiver, handler, or attacker.Source: §A.3.1 · p. 24

A.3.2 Ambiguous Data Transfers

• Transfers could be labeled ambiguous when articles lacked enough information to distinguish access from sharing or both parties took action in the transfer.Source: §A.3.2 · p. 24

A.3.3 Broadened Access and Sharing

• Access means the receiver acts to obtain data and sharing means the giver acts to provide it; either may apply to any transfer except the initial sharer's typically sharing transfer.When no sharing was identifiable, the initial sharer was recorded as the initial receiver.Source: §A.3.3 · p. 24

A.3.4 Inclusion of More Entities

• Rather than grouping pass-through entities, the model includes every party identified in an article, preserving data-flow length and the parties involved.Source: §A.3.4 · p. 24

B Data Collection Counts

• Table 3 reports article exclusions and remaining counts by collection step and reason, but some source-specific counts and totals are unavailable.WIRED and ABC lack counts for articles failing format or title checks; some The Times per-criterion counts and totals are omitted.Source: Table 3 · p. 25

C Codebook

• The codebook distinguishes transfer, access, and sharing types, including whether data subjects know of or control access and whether sharing is pressured.Source: C Codebook · pp. 26–27
• The codebook distinguishes unaccepted collection, disclosure, and use, including disclosure to specific parties versus the public.Source: C Codebook · p. 27
• Incident coding covers targeting, data types, harms, motivation, and attacker power, with categories for psychological, economic, physical, reputational, and autonomy harms.Source: C Codebook · pp. 27–29

D Details on Application of Codes

• For online tracking, coders generally treated the data subject as involved in the first transfer, with exceptions for children or indications of unawareness.Unspecified social media was assumed to involve major platforms and coded as high power; data-broker transfers were assumed financial unless evidence indicated otherwise.Source: D Details on Application of Codes · p. 30
• Targeted advertising was coded as untargeted and generally as motivated by financial gain, unless evidence indicated otherwise.Source: D Details on Application of Codes · p. 30
• Coders identified the first event outside accepted practices as the privacy violation; for pressured sharing, the receiving entity was identified as its initiator.Source: D Details on Application of Codes · p. 30
• Coding guidelines distinguish platforms by their described use and type, and include image capture only when relevant to the case or article.Biometric coding follows the article’s description; communications and social media codes depend on whether use is one-to-one communication or broadcasting and meeting people.Source: D Details on Application of Codes · p. 30

E Visualization of All Data Flows

• Figure 5 provides a legend for the data-flow visualizations.Source: Figure 5 · p. 31

• Table 5 groups identified harms under high-level harm categories.Source: Table 5 · p. 36
• Table 6 counts attacks separately for each harm, so an attack causing multiple harms is counted once for each harm.Source: Table 6 · p. 36
• Figure 6 reports, for each harm, the share of attacks involving a particular Technology, Targeting, or Power code, using attacks causing that harm as the denominator.Source: Figure 6 · p. 36

G System Intervention Results

• Some interventions impose partial restrictions, including reduced user freedoms during a commute and reduced information collection when Wi-Fi is turned off.Source: G System Intervention Results · p. 37
• The examples include refined or hidden authentication mechanisms, opt-out mechanisms, accessories that impede facial recognition, and privacy-preserving contact tracing [108].Source: G System Intervention Results · p. 37
• For facial recognition in TSA presecurity checks and public-transport data collection, the listed intervention does not apply when financial gain is considered.Source: G System Intervention Results · p. 37
• Figure 7 shows, for each analyzed system, whether each intervention type applies; Figure 8 counts cases where each type applies; and Figure 9 gives the proportion of interventions with restrictions.Source: Figure 7 · p. 37, Figure 8 · p. 37, Figure 9 · p. 37

H Referenced Articles

• Table 8 contains details about articles cited as examples in the paper.Source: Table 8 · p. 38