Abstract, version, and status information are not relevant in this partial draft, but are part of the template. Just ignore these for now.

Drafting Notes

Parties, First Parties and Third Parties

Parties

Definition

A "party" is any commercial, nonprofit, or governmental organization, a subsidiary or unit of such an organization, or a person, that an ordinary user would perceive to be a discrete entity for purposes of information collection and sharing. Domain names, branding, and corporate ownership may contribute to, but are not necessarily determinative of, user perceptions of whether two parties are distinct.

Non-Normative Discussion

Our definition of what constitutes a "party" is guided by ordinary user expectations. We decline to adopt a conflicting approach that would draw a line at domain names, corporate affiliation, or branding, as discussed below.

Domain Names

In an uncomplicated world, a party might be delineated by domain boundaries. In practice, however, the domain approach can emphasize differences that would not matter to ordinary users and would be restrictive for many business uses. Suppose Example Company hosts dynamic content on example.com and static images on example-static.com. An average user would understand both domains are operated by Example Company, but a domain name distinction would say the two domains are different parties. Using domain names to differentiate parties would also impose an unnecessary choice on large websites of either hosting all their content on a single domain or having some of their content considered third party. By adopting a user expectations standard, we allow a single website to span multiple domains.

A domain name approach can also gloss over relevant differences from a user expectations perspective. Suppose Example Company hires an analytics company and aliases the domain analytics.example.com to the analytics company's website. By user expectations, and corporate affiliation and branding, the analytics company would be a separate party. Moreover, circumventing the limits imposed by this standard would require nothing more than switching domain names. The user expectations standard we adopt recognizes that multiple parties may exist at a single domain.

Corporate Affiliation

Corporate families can consist of businesses in completely unrelated industries; users may have limited understanding of how businesses are related by corporate ownership or control. Moreover, by creating affiliates for the purposes of data sharing, organizations could circumvent the limits imposed by this standard. Under the user expectations standards we adopt, a corporate affiliate is not, in general, the same party as an organization.

Branding

In many cases, branding aligns with ordinary user expectations. Unrelated websites rarely share branding. In company ownership scenarios, prominent language like "Brand A, provided by Company B" may be sufficient for the average user to understand that Brand A is owned by Company B and information shared with Brand A may also be shared with Company B.

But, in some cases, branding does not align with user expectations. Suppose Example Search owns a video sharing website, Example Video. Most users are aware that Example Video is a subsidiary of Example Search, and that the Example Video website differs from the Example Search website for historical reasons. The Example Video home page does not, however, include any branding reference to Example Search. Under a branding test, Example Search and Example Branding would be different parties. The user expectations test allows for factors, other than branding, that influence user understanding.

Branding may also fall short in informing user expectations. If most users have never heard of Company B, language like "Brand A, provided by Company B" may not be adequate for the average user to understand the relationship between Brand A and Company B. A user expectations test recognizes there may be instances where even conspicuous branding is inadequate to inform users.

Network Interaction

Definition

A "network interaction" is an HTTP request and response, or any other set of logically related network traffic.

Non-Normative Discussion

Determination of a party's status is limited to a single transaction because a party's status may be affected by time, context, or any other factor that influences user expectations.

First Parties and Third Parties

Definitions

A "first party" is any party, in a specific network interaction, that can infer with high probability that the user knowingly and intentionally communicated with it. Otherwise, a party is a third party.

A "third party" is any party, in a specific network interaction, that cannot infer with high probability that the user knowingly and intentionally communicated with it.

Non-Normative Discussion

Overview

We draw a distinction between those parties an ordinary user would or would not expect to share information with, "first parties" and "third parties" respectively. The delineation exists for three reasons.

First, when a user expects to share information with a party, she can often exercise control over the information flow. Take, for example, Example Social, a popular social network. The user may decide she does not like Example Social's privacy or security practices, so she does not visit examplesocial.com. But if Example Social provides a social sharing widget embedded in another website, the user may be unaware she is giving information to Example Social and unable to exercise control over the information flow.

Second, we recognize that market pressures are an important factor in encouraging good privacy and security practices. If users do not expect that they will share information with an organization, it is unlikely to experience market pressure from users to protect the security and privacy of their information. In practice, moreover, third parties may not experience sufficient market pressure from first parties since increasingly third parties do not have a direct business relationship with the first party websites they appear on. We therefore require a greater degree of user control over information sharing with such organizations.

Last, third parties are often in a position to collect a sizeable proportion of a user's browsing history – information that can be uniquely sensitive and easily associated with a user's identity. We wish to provide user control over such information flows.

We recognize that, unlike with a bright-line rule, there can be close calls in applying our standard for what constitutes a first party or a third party. But we believe that in practice, such close calls will be rare. The overwhelming majority of content on the web can be classified as first party or third party, with few cases of ambiguity in practice.

We require a confidence at a "high probability" before a party can consider itself a first party. Where there is reasonable ambiguity about whether a user has intentionally interacted with a party, it must consider itself a third party. Our rationale is that, in the rare close cases, a website is in the best position to understand its users' expectations. We therefore impose the burden of understanding user expectations on the website. We also wish, in close cases, to err on the side of conforming to user expectations and protecting user privacy. If the standard is insufficiently protective, ordinary users have limited recourse; if the standard imposes excessive limits, websites retain the safety valve of explicitly asking for user permission.

Common Examples and Use Cases

  1. A user accesses an Example News article. The page includes an advertisement slot, which loads content from many companies other than Example News. Those companies are third parties.
  2. A user accesses an Example News article. The page includes an analytics script that is hosted by Example Analytics, an analytics service. Example Analytics is a third party.
  3. A user accesses an Example News article. It includes a social sharing widget from Example Social, a popular social network. Example Social is a third party.
  4. A user visits Example Diary, which is hosted by the free blogging service Example Blog Hosting but located at examplediary.com. Example Blog Hosting is a third party.
  5. A user launches Example Application, an app on a mobile device. The app includes a library from Example Advertising Network that displays ads. Example Advertising Network is a third party.

Multiple First Parties

There will almost always be only one party that the average user would expect to communicate with: the provider of the website the user has visited. But, in rare cases, users may expect that a website is provided by more than one party. For example, suppose Example Sports, a well known sports league, collaborates with Example Streaming, a well known streaming video website, to provide content at www.examplesportsonexamplestreaming.com. The website is prominently advertised and branded as being provided by both Example Sports and Example Streaming. An ordinary user who visits the website may recognize that it is operated by both Example Sports and Example Streaming.

User Interaction with Third-Party Content

A party may start out as a third party but become a first party later on, after a user interacts with it. If content from a third party is embedded on a first party page, the third party may become an additional first party if it can infer with high probability that the average user knowingly and intentionally communicated with it. If a user merely moused over, closed, or muted third-party content, the party would not be able to draw such an inference.

Examples and Use Cases

Example: Example Weather offers an unbranded weather widget that is embedded into websites, including Example News. The widget contains small links to Example Weather's website and privacy policy. A user visits Example News and scrolls through the weekly forecast in the Example Weather widget.

Discussion: Example Weather is a third party. The user has interacted with Example Weather's widget, but an ordinary user would not expect that scrolling through the widget involves communicating with Example News.

Example: Example Social, a popular social network, hosts a social sharing button that other websites can embed. The button is colored and styled in the same fashion as Example Social's website, contains descriptive text that is specific to Example Social, includes Example Social's logo, and very frequently appears on Example Social's website. Example News embeds the Example Social button, and a user clicks it.

Discussion: Example Social is a first party once the user clicks its embedded social sharing button. The average user would understand that by clicking the button she is communicating with Example Social.

Information Practices

First Party

A first party MUST NOT share information with a third party that the third party is prohibited from collecting itself.

Best Practice: A first party may voluntarily take steps to protect user privacy when responding to a Do Not Track request.

Third Party

General Rule

A third party may not collect, retain, use, or share any information related to communication with a user or user agent. There are exceptions to this general rule as defined in the following sections.

Exceptions

Protocol Information

A third party may collect, retain, and use protocol information for the purpose of communicating with a user agent.

Drafting note: We look forward to discussing with the group how to effectively impose retention limits on protocol information.

Unlinkable Data

Definition

N-unlinkability is the special case of K-anonymity where all values are considered part of the pseudo-identifier.

A dataset is "unlinkable" when there is a high probability that it contains only information which, for a skilled analyst, is 1024-unlinkable with respect to particular users, user agents, or devices.

Collection

A third party may collect non-protocol information if it is, independent of protocol information, unlinkable data.

Example: Example Analytics sets a language preference cookie that takes on few values and is shared by many users.

Outsourcing

A first party MAY outsource website functionality to a third party, in which case the third party may act as the first party under this standard with the following additional restrictions.

Technical Precautions

Operative Text

Throughout all data collection, retention, and use, outsourced service providers MUST use all feasible technical precautions to both mitigate the linkability of and prevent the linking of data from different first parties.

Structural separation ("siloing") of data per first party, including both
  1. separate data structures and
  2. avoidance of shared unique identifiers
are necessary, but not necessarily sufficient, technical precautions.

Non-Normative Discussion

Siloing in the Browser

Outsourcing services should use browser access control features so that stored data specific to one first party is never accessed or collected when the user visits another first party.

Same-Origin Policy

The same-origin policy silos stored data by domain name. An outsourcing service can use a different domain name for each first party.

Example: Example Analytics provides an outsourced analytics service to Example News and Example Sports, two unrelated websites. Example Analytics stores its cookies for Example News at examplenews.exampleanalytics.com, and it stores its cookies for Example Sports at examplesports.exampleanalytics.com.

Cookie Path Attribute

The HTTP cookie path can be used to silo data to a first party.

Example: Example Analytics stores its cookies for Example News with "Path=/examplenews", and it stores its cookies for Example Sports with "Path=/examplesports".

Storage Key

For key/value storage APIs, such as Web Storage and Indexed Database, an outsourcing service can use a different key or key prefix for each first party.

Example: Example Analytics stores data for Example News at window.localStorage["examplenews"] and data for Example Sports at window.localStorage["examplesports"].

Siloing in the Backend

Encryption Keys

An outsourcing service should encrypt each first party's data with a different set of keys.

Access Controls

An outsourcing service should deploy access controls so that only authorized personnel are able to access siloed data, and only for authorized purposes.

Access Monitoring

An outsourcing service should deploy access monitoring mechanisms to detect improper use of siloed data.

Retention in the Backend

An outsourcing service should retain information only so long as necessary to provide necessary functionality to a first party. If a service creates periodic reports, for example, it should delete the data used for a report once it is generated. An outsourcing service should be particularly sensitive to retaining protocol logs, since they may allow correlating user activity across multiple first parties.

Internal Practices

Operative Text

Throughout all data collection, retention, and use, outsourced service providers MUST use sufficient internal practices to prevent the linking of data from different first parties.

Non-Normative Discussion

Policy

An outsourcing service should establish a clear internal policy that gives guidance on how to collect, retain, and use outsourced data in compliance with this standard.

Training

Personnel that interact with outsourced data should be familiarized with internal policy on compliance with this standard.

Supervision and Reporting

An outsourcing service should establish a supervision and reporting structure for detecting improper access.

Auditing

External auditors should periodically examine an outsourcing service to assess whether it is in compliance with this standard and has adopted best practices. Auditor reports should be made available to the public.

Use Direction

An outsourced service
  1. MUST use data stored on behalf of a first party ONLY on behalf of that first party, and
  2. MUST NOT use data stored on behalf of a first party for their own business purposes, or for any other reasons.

First-Party Requirements

Representation

A first party's representation that it is in compliance with this standard includes a representation that its outsourcing service providers comply with this standard.

Contract

A first party MUST enter into a contract with an outsourcing service provider that requires that outsourcing service provider to comply with these requirements.

User Permission

A website my engage in practices otherwise prohibited by this standard if a user grants permission. Permission may be attained through the browser API defined in the companion Tracking Preference Expression document. A website may also rely on "out-of-band" consent attained through a different technology. An "out-of-band" choice mechanism has the same effect under this standard as the browser exception API, provided that it satisfies the following bright-line requirements:
  1. Actual presentation: The choice mechanism MUST be actually presented to the user. It MUST NOT be on a linked page, such as a terms of service or privacy policy.
  2. Clear terms: The choice mechanism must use clear, non-confusing terminology.
  3. Independent choice: The choice mechanism MUST be presented independent of other choices. It MUST NOT be bundled with other user preferences.
  4. No default permission: The choice mechanism MUST NOT have the user permission preference selected by default.
An "out-of-band" choice mechanism must additionally satisfy the following high-level standard:

An ordinary user would know that the choice overrides his or her privacy protections under this standard.

Contextual Personalization

A third party may temporarily use a referrer URL for the purpose of contextually personalizing content.

Geolocation

A third party may temporarily use an IP address for the purpose of coarse geolocation.

Security

Operative Text

A third party may collect, retain, and use data about a particular user or user agent for the purpose of ensuring its security, provided that there are reasonable grounds to believe the user or user agent was attempting to breach the party's security at the time the data was collected.

Non-Normative Discussion

This exception grants third parties (e.g. advertising networks) some latitude to mitigate security risks. Websites that users store sensitive personal information on (e.g. financial services and webmail) are all first-party; they are able to collect, retain, and use information about all users for security purposes.

Fraud Prevention

Operative Text

A third party may collect, retain, and use data about a particular user or user agent for the purpose of preventing fraud, provided that there are reasonable grounds to believe the user or user agent was attempting to commit fraud at the time the data was collected.

Non-Normative Discussion

When a user meaningfully interacts with third-party content (e.g. clicking an ad), the third party can collect, retain, and use information for fraud prevention. Third parties can also use protocol logs for fraud prevention (subject to appropriate retention limits, which this draft does not address). This exception provides an additional capability to, in certain circumstances, track impressions for fraud prevention.