Target Privacy Threat Model

Editor’s Draft,

This version:
https://w3cping.github.io/privacy-threat-model
Feedback:
public-privacy@w3.org with subject line “[privacy-threat-model] … message topic …” (archives)
Issue Tracking:
GitHub
Inline In Spec
Editors:
(Google Inc.)
(Brave)
Not Ready For Implementation

This spec is not yet ready for implementation. It exists in this repository to record the ideas and promote discussion.

Before attempting to implement this spec, please contact the editors.


Abstract

A privacy threat model we should migrate the web toward.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index.

This document was published by the Privacy Interest Group as an Editor’s Draft. Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Feedback and comments on this specification are welcome, either as GitHub issues or on the public-privacy@w3.org mailing list. When sending e-mail, please put the text “privacy-threat-model” in the subject, preferably like this:“[privacy-threat-model] …summary of comment…

This document was produced by a group operating under the W3C Patent Policy. The W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent.

This document is governed by the 1 March 2019 W3C Process Document.

This document is at a very early stage. Many things in it are wrong and/or incomplete. Please take it as a rough shape for how we might document the target threat model, rather than as definite statements about what should be in the target threat model.

1. Introduction

As a threat model, this specification describes attacker capabilities and attacker goals, and says, for each possible set of capabilities an attacker might have, which goals we expect the attacker can achieve.

As a privacy threat model, the attacker goals compromise the privacy of users, rather than their security.

As a target threat model, it describes not the current state of the Web including all current maybe-unwise APIs, but rather an end state that we hope to migrate to, and that new APIs should be held to. This is meant to be a plausible threat model: it doesn’t expect to remove any APIs or browser behavior that is deemed essential to the viability of the Web.

Since people are likely to disagree about which APIs are essential to the Web, when saying that an attacker can achieve their goal, this document describes how the attacker achieves it using particular "essential" APIs, and it provides an index of those APIs so readers can point out ones that they don’t consider essential.

2. Terminology

[HTML] defines an origin as the tuple of a scheme, hostname, and port that provides the main security boundary on the web.

A site is a set of origins that are all same site with each other. Note that there are problems ([PSL-PROBLEMS]) with using registrable domains as a logical boundary.

A party is defined by [tracking-dnt] as "a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user."

The first party for a user action is the party that controls the origin of the top-level browsing context under which the action happened. Intuitively, this is the owner of the domain in the browser’s URL bar. This differs from Mozilla’s definition in that Mozilla defines other parties as first parties if the user can easily discover which party it is and intends to interact with that party, for example to allow sign-in widgets to be first-party.

A third party for a user action is any party that isn’t the first party or the user (the second party).

A user is a human or program that controls a user agent.

A user ID is a pair of a site and a (potentially-large) integer allocated by that site that is used to identify a user on that site. A single user will generally have many user IDs that refer to them, and a single site may or may not know that multiple user IDs refer to the same user.

A global identifier is a string that identifies a particular user independent of which site they’re visiting. Users generally have relatively few global identifiers and can usually list and recognize them. A goal of anti-tracking policy is to prevent user IDs from becoming global identifiers.

An attacker is any entity trying to get information that a user might not want them to get. Attackers are often entities that a user intends to interact with in other ways, as both first and third parties, and some users may not mind their collection of this information.

This document uses the terms publisher and tracker colloquially to refer to particular kinds of sites and the parties that operate them. They are not rigorously defined.

3. High-level threats

User agents should attempt to defend their users from a variety of high-level threats or attacker goals, described in this section. § 6 Attacker goals then describes the low-level steps an attacker would use to achieve these high-level goals.

[RFC6973] describes the following high-level privacy threats, which the TAG has adopted into Self-Review Questionnaire: Security and Privacy §threats:

Surveillance

Surveillance is the observation or monitoring of an individual’s communications or activities. See Privacy Considerations for Internet Protocols §section-5.1.1.

Stored Data Compromise

End systems that do not take adequate measures to secure stored data from unauthorized or inappropriate access. See Privacy Considerations for Internet Protocols §section-5.1.2.

Intrusion

Intrusion consists of invasive acts that disturb or interrupt one’s life or activities. See Privacy Considerations for Internet Protocols §section-5.1.3.

Misattribution

Misattribution occurs when data or communications related to one individual are attributed to another. See Privacy Considerations for Internet Protocols §section-5.1.4.

Correlation

Correlation is the combination of various pieces of information related to an individual or that obtain that characteristic when combined. See Privacy Considerations for Internet Protocols §section-5.2.1.

Identification

Identification is the linking of information to a particular individual to infer an individual’s identity or to allow the inference of an individual’s identity. See Privacy Considerations for Internet Protocols §section-5.2.2.

Secondary Use

Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected. See Privacy Considerations for Internet Protocols §section-5.2.3.

Disclosure

Disclosure is the revelation of information about an individual that affects the way others judge the individual. See Privacy Considerations for Internet Protocols §section-5.2.4.

Exclusion

Exclusion is the failure to allow individuals to know about the data that others have about them and to participate in its handling and use. See Privacy Considerations for Internet Protocols §section-5.2.5.

These threats combine into the particular concrete threats we want web specifications to defend against, described in subsections here:

3.1. Unwanted same-site recognition

Contributes to surveillance, correlation, and identification.

Users of most instantiations of the web platform expect that if they visit a site on one day, and then visit again the next day, the site will be able to recognize that they’re the same user. This allows sites to save the user’s preferences, shopping carts, etc. The web platform offers many mechanisms that are either intended to accomplish this recognition or that can be trivially used for it, including cookies, localStorage, indexedDB, CacheStorage, and other forms of storage.

A privacy harm only occurs if the user wants to break the association between two visits, but the site can still determine with high probability that the two visits came from the same user.

A user might expect that their two visits won’t be associated if they:

This recognition is generally accomplished by either "supercookies" or browser fingerprinting.

Supercookies occur when a browser stores data for a site but makes that data more difficult to clear than other cookies or storage. Fingerprinting Guidance §5.4 Clearing all local state discusses how specifications can help browsers avoid this mistake.

Fingerprinting consists of using attributes of the user’s browser and platform that are consistent between the two visits and probabilistically unique to the user.

The attributes can be exposed as information about the user’s device that is otherwise benign (as opposed to § 3.3 Sensitive information disclosure). For example:

See [fingerprinting-guidance] for how to mitigate this threat.

3.2. Unwanted cross-site recognition

Contributes to surveillance, correlation, and identification, usually more significantly than § 3.1 Unwanted same-site recognition.

This occurs if a site can determine with high probability that a visit to that site comes from the same user as another visit to a different site. This threat is discussed in § 4.1 Cross-site recognition.

3.3. Sensitive information disclosure

Contributes to correlation, identification, secondary use, and disclosure.

Many pieces of information about a user could cause privacy harms if disclosed. For example:

A particular piece of information may have different sensitivity for different users. Language preferences, for example, might typically seem innocent, but also can be an indicator of belonging to an ethnic minority. Precise location information can be extremely sensitive (because it’s identifying, because it allows for in-person intrusions, because it can reveal detailed information about a person’s life) but it might also be public and not sensitive at all, or it might be low-enough granularity that it is much less sensitive for many users.

When considering whether a class of information is likely to be sensitive to users, consider at least these factors:

This description of what makes information sensitive still needs to be refined. <https://github.com/w3cping/privacy-threat-model/issues/16>

3.4. Intrusive behavior

See intrusion.

Privacy harms don’t always come from a site learning things. For example it is intrusive for a site to

if the user doesn’t intend for it to do so.

3.5. Powerful capabilities

Contributes to misattribution.

For example, a site that sends SMS without the user’s intent could cause them to be blamed for things they didn’t intend.

4. Threat Model

For each of the high-level threats, we describe a threat model: a description of what goals attackers with various capabilities should or should not be able to achieve. For simple threats, a model can be expressed in prose, while complex threat models use a grid to express the web platform’s target guarantees.

indicates that the goal should be frustrated, while indicates that the attacker can achieve their goal.

Should we mark goals attackers can currently achieve, which we want to remove, differently from goals attackers already can’t achieve?

4.1. Cross-site recognition

§ 6.2.1 Transfer user ID from publisher 1 to publisher 2 on navigation. § 6.2.2 Transfer user ID from tracker to that tracker running within a publisher, on navigation. § 6.2.3 Transfer user ID from tracker within publisher 1 to that tracker within publisher 2, on navigation. § 6.2.5 Probabilistically transfer user ID from publisher 1 to publisher 2 without navigation. § 6.2.4 Probabilistically transfer user ID from publisher 1 to publisher 2 on navigation.
§ 5.1 Load iframes
§ 5.2 Run Javascript in a first-party context
§ 5.4 Read server logs on other publishers
Publisher 2 reads their own logs for the page load and publisher 1’s logs for the click tracking of the navigation click. User IDs that clicked on publisher 1 approximately the same time as that link’s target loaded on publisher 2 are probabilistically correlated.
§ 5.3 Modify server processing on the target publisher
The tracker adds a path segment, possibly encrypted, in their links to the publisher, encoding the user’s ID within the tracker. They convince the publisher to ignore that path segment in their server processing. The tracker running inside that publisher reads the URL, decodes the tracker site’s user ID, and sends that and the tracker-within-publisher user ID up to the tracker’s server.
§ 5.2 Run Javascript in a first-party context or § 5.3 Modify server processing on the source site and § 5.3 Modify server processing on the target publisher
The tracker adds a path segment, possibly encrypted, in their links to the publisher, encoding the user’s ID within the tracker. They convince the publisher to ignore that path segment in their server processing. The tracker running inside that publisher reads the URL, decodes the tracker site’s user ID, and sends that and the tracker-within-publisher user ID up to the tracker’s server.
The tracker adds a path segment, possibly encrypted, in the publisher 1’s links to publisher 2, encoding the user’s ID within publisher 1. They convince publisher 2 to ignore that path segment in their server processing. The tracker running inside that publisher reads the URL, decodes publisher 1’s user ID, and sends that and publisher 2’s user ID up to the tracker’s server.

Further cross-site recognition is available by combining capabilities with the ability to § 5.2 Run Javascript in a first-party context (or § 5.3 Modify server processing to add attacker-controlled javascript):

§ 6.2.5 Probabilistically transfer user ID from publisher 1 to publisher 2 without navigation.
§ 5.5 Convince the user to type an identifier
The tracker gets a report of the identifiers typed in both publisher sites, along with each publisher’s user id. If they’re equal, the user ids probably refer to the same user. The probability depends on the type of identifier: email addresses or credit card numbers are very high probability. Names or dates of birth are lower probability unless combined with other information like a zip code.
§ 5.6 Convince the user to open the same device in two cross-site tabs
The tracker reads the two devices, and if they give the same output at approximately the same time, the user is probably the same. For devices like cameras and microphones, detection is likely to be very accurate. Others, like ambient light, might only give a few bits per sample, and so need a long period of overlap in order to provide a good correlation.

For some devices, this transfer can be mitigated by turning off input when the site isn’t visible or isn’t focused, but user expectations limit where that mitigation is applicable.

§ 5.7 Convince the user to open the same read+write device in two different sites
The tracker writes identifying content to the device and then reads it back when the other site is opened. This is visible to varying degrees depending on the device: an individual native file or a Bluetooth or USB device that isn’t designed to cooperate with this sort of tracking, is likely to break in obvious ways when the tracker tries to write an identifier. A native directory, on the other hand, has many available filenames that could hold identifying information without a user being likely to notice.
§ 5.8 Have two sites open when a browser-wide event happens
§ 5.9 Have two sites visible when a browser-wide event happens
Browser-wide events generally need to be visible immediately when a user is looking at a website, so the tracker just needs to notice that the event’s parameters are the same, and its timestamp across two sites is close together. The probability of identifying a single user goes up as more events are observed.

4.2. Sensitive-information

Attackers should only be able to get access to sensitive information from a user agent if the user expresses their intent that the attacker get access to this information at the time the attacker gets access to it. User agents vary in how they gather this expression of intent.

That a user intends an attacker to get a piece of information at one time, for example their location or their contact book, may be, but is not necessarily evidence that the user intends to give out the same piece of information at a later time. There is not consensus about how long it’s reasonable to infer continued intent, but there is consensus that intent doesn’t last for years without interaction.

Add more information about local attackers and confused users and how browsers can mitigate. <https://github.com/w3cping/privacy-threat-model/issues/19>

This threat model defines a kind of information as restricted sensitive information if the web platform currently blocks access to it by default or if we plan to evolve the web platform to block access to it by default because of the potential privacy harms from disclosure of that kind of information.

Other information is described as "not restricted sensitive information" even if some users in some situations would find it sensitive. Information in this category may have a lower risk of privacy harm to users or may not currently be restricted because of incompatibility with functionality of the Web. These categories are not static and it may become feasible to block access by default to more kinds of information as the platform develops.

There is consensus that some kinds of information are restricted sensitive information:

There is consensus that some other kinds of information are not restricted sensitive information:

There is not consensus about the sensitivity of all kinds of information:

5. Attacker Capabilities

These are things some attackers can do. The attackers can use them to achieve their goals. All attackers are assumed to be able to buy domains and host sites on their domains.

5.1. Load iframes

The attacker can convince a publisher to load an iframe from the attacker’s site.

5.2. Run Javascript in a first-party context

When a publisher wants to show ads from an ad network, many/most ad networks require that publisher to use a <script src="adnetwork.js"> tag instead of an <iframe src="adnetwork.html">, which allows the ad network to see any publisher data that’s exposed to Javascript. This includes query parameters (e.g. fbclid) and any cookies that aren’t HttpOnly.

5.3. Modify server processing

Some attackers can convince some publishers (perhaps by paying them) to modify their server software. This could be used, for example, to receive user IDs passed in a path segment instead of a query parameter, without breaking the normal logic mapping a path to content.

5.4. Read server logs

Servers can keep logs of requests. The attacker may be able to convince some server operators to give them these logs or let them run queries over the logs.

5.5. Convince the user to type an identifier

The attacker can convince a user to type their email address, name, zip code, etc. into two publishers' sites.

5.6. Convince the user to open the same device in two cross-site tabs

The attacker can convince a user to open the same device on two publishers' sites that are both open at the same time in different tabs or windows.

5.7. Convince the user to open the same read+write device in two different sites

A read+write device is something like a native filesystem file or directory, or a bluetooth or USB device that can be configured to save data. The two sites need to be given access to the same device, but they don’t need to both be open at the same time.

5.8. Have two sites open when a browser-wide event happens

A browser-wide event is something that happens to the browser as a whole instead of to an individual site or web page. For example, the user going idle, sensor data changing, or the device’s time zone changing, would affect all tabs at the same time.

5.9. Have two sites visible when a browser-wide event happens

Unlike § 5.8 Have two sites open when a browser-wide event happens, this capability requires both sites to be visible (probably in two separate browser windows) at the same time during the event.

6. Attacker goals

These are things attackers want to accomplish.

6.1. User metrics within a single site

6.1.1. Click tracking

A site wants to know which of its links a user clicks on.

6.2. Tracking

[tracking-dnt] defines "tracking" as the collection of data regarding a particular user’s activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties. The following are building blocks that allow a tracker to build such a log of a user’s activity.

6.2.1. Transfer user ID from publisher 1 to publisher 2 on navigation.

When the user clicks a link from publisher 1 that navigates to publisher 2, publisher 2’s server learns that a user ID on publisher 2 and a user ID on publisher 1 represent the same user.

6.2.2. Transfer user ID from tracker to that tracker running within a publisher, on navigation.

When the user clicks a link from tracker.example to publisher.example, that tracker’s server learns that a user ID for either publisher.example or the tracker running within publisher.example and a user ID for tracker.example represent the same user.

6.2.3. Transfer user ID from tracker within publisher 1 to that tracker within publisher 2, on navigation.

When the user clicks a link from publisher1.example (where a tracker was embedded within that site) to publisher2.example (which has the same tracker embedded), that tracker’s server learns that a user ID for either publisher1.example or the tracker running within publisher1.example and a user ID for either publisher2.example or the tracker running within publisher2.example represent the same user.

6.2.4. Probabilistically transfer user ID from publisher 1 to publisher 2 on navigation.

When the user clicks a link from publisher 1 that navigates to publisher 2, publisher 2’s server learns that a user ID on publisher 2 and a user ID on publisher 1 are more likely than chance to represent the same user.

6.2.5. Probabilistically transfer user ID from publisher 1 to publisher 2 without navigation.

While the user is visiting publisher 1, that publisher can tell publisher 2 that a user ID on publisher 2 and a user ID on publisher 1 are more likely than chance to represent the same user, without requiring the user to navigate from publisher 1 to publisher 2.

7. Essential Web APIs

These are Web APIs and features that would destroy the Web as we know it if they went away. The placement of some features here will be contentious, and those features are marked as I discover the contention.

7.1. Javascript can make requests to servers

This could perhaps be broken down into same-origin requests and cross-origin requests, with cross-origin requests being more contentious.

7.2. Servers can define the paths under which they host content

These paths can include opaque strings that neither a human nor a user agent can interpret without knowing how the server works, like /t/proposal-packaging-for-the-web-signed-and-indexed/1827/10 and /Moby-Dick-Herman-Melville/dp/1503280780/.

8. Acknowledgements

Safari did the first work to prove that a more privacy-preserving web was possible, by blocking third-party cookies by default and then shipping ITP 1.0, without breaking the world. They eventually published their policy for Tracking Prevention, which heavily influenced this document.

Mozilla wrote the first concrete anti-tracking policy, which inspired Safari’s policy.

Michael Kleber on the Chrome team proposed a Privacy Model for the Web, which suggests blocking the transfer of user IDs between top-level sites and suggests a few ways that information could flow between sites without compromising user privacy.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[FINGERPRINTING-GUIDANCE]
Nick Doty. Mitigating Browser Fingerprinting in Web Specifications. 28 March 2019. NOTE. URL: https://www.w3.org/TR/fingerprinting-guidance/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[IndexedDB-2]
Ali Alabbas; Joshua Bell. Indexed Database API 2.0. 30 January 2018. REC. URL: https://www.w3.org/TR/IndexedDB-2/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[MEDIAQUERIES-5]
Dean Jackson; Florian Rivoal; Tab Atkins Jr.. Media Queries Level 5. 3 June 2020. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[PSL]
Public Suffix List. Mozilla Foundation.
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC6265]
A. Barth. HTTP State Management Mechanism. April 2011. Proposed Standard. URL: https://httpwg.org/specs/rfc6265.html
[SERVICE-WORKERS-1]
Alex Russell; et al. Service Workers 1. 19 November 2019. CR. URL: https://www.w3.org/TR/service-workers-1/

Informative References

[PSL-PROBLEMS]
Ryan Sleevi. Public Suffix List Problems. URL: https://github.com/sleevi/psl-problems
[RFC6973]
A. Cooper; et al. Privacy Considerations for Internet Protocols. July 2013. Informational. URL: https://tools.ietf.org/html/rfc6973
[TRACKING-DNT]
Roy Fielding; David Singer. Tracking Preference Expression (DNT). 17 January 2019. NOTE. URL: https://www.w3.org/TR/tracking-dnt/
[WHAT-DOES-PRIVATE-BROWSING-DO]
Martin Shelton. What Does Private Browsing Mode Do?. URL: https://medium.com/@mshelton/what-does-private-browsing-mode-do-adfe5a70a8b1

Issues Index

This description of what makes information sensitive still needs to be refined. <https://github.com/w3cping/privacy-threat-model/issues/16>
Should we mark goals attackers can currently achieve, which we want to remove, differently from goals attackers already can’t achieve?
Add more information about local attackers and confused users and how browsers can mitigate. <https://github.com/w3cping/privacy-threat-model/issues/19>