Abstract, version, and status information are not relevant in this partial draft, but are part of the template. Just ignore these for now.
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.
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.
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 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.
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.
A "network interaction" is an HTTP request and response, or any other set of logically related network traffic.
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.
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.
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.
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.
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.
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.