- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 19 Sep 2012 23:48:54 -0700
- To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Below is a plain text version of the generated source of the current
editors' draft for compliance, which may be useful to folks who find
it easier to respond in email than to make comments indirectly.
....Roy
----------------------------------------------------------------------
W3C
Tracking Compliance and Scope Specification
W3C Editor's Draft 14 September 2012
This version:
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
Latest published version:
http://www.w3.org/TR/tracking-compliance/
Latest editor's draft:
http://www.w3.org/2011/tracking-protection/drafts/tracking-compliance.html
Editors:
Justin Brookman, CDT
Sean Harvey, Google
Erica Newland, CDT
Heather West, Google
Copyright (c) 2011-2012 W3C(R) (MIT, ERCIM, Keio), All Rights Reserved.
W3C liability, trademark and document use rules apply.
----------------------------------------------------------------------
Abstract
This specification defines the meaning of a Do Not Track (DNT) preference
and sets out practices for websites to comply with this preference.
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 at http://www.w3.org/TR/.
This document is an editors' strawman reflecting a snapshot of live
discussions within the Tracking Protection Working Group. It does not yet
capture all of our work. For example, we have issues that are [PENDING
REVIEW] with complete text proposals that have not yet made it into this
draft. Text in blue boxes presents multiple options the group is
considering. An issue tracking system is available for recording raised,
open, pending review, closed, and postponed issues regarding this
document.
This document was published by the Tracking Protection Working Group as an
Editor's Draft. If you wish to make comments regarding this document,
please send them to public-tracking@w3.org (subscribe, archives). All
feedback is welcome.
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.
This document was produced by a group operating under the 5 February 2004
W3C Patent Policy. 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. An individual who has
actual knowledge of a patent which the individual believes contains
Essential Claim(s) must disclose the information in accordance with
section 6 of the W3C Patent Policy.
Table of Contents
* 1. Introduction
* 2. Scope and Goals
* 3. Definitions
* 3.1 User
* 3.2 User Agent
* 3.3 Party
* 3.3.1 Option 1
* 3.3.2 Option 2
* 3.4 Service Providers/Outsourcers
* 3.4.1 Option 1: Service Provider/Outsourcer Definition
* 3.4.1.1 Non-Normative
* 3.4.1.2 Technical Precautions
* 3.4.1.3 Non-Normative Discussion
* 3.4.1.3.1 Siloing in the Browser
* 3.4.1.3.1.1 Same-Origin Policy
* 3.4.1.3.1.2 Cookie Path Attribute
* 3.4.1.3.1.3 Storage Key
* 3.4.1.3.2 Siloing in the Backend
* 3.4.1.3.2.1 Encryption Keys
* 3.4.1.3.2.2 Access Controls
* 3.4.1.3.2.3 Access Monitoring
* 3.4.1.3.3 Retention in the Backend
* 3.4.1.4 Internal Practices
* 3.4.1.4.1 Non-Normative Discussion
* 3.4.1.4.1.1 Policy
* 3.4.1.4.1.2 Training
* 3.4.1.4.1.3 Supervision and Reporting
* 3.4.1.4.1.4 Auditing
* 3.4.1.5 Use Direction
* 3.4.1.6 First Party or Third Party Requirements
* 3.4.1.6.1 Representation
* 3.4.1.6.2 Contract
* 3.4.2 Option 2: Service Provider/Outsourcer Definition
* 3.4.3 Option 3: Service Provider/Outsourcer Definition
* 3.5 First and Third Parties
* 3.5.1 Option 1: First and Third Parties
* 3.5.1.1 Definitions
* 3.5.1.2 Discussion
* 3.5.1.2.1 Overview
* 3.5.1.2.2 Multiple First Parties
* 3.5.1.2.3 User Interaction with Third-Party
Content
* 3.5.2 Option 2: First and Third Parties
* 3.6 Unlinkable Data
* 3.6.1 Option 1: Unlinkable Data
* 3.6.2 Option 2: Unlinkable Data
* 3.7 Network Transaction
* 3.8 Transactional data
* 3.9 Data collection, retention, use, and sharing
* 3.9.1 Exception for unknowing collection, retention, and use
* 3.10 Tracking
* 3.10.1 Option 1: Non-first Party Identifiers
* 3.10.2 Option 2: Cross-site or Over Time
* 3.10.3 Option 3: Silence
* 3.11 Explicit and Informed Consent
* 3.11.1 Option 1: Prescriptive
* 3.11.2 Option 2: Silence
* 4. First Party Compliance
* 5. User Agent Compliance
* 6. Third Party Compliance
* 6.1 Permitted Operational Uses for Third Parties and Service
Providers
* 6.1.1 Enumerated Uses
* 6.1.1.1 Short Term Collection and Use
* 6.1.1.2 Contextual Content or Ad Delivery
* 6.1.1.2.1 Examples
* 6.1.1.3 Content or Ad Delivery Based on First Party
Data
* 6.1.1.3.1 Examples
* 6.1.1.4 Frequency Capping
* 6.1.1.4.1 Examples
* 6.1.1.5 Financial Logging and Auditing
* 6.1.1.5.1 Examples
* 6.1.1.6 Security and Fraud Prevention
* 6.1.1.6.1 Examples
* 6.1.1.7 Debugging
* 6.1.1.7.1 Discussion
* 6.1.1.7.2 Examples
* 6.1.1.8 Aggregate Reporting
* 6.1.1.8.1 Option 1: Aggregate Reporting
* 6.1.1.8.2 Option 2: Aggregate Reporting
* 6.1.1.8.3 Option 3: No Aggregate Reporting
* 6.1.1.9 Compliance With Local Laws and Public Purposes
* 6.1.2 Additional Requirements for Permitted Uses
* 6.1.2.1 No Secondary Uses
* 6.1.2.2 Data Minimization and Transparency
* 6.1.2.3 Reasonable Security
* 6.1.2.4 No Personalization
* 6.1.2.5 No Persistent Identifiers
* 6.2 Geolocation compliance by a third party
* 6.2.1 Discussion
* 6.2.2 Examples
* 6.3 User-Granted Exceptions
* 6.3.1 Interaction with existing user privacy controls
* 6.3.2 Logged In Transactions
* 6.4 Disregarding Non-Compliant User Agents
* 6.5 Degrading User Experience for DNT:1 users
* 6.6 Public Disclosure of Compliance
* 6.6.1 Third Party Auditing
* A. Acknowledgements
* B. References
* B.1 Normative references
* B.2 Informative references
Note
This draft is a work-in-progress toward a Third Public Working Draft.
Until the Third Public Working Draft is finalized, this document should
not be relied upon as an indicator of the status of consensus (or lack of
consensus) among the working group.
1. Introduction
Note
This introduction will be re-worked after details of substantive text is
closer to being finalized.
The World Wide Web (WWW, or Web) consists of millions of sites
interconnected through the use of hypertext. Hypertext provides a simple,
page-oriented view of a wide variety of information that can be traversed
by selecting links, manipulating controls, and supplying data via forms
and search dialogs. A Web page is usually composed of many different
information sources beyond the initial resource request, including
embedded references to stylesheets, inline images, javascript, and other
elements that might be automatically requested as part of the rendering or
behavioral processing defined for that page.
Each of the hypertext actions and each of the embedded resource references
might refer to any site on the Web, leading to a seamless interaction with
the user even though the pages might be composed of information requested
from many different and possibly independent Web sites. From the user's
perspective, they are simply visiting and interacting with a single brand
-- the first-party Web property -- and all of the technical details and
protocol mechanisms that are used to compose a page representing that
brand are hidden behind the scenes.
It has become common for Web site owners to collect data regarding the
usage of their sites for a variety of purposes, including what led the
user to visit their site (referrals), how effective the user experience is
within the site (web analytics), and the nature of who is using their site
(audience segmentation). In some cases, the data collected is used to
dynamically adapt the content (personalization) or the advertising
presented to the user (targeted advertising). Data collection can occur
both at the first-party site and via third-party providers through the
insertion of tracking elements on each page. A survey of these techniques
and their privacy implications can be found in [KnowPrivacy].
People have the right to know how data about them will be collected and
how it will be used. Empowered with that knowledge, individuals can decide
whether to allow their online activities to be tracked and data about them
to be collected. Many Internet companies use data gathered about people's
online activities to personalize content and target advertising based on
their perceived interests. While some people appreciate this
personalization of content and ads in certain contexts, others are
troubled by what they perceive as an invasion of their privacy. For them,
the benefit of personalization is not worth their concerns about allowing
entities with whom they have no direct relationship to amass detailed
profiles about their activities.
Therefore, users need a mechanism to express their own preference
regarding tracking that is both simple to configure and efficient when
implemented. In turn, Web sites that are unwilling or unable to offer
content without such targeted advertising or data collection need a
mechanism to indicate those requirements to the user and allow them (or
their user agent) to make an individual choice regarding user-granted
exceptions.
This specification defines the terminology of tracking preferences, the
scope of its applicability, and the requirements on compliant first-party
and third-party participants when an indication of tracking preference is
received. This specification defines the meaning of a Do Not Track
preference and sets out practices for websites and other online companies
to comply with this preference.
A companion document, [TRACKING-DNT], defines the HTTP request header
field DNT for expressing a tracking preference on the Web, a well-known
location (URI) for providing a machine-readable tracking status resource
that describes a service's DNT compliance, the HTTP response header field
Tk for resources to communicate their compliance or non-compliance with
the user's expressed preference, and JavaScript APIs for determining DNT
status and requesting a site-specific, user-granted exception.
2. Scope and Goals
Issue 6: What are the underlying concerns? Why are we doing this?
This section consists of proposed text that is meant to address ISSUE-6
and is in active discussion. Currently, it satisfies no one. Like the
introduction, we will revisit and finalize once the document is more
complete.
While there are a variety of business models to monetize content on the
web, many rely on advertising. Advertisements can be targeted to a
particular user's interests based on information gathered about one's
online activity. While the Internet industry believes many users
appreciate such targeted advertising, as well as other personalized
content, there is also an understanding that some people find the practice
intrusive. If this opinion becomes widespread, it could undermine the
trust necessary to conduct business on the Internet. This Compliance
specification and a companion [TRACKING-DNT] specification are intended to
give users a means to indicate their tracking preference and to spell out
the obligations of compliant websites that receive the Do Not Track
message. The goal is to provide the user with choice, while allowing
practices necessary for a smoothly functioning Internet. This should be a
win-win for business and consumers alike. The Internet brings millions of
users and web sites together in a vibrant and rich ecosystem. As the
sophistication of the Internet has grown, so too has its complexity which
leaves all but the most technically savvy unable to deeply understand how
web sites collect and use data about their online interactions. While on
the surface many web sites may appear to be served by a single entity, in
fact, many web sites are an assembly of multiple parties coming together
to power a user's online experience. As an additional privacy tool, this
specification provides both the technical and compliance guidelines to
enable the online ecosystem to further empower users with the ability to
communicate a tracking preferences to a web site and its partners.
The accompanying TRACKING-DNT recommendation explains how a user, through
a user agent, can clearly express a desire not to be tracked. This
Tracking Compliance and Scope recommendation sets the standard for the
obligations of a website that receives such a DNT message.
Taken together these two standards should have four substantial outcomes:
1. Empower users to manage their preference around the collection and
correlation of data about Internet activities that occur on different
sites and spell out the obligations of sites in honoring those
preferences when DNT is enabled.
2. Provide an exceedingly straightforward way for users to gain
transparency and control over data usage and the personalization of
content and advertising on the web.
3. Enable a vibrant Internet to continue to flourish economically by
supporting innovative business models while protecting users' privacy.
4. Establish compliance metrics for operators of online services
This solution is intended to be persistent, technology neutral, and
reversible by the user. It aims to preserve a vibrant online ecosystem,
privacy-preserving secondary data uses necessary to ecommerce, and
adequate security measures. We seek a solution that is persistent,
technology neutral, and [something that speaks with the ability to opt
back in], but that preserves a vibrant online ecosystem,
privacy-preserving secondary data uses, and adequate security measures.
3. Definitions
3.1 User
A user is an individual human. When user-agent software accesses online
resources, whether or not the user understands or has specific knowledge
of a particular request, that request is made "by" the user.
3.2 User Agent
This specification uses the term user agent to refer to any of the various
client programs capable of initiating HTTP requests, including but not
limited to browsers, spiders (web-based robots), command-line tools,
native applications, and mobile apps [HTTP11].
3.3 Party
3.3.1 Option 1
A party is any commercial, nonprofit, or governmental organization, a
subsidiary or unit of such an organization, or a person which acts as a
functional entity. A set of functional entities is considered affiliated
when they are related by both common majority ownership and common
control, and affiliation is made easily discoverable by a user.
3.3.2 Option 2
A party is any commercial, nonprofit, or governmental organization, a
subsidiary or unit of such an organization, or a person. For unique
corporate entities to qualify as a common party with respect to this
document, those entities MUST be commonly owned and commonly controlled
(Affiliates) and MUST provide "easy discoverability" of affiliate
organizations. An "Affiliate List" MUST be provided within one click from
each page or the entity owner clearly identified within one click from
each page.
A website with a clear labeled link to the Affiliate List within the
privacy policy would meet this requirement or the ownership brand clearly
labeled on the privacy policy itself and may choose to act as a single
party.
3.4 Service Providers/Outsourcers
Note
We seem to have general consensus in theory but not in language for the
definition of a service provider. However, the three options below
different significantly in how prescriptive and demanding the test to
qualify as a service provider should be.
3.4.1 Option 1: Service Provider/Outsourcer Definition
Note
This option contains both definitions and normative compliance
requirements.
This section applies to parties engaging in an outsourcing relationship,
wherein one party "stands in the shoes" of another party to perform a
specific task. Both parties have responsibilities, as detailed below.
A first party or a third party MAY outsource functionality to another
party, in which case the third party may act as the original first party
or third party under this standard, with the following additional
restrictions:
* Data collected by each outsourced company is separated for each party
they collect data for by both technical means and organizational
process, AND
* The outsourced company has no independent rights to the collected
information, AND
* A contractual relationship exists between the outsourced and the party
they collect data for that outlines and mandates these requirements.
An outsourced company acting on the behalf of another party is subject to
all of the same restrictions on that party (for First or Third party, as
appropriate.)
3.4.1.1 Non-Normative
This section is non-normative.
Outsourced companies that act purely as vendors for their customers (often
first parties in this context) are not the intended target for the
Tracking Preference Expression but it is important there are no unintended
activities that are extended to another party through this allowance. In
all cases, its expected an outsourced company acting on the part of a
customer follows all of the same restrictions placed on that customer.
For the data separation requirement, outsourced companies have technical
options to achieve appropriate separation but in each the critical element
is that data is never reconstituted for users that have indicated a
preference not to be tracked. One possible approach would be to leverage a
per partner hash against a common cookie identifier, ensuring the
resulting identifier is consistent for a specific customer, but is unable
to be linked with another customer's identifier.
Contractual requirements that enforce data rights and responsibilities for
separation are a critical element of establishing an outsourcer acting on
another party's behalf. Contracts may occur directly through parties (for
example, a Publisher in an Ad Network) or between intermediaries (for
example, an Ad Network acting through an Ad Exchange). In either case,
data separation and removal of independent rights are necessary elements
that must survive intermediary contractual constructs.
3.4.1.2 Technical Precautions
Throughout all data collection, retention, and use, outsourced parties
MUST use all feasible technical precautions to both mitigate the
identifiability of and prevent the identification 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.
3.4.1.3 Non-Normative Discussion
This section is non-normative.
3.4.1.3.1 Siloing in the Browser
This section is non-normative.
Outsourcing services should use browser access control features so that
stored data specific to one party is never accessed or collected when the
user visits another party.
3.4.1.3.1.1 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 1
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.
3.4.1.3.1.2 Cookie Path Attribute
The HTTP cookie path can be used to silo data to a first party.
Example 2
Example Analytics stores its cookies for Example News with
"Path=/examplenews", and it stores its cookies for Example Sports with
"Path=/examplesports".
3.4.1.3.1.3 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 3
Example Analytics stores data for Example News at
window.localStorage["examplenews"] and data for Example Sports at
window.localStorage["examplesports"].
3.4.1.3.2 Siloing in the Backend
3.4.1.3.2.1 Encryption Keys
An outsourcing service should encrypt each first party's data with a
different set of keys.
3.4.1.3.2.2 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.
3.4.1.3.2.3 Access Monitoring
An outsourcing service should deploy access monitoring mechanisms to
detect improper use of siloed data.
3.4.1.3.3 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.
3.4.1.4 Internal Practices
Throughout all data collection, retention, and use, outsourced parties
MUST use sufficient internal practices to prevent the identification of
data from different parties.
3.4.1.4.1 Non-Normative Discussion
This section is non-normative.
3.4.1.4.1.1 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.
3.4.1.4.1.2 Training
Personnel that interact with outsourced data should be familiarized with
internal policy on compliance with this standard.
3.4.1.4.1.3 Supervision and Reporting
An outsourcing service should establish a supervision and reporting
structure for detecting improper access.
3.4.1.4.1.4 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.
3.4.1.5 Use Direction
An outsourced service:
1. MUST use data retained on behalf of a party ONLY on behalf of that
party, and
2. MUST NOT use data retained on behalf of a party for their own business
purposes, or for any other reasons.
3.4.1.6 First Party or Third Party Requirements
3.4.1.6.1 Representation
A party's representation that it is in compliance with this standard
includes a representation that its outsourcing parties comply with this
standard.
3.4.1.6.2 Contract
A first party MUST enter into a contract with an outsourced party that
requires that outsourced party to comply with these requirements.
3.4.2 Option 2: Service Provider/Outsourcer Definition
Outsourced service providers are considered to be the same party as their
clients if the outsourced service providers only act as data processors on
behalf of that party, silo the data so that it cannot be accessed by other
parties, and have no control over the use or sharing of that data except
as directed by that party.
3.4.3 Option 3: Service Provider/Outsourcer Definition
Note
Service Providers acting on the behalf of a First Party and with no
independent rights to use the First Party's data outside of the context of
that First Party and Permitted Uses are also considered to be acting as
the First Party. .
3.5 First and Third Parties
3.5.1 Option 1: First and Third Parties
3.5.1.1 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.
3.5.1.2 Discussion
This section is non-normative.
3.5.1.2.1 Overview
This section is non-normative.
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.
In some cases, web requests are redirected through intermediary domains,
such as url shorteners or framing pages, before eventually delivering the
content that the user was attempting to access. The operators of these
intermediary domains are third parties, unless they are a common party to
the operator of either the referring page or the eventual landing page.
Examples
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.
6. A user visits Example Social and sees the language: "Check out this
Example News article on cooking: sho.rt/1234". The user clicks the
link which directs the user to a page operated by the company Example
Sho.rt which then redirects the user to a page operated by Example
News. Example Social and Example News and first parties, and Example
Sho.rt is a third party.
7. A user visits Example Social and sees a hyperlink reading: "Check out
this Example News article on cooking." A user clicks the link which
points to framing.com/news1234. This page loads nothing but a frame
which contains the cooking article from Example News, but all links
are rewritten to pass through framing.com which is operated by Example
Framing. Example Social and Example News are first parties and Example
Framing is a third party.
3.5.1.2.2 Multiple First Parties
Note
There has been some disagreement within the group over how many first
parties there should be in any one network interaction. These three
options lay out the range of possibilities; the first is text that has
been before the group for some time, the others are new.
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.
There can be only one first party in any network transaction absent
additional meaningful interaction with otherwise third party content on
the webpage. The first party is the registrant and operator of the domain
that the user intentionally communicated with.
If a user intends to communicate with a party that utilizes a different
party as a platform, then both parties are first parties in the network
transaction.
Example: ExampleSports franchise has a dedicated page on a ExampleSocial.
When a user visits this dedicated page, both ExampleSports and
ExampleSocial are first parties.
3.5.1.2.3 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
1. 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. 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.
2. 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. 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.
3.5.2 Option 2: First and Third Parties
First Party is the party that owns the Web site or has control over the
Web site the consumer visits. A First Party also includes the owner of a
widget, search box or similar service with which a consumer interacts.
If a user merely mouses over, closes, or mutes third-party content, that
is not sufficient interaction to constitute a First Party widget
interaction.
A Third Party is any party other than a First Party, Service Provider, or
the user. It is possible to have multiple first parties on a single page
but each party must provide clear branding and a link to their respective
privacy policy (co-branded experience).
Issue 26: Providing data to 3rd-party widgets -- does that imply consent?
3.6 Unlinkable Data
Note
There is debate about whether to use the terms unlinkable, unlinked, or
unidentified to describe this type of data.
3.6.1 Option 1: Unlinkable Data
A party render a dataset unlinkable when it
1. takes commercially reasonable steps have been taken to de-identify data
such that there is confidence that it contains information which could not
be linked to a specific user, user agent, or device in a production
environment
2. publicly commits to retain and use the data in unlinkable fashion, and
not to attempt to re-identify the data
3. contracually prohibits any third party that it transmits the unlinkable
data to from attempting to re-identify the data. Parties SHOULD provide
transparency to their delinking process (to the extent that it will not
provided confidential details into security practices) so external experts
and auditors can assess if the steps are reasonably given the particular
data set.
3.6.2 Option 2: Unlinkable Data
A dataset is unlinkable when there is a high probability that it contains
only information that could not be linked to a particular user, user
agents, or device by a skilled analyst. A party renders a dataset
unlinkable when either:
1. it publicly publishes information that is sufficiently detailed for a
skilled analyst to evaluate the implementation, or
2. ensure that the dataset is at least 1024-unlinkable.
3.7 Network Transaction
A "network interaction" is an HTTP request and response, or any other
sequence of logically related network traffic.
Non-normative explanatory text: Determination of a party's status is
limited to a single interaction because a party's status may be affected
by time, context, or any other factor that influences user expectations.
3.8 Transactional data
Transactional data is information about the user's interactions with
various websites, services, or widgets which could be used to create a
record of a user's system information, online communications, transactions
and other activities, including websites visited, pages and ads viewed,
purchases made, etc.
3.9 Data collection, retention, use, and sharing
Note
We have not had time to substantially edit the definitions of collection
and tracking. These continue to be actively debated issues, as the
resolution of the use of unique identifiers is likely to end up in these
definitions.
Issue 16: What does it mean to collect data? (caching, logging, storage,
retention, accumulation, profile etc.)
1. A party "collects" data if the data comes within its control.
2. A party "retains" data if data remains within a party's control beyond
the scope of the current interaction.
3. A party "uses" data if the party processes the data for any purpose
other than storage or merely forwarding it to another party.
4. A party "shares" data if the party enables another party to receive or
access that data.
The definitions of collection, retention, use, and sharing are drafted
expansively so as to comprehensively cover a party's user-information
practices. These definitions do not require a party's intent; a party may
inadvertently collect, retain, use, or share data. The definition of
collection includes information that a party did not cause to be
transmitted, such as protocol headers.
3.9.1 Exception for unknowing collection, retention, and use
A party may receive, retain, and use data as otherwise prohibited by this
standard, so long as is unaware of such information practices and has made
reasonable efforts to understand its information practices. If a party
learns that it possesses information in violation of this standard, it
must delete that information at the earliest practical opportunity.
3.10 Tracking
Note
We have not had time to substantially edit the definitions of collection
and tracking. These continue to be actively debated issues, as the
resolution of the use of unique identifiers is likely to end up in these
definitions.
Issue 117: Terms: tracking v. cross-site tracking
3.10.1 Option 1: Non-first Party Identifiers
Note
Concerns with this section include undefined term "user data" plus as
written, this may apply more broadly than the authors intended
Tracking is the collection or use of user data via either a unique
identifier or a correlated set of data points being used to approximate a
unique identifier, in a context other than "first party" as defined in
this document. This includes:
1. a party collecting data across multiple websites, even if it is a
first party in one or more (but not all) of the multiple contexts
2. a third party collecting data on a given website
3. a first party sharing user data collected from a DNT:1 user with third
parties "after the fact".
Examples of tracking use cases include:
1. personalized advertising
2. cross-site analytics or market research that has not been
de-identified
3. automatic preference sharing by social applications
3.10.2 Option 2: Cross-site or Over Time
Tracking is defined as following or identifying a user, user agent, or
device across multiple visits to a site (time) or across multiple sites
(space).
Mechanisms for performing tracking include but are not limited to:
1. assigning a unique identifier to the user, user agent, or device such
that it will be conveyed back to the server on future visits;
2. personalizing references or referral information such that they will
convey the user, user agent, or device identity to other sites;
3. correlating data provided in the request with identifying data
collected from past requests or obtained from a third party; or,
4. combining data provided in the request with de-identified data
collected or obtained from past requests in order to re-identify that
data or otherwise associate it with the user, user agent, or device.
A preference of "Do Not Track" means that the user does not want tracking
to be engaged for this request, including any mechanism for performing
tracking, any use of data retained from prior tracking, and any retention
or sharing of data from this request for the purpose of future tracking,
beyond what is necessary to enable:
1. the limited permitted uses defined in this specification;
2. the first-party (and third-parties acting as the first-party) to
provide the service intentionally requested by the user; and
3. other services for which the user has provided prior, specific, and
informed consent.
3.10.3 Option 3: Silence
One proposal is not to define "tracking," but rather to list what is, or
is not, required and allowed in order to comply with the recommendation.
3.11 Explicit and Informed Consent
Note
The spec currently envisions that users should consent to both the setting
of a DNT preference as well as any user-granted exceptions. We have not
reached agreement on how precisely we need to define this term.
Issue 69: Should the spec say anything about minimal notice? (ie. don't
bury in a privacy policy)
3.11.1 Option 1: Prescriptive
Explicit and informed choice must satisfy 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
technology.
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 MUST NOT have the user permission
selected by default.
3.11.2 Option 2: Silence
No definition, other than explicitly leaving the definition of consent to
local rules.
4. First Party Compliance
Note
This language is still in flux, and may not yet allow third parties to do
anything on a publisher site.
If a First Party receives a network transaction to which a DNT:1 header is
attached, First Parties may engage in their normal collection and use of
information. This includes the ability to customize the content, services,
and advertising in the context of the first party experience.
The First Party must not pass information about this transaction to
non-service provider third parties who could not collect the data
themselves under this Recommendation.
5. User Agent Compliance
A user agent MUST offer a control to express a tracking preference to
third parties. The control MUST communicate the user's preference in
accordance with the [TRACKING-DNT] recommendation and otherwise comply
with that recommendation. A user agent MUST NOT express a tracking
preference for a user unless the user has given express and informed
consent to indicate a tracking preference.
We do not specify how tracking preference choices are offered to the user
or how the preference is enabled: each implementation is responsible for
determining the user experience by which a tracking preference is enabled.
For example, a user might select a check-box in their user agent's
configuration, install an extension or add-on that is specifically
designed to add a tracking preference expression, or make a choice for
privacy that then implicitly includes a tracking preference (e.g.,
"Privacy settings: high"). Likewise, a user might install or configure a
proxy to add the expression to their own outgoing requests.
Shane's proposal has suggested the additional compliance requirements of
user agents:
1. The User Agent must also make available via a link in explanatory text
where DNT is enabled to provide more detailed information about DNT
functionality
2. Any User Agent claiming compliance must have a functional
implementation of the browser exceptions in this specification
6. Third Party Compliance
Note
We will be using this language as one of three or more options to evaluate
for third party compliance.
If the operator of a third-party domain receives a communication to which
a DNT:1 header is attached:
1. that operator must not collect, share, or use information related to
that communication outside of the permitted uses as defined within
this standard and any explicitly-granted exceptions, provided in
accordance with the requirements of this standard;
2. that operator must not use information about previous communications
in which the operator was a third party, outside of the explicitly
expressed permitted uses as defined within this standard;
3. that operator may delete information about previous communications in
which the operator was a third party, outside of the explicitly
expressed permitted uses as defined within this standard.
6.1 Permitted Operational Uses for Third Parties and Service Providers
Note
These are options that have been discussed in the group. While many have
broad consensus within the group, some are debated both based on scope of
the draft and whether they should be permitted uses. There is also
substantial disagrement over the SCOPE of information that may be
collected, used, and retained for these purposes, most notably whether
persistent unique identifiers may be collected, used, and retained for
these purposes.
If the operator of a third-party domain receives a communication to which
a DNT:1 header is attached, that operator MAY nevertheless collect, use,
and retain information related to that communication for these permitted
uses:
* Short term collection and use, where information is not transmitted to
a third party or used to profile or personalize a user's experience;
* Contextual content or ad delivery;
* Content or Ad Delivery Based on First Party Data
* Frequency Capping
* Financial Logging and Auditing
* Security and Fraud Prevention
* Aggregate Reporting
* Debugging
* Compliance With Local Laws and Public Purposes
As long as there is:
* No Secondary Use
* Data Minimization and Transparency
* Reasonable Security
* No Personalization
These permitted uses and requirements are further discussed below.
6.1.1 Enumerated Uses
6.1.1.1 Short Term Collection and Use
Note
We have discussed allowing a N-week (anywhere from 1 week to 3 months)
grace period where third parties could collect and use data, partly due to
concerns , partly as a compromise to the market research/aggregate
reporting issue. We do not have consensus on this permitted use at this
point. If we decide to allow this, we would need to add non-normative text
explaining the rationale and providing examples.
Information may be collected and used any purpose, so long as the
information is retained for no longer than N weeks and the information is
not transmitted to a third party and the information is not used to build
a profile about a user or otherwise alter any individual's user experience
(apart from changes that are made based on aggregate data or security
concerns).
6.1.1.2 Contextual Content or Ad Delivery
Note
Note that it is not clear that this is in scope, per Shane; others
disagree. Revisit whether contextual belongs in some place other than
permitted uses (potentially the definition of collection).
Regardless of DNT signal, information may be collected, retained and used
for the display of contextual content or advertisements, including content
or advertisements based on the first-party domain that the user visited.
6.1.1.2.1 Examples
This section is non-normative.
1. A user visits ExampleSports.com with DNT:1 enabled to read a news
article about a baseball game. ExampleSports uses the third party
ExampleAds to serve ads on ExampleSports.com. ExampleAds is not an
outsourcing partner of ExampleSports, and often uses third-party
behavioral data to serve targeted ads to users who have not enabled
DNT:1. ExampleAds may collect and use information about the user in
order to render an advertisement (including IP address and information
about the user agent) and information about the url of the news
article in order to render an advertisement related to the baseball
game.
2. A user visits ExampleLocalNews.com with DNT:1 enabled to read a news
article about a local fire. ExampleLocalNews uses the third party
ExampleWeather to display a weather widget on its site. ExampleWeather
is not an outsourcing partner of ExampleLocalNews. ExampleWeather may
collect and user information about the user in order to render the
weather widget (including IP address and information about the user
agent) and information about the domain of the news site in order to
render weather information related to the city which ExampleLocalNews
reports on.
6.1.1.3 Content or Ad Delivery Based on First Party Data
Note
Note that it is not clear that this is in scope, per Shane; others
disagree. Revisit whether contextual belongs in some place other than
permitted uses (potentially the definition of collection).
Regardless of DNT signal, information may be collected, retained and used
for the display of content or advertisements based in part of data that
the third party previously collected from the user when acting as a first
party.
6.1.1.3.1 Examples
This section is non-normative.
1. A user visits ExampleNews.com with DNT:1 enabled to read a story about
a national election. ExamplesNews uses the third party ExamplePortal
to serve content and advertisements on its site. ExamplePortal is not
an outsourcing partner of ExampleNews. The user had previously visited
ExamplePortal.com with DNT:1 enabled and read several stories about
golf. ExamplePortal may serve an advertisement related to golf to that
same user on ExampleNews. However, ExamplePortal may not use the fact
that user went to ExampleNews to add to the user's ExamplePortal
profile, and may only retain and use information about that fact for a
permitted operational use.
2. A user visits Example Music with DNT:1 enabled to listen to recently
released albums streamed online. Example Music uses the third party
Example Social to provide a widget that shows users what their Example
Social friends have done on ExampleMusic. ExampleSocial is not an
outsourcing partner of ExampleMusic. The user is a member of
ExampleSocial and has several friends who also share information about
what they do on ExampleMusic on ExampleSocial. ExampleSocial may
display information that the users' friends had shared on
ExampleSocial related to ExampleMusic within its third-party widget on
ExampleMusic. However, ExampleSocial may not use the fact that user
went to ExampleMusic to add to the user's ExampleSocial profile, and
may only retain and use information about that fact for a permitted
operational use.
6.1.1.4 Frequency Capping
Regardless of DNT signal, information may be collected, retained and used
for limiting the number of times that a user sees a particular
advertisement, often called "frequency capping".
In Seattle, we discussed specifically limiting how data was stored for
frequency capping:
Server-side frequency capping is allowed if the tracking identifier is
only retained in a form that is unique to each super-campaign (e.g.,
one-way hashed with a campaign id) and does not include retention of the
user's activity trail (page URIs on which the ads were delivered) aside
from what is allowed for other permitted uses.
6.1.1.4.1 Examples
This section is non-normative.
A user visits ExampleNews with DNT:1 enabled. ExamplesNews uses the third
party ExampleAds to serve content and advertisements on its site.
ExampleAds is not an outsourcing partner of ExampleNews. ExampleAds has
previously shown the user an ad for ExampleCars fives times in the past
week on other sites. ExampleCars' contract with Example Ads states that
Example Ads will be paid less for impressions where the user sees an ad
more than five times in a week. ExampleAds may opt not to show the user
the ad for ExampleCars because the user has already seen the ad five times
on other sites.
6.1.1.5 Financial Logging and Auditing
Note
for financial logging/ auditing, look to 3rd parties as 3rd parties
Regardless of DNT signal, information may be collected, retained and used
for financial fulfillment purposes such as billing and audit compliance.
This includes counting and verifying:
* ad impressions to unique visitors
* clicks by unique visitors
* subsequent action or conversion by unique visitors
* quality measures such as ad position on sites and the sites on which
the ads were served
Note
One potential compromise on the unique identifier issue for logging would
be grandfather in existing contracts that require unique, cookie-based
counting. New contracts would not be able to require that ad networks use
cookies (or other unique identifiers) to uniquely count users who have
DNT:1 enabled.
6.1.1.5.1 Examples
This section is non-normative.
Note
Add examples for display verification, click verification, CPA, quality
measures
6.1.1.6 Security and Fraud Prevention
Regardless of DNT signal, information may be collected, retained and used
for detecting security risks and fraudulent activity, defending from
attacks and fraud, and maintaining integrity of the service. This includes
data reasonably necessary for enabling authentication/verification,
detecting hostile transactions and attacks, providing fraud prevention,
and maintaining system integrity. In this example specifically, this
information may be used to alter the user's experience in order to
reasonably keep a service secure or prevent fraud.
6.1.1.6.1 Examples
This section is non-normative.
Note
Add examples with and without outsourced parties (J- not sure what this
means)
6.1.1.7 Debugging
Regardless of DNT signal, information may be collected, retained and used
for identifying and repairing errors that impair existing intended
functionality.
Note
In Seattle, we discussed a compromise"graduated response" approach that
allows third parties to retain data for a short period if no problems are
apparent, and to use/retain longer only if there is reason to believe
there is a problem.
6.1.1.7.1 Discussion
This section is non-normative.
Detailed information is often necessary to replicate a specific user's
experience to understand why their particular set of variables is
resulting in a failure of expected functionality or presentation. These
variables could include items such as cookie IDs, page URLs, device or UA
details, content specifics, and activity/event specifics to narrow in on
the cause of the discrepancy.
6.1.1.7.2 Examples
This section is non-normative.
A user visits ExampleBlog with DNT:1 enabled. Example News uses the third
party ExampleAds to serve content and advertisements on its site.
ExampleAds is not an outsourcing partner of ExampleBlog. ExampleAds
retains [to be determined data fields] in order to later replicate users'
experiences in receiving its ads to subsequently diagnose problems and
understand why their particular set of variables resulted in a failure of
expected functionality or presentation.
6.1.1.8 Aggregate Reporting
6.1.1.8.1 Option 1: Aggregate Reporting
Regardless of DNT signal, information may be collected, retained and used
for aggregate reporting, such as market research and product improvement.
Data MAY be collected and retained on an individual level, but the use of
the data must only be aggregate reporting, and the products of the
reporting MUST be unlinkable as defined in this document.
6.1.1.8.2 Option 2: Aggregate Reporting
Regardless of DNT signal, information may be collected, retained and used
for aggregate reporting, such as market research and product improvement,
if that information is collected and retained for another enumerated
permitted use. Data MAY be collected and retained on an individual level,
but the use of the data must only be aggregate reporting, and the products
of the reporting MUST be unlinkable as defined in this document. If the
operator no longer has another enumerated permitted use for which to use
and retain the data, the operator MAY NOT use and retain the data for
aggregate reporting unless the data has been rendered unlinkable as
defined in this document.
6.1.1.8.3 Option 3: No Aggregate Reporting
There is no permitted use for aggregate reporting outside of the grace
period described earlier.
6.1.1.9 Compliance With Local Laws and Public Purposes
Note
The group has generally agreed that companies can collect and process data
as required by local law despite the DNT:1 signal and still comply with
this standard. We have also conceptually agreed that companies cannot
exploit this language by creating contractual requirements between
companies to collect data as a "legally required" basis for the collection
and use of data despite a DNT:1 signal.
Regardless of DNT signal, information may be collected, retained and used
for complying with local laws and public purposes, such as copyright
protection and delivery of emergency services.
6.1.2 Additional Requirements for Permitted Uses
In order to use the Permitted Uses outlined, a party must comply with
these four requirements.
6.1.2.1 No Secondary Uses
Third Parties MUST NOT use data retained for permitted uses for
non-permitted uses.
6.1.2.2 Data Minimization and Transparency
A third party MUST ONLY retain information for a Permitted Use for as long
as is reasonably necessary for that use. Third parties MUST make
reasonable data minimization efforts to ensure that only the data
necessary for the permitted use is retained. A third party MUST provide
public transparency of their data retention period. The third party MAY
enumerate each individually if they vary across Permitted Uses. Once the
period of time for which you have declared data retention for a given use,
the data MUST NOT be used for that permitted use. After there are no
remaining Permitted Uses for given data, the data must be deleted or
rendered unlinkable.
Note
May be worthwhile to put some examples in around when it is or isn't a
good idea to explain use, ie, Commonly Accepted Practices vs. security
data to address unique businesses
6.1.2.3 Reasonable Security
Third parties MUST use reasonable technical and organizational safeguards
to prevent further processing of data retained for Permitted Uses. While
physical separation of data maintained for permitted uses is not required,
best practices should be in place to ensure technical controls ensure
access limitations and information security. Third parties SHOULD ensure
that the access and use of data retained for Permitted Uses is auditable.
Note
Whether or not an audit, or the type of audit, is mandated is still in
discussion; an optional field exists in the TPE spec for auditors and
self-regulatory commitments. The audit section of the TPE should be
cross-referenced here.
6.1.2.4 No Personalization
Outside of Security and Frequency Capping, data retained for Permitted
Uses MUST NOT be used to alter a specific user's online experience based
on multi-site activity.
6.1.2.5 No Persistent Identifiers
A third party may only collect, use, and retain for permitted uses
information that a user agent necessarily shares with a web server when it
communicates with the web server (e.g. IP address and User-Agent), and the
URL of the top-level page, communicated via a Referer header or other
means, unless the URL contains information that is not unlinkable (e.g. a
username or user ID).
A third party may not collect, use, or retain information that a web
server could cause to not be sent but still be able to communicate with
the user agent (e.g. a cookie or a Request-URI parameter generated by the
user agent), except the URL of the top-level page, or any data added by a
network intermediary that the operator of a web server has actual
knowledge of (e.g. a unique device identifier HTTP header).
Note
The EFF/Mozilla/Stanford proposal is heavily dependent upon a requirement
that permitted use data is not correlated to a unique cookie or other
persistent identifier. This issue remains one of the biggest areas of
dispute in the working group, as the industry proposal allows for the use
of cookies and other unique identifiers by third parties despite a DNT:1
instruction.
6.2 Geolocation compliance by a third party
Note
Unclear whether this section reflects group consensus.
Issue 39: Tracking of geographic data (however it's determined, or used)
If the operator of a third-party domain receives a communication to which
a DNT:1 header is attached:
1. Geo-location information that is more granular than postal code is too
granular. Geolocation data must not be used at any level more granular
than postal code. Note that while the number of people living in a
postal code varies from country to country, postal codes are extant
world-wide.
2. If specific consent has been granted for the use of more granular
location data, than that consent prevails.
6.2.1 Discussion
This section is non-normative.
It is acceptable to use data sent as part of this particular network
interaction when composing a response to a DNT:1 request, but it is not
acceptable to store that data any longer than needed to reply. For
instance, it would be appropriate to use an IP address to guess which
country a user is in, to avoid showing them an advertisement for products
or services unavailable where they live.
When using request-specific information to compose a reply, some levels of
detail may feel invasive to users, and may violate their expectations
about Do Not Track. These sorts of detailed assessments should be avoided.
6.2.2 Examples
This section is non-normative.
Reasonable behavior: A user visits you from an IP address which a general
geo-IP database suggests is in the NYC area, where it is 6pm on a Friday.
You choose to show an advertisement for theaters and restaurants in the
area.
Invasive behavior: A user visits you from an IP address which suggests
that they are in a particular ZIP+4, which has a distinctive demographic
profile. Their user-agent indicates that they are a Mac user, further
narrowing their expected profile. You serve them an ad for business within
a few blocks of them which specializes in items which their expected
profile indicates they may enjoy.
In this example, even though the decision about which ad to serve was
based exclusively on request specific information, but was still tailored
to a highly-specific user profile. In particular, the estimation of a
user's location to within a single ZIP+4 may make a user feel that they
are being followed closely, even if the decision was made on the fly, and
the information was only held ephemerally.
6.3 User-Granted Exceptions
Note
Figure out which parts of UGE belong in which document.
The operator of a website may engage in practices otherwise described by
this standard if the user has given explicit and informed consent. This
consent may be obtained through the browser API defined in the companion
[TRACKING-DNT] document, or an operator of a website may also obtain
"out-of-band" consent to disregard a "Do Not Track" preference using a
different technology. If an operator is relying on "out of band" consent
to disregard a "Do Not Track" instruction, the operator must indicate this
consent to the user agent as described in the companion [TRACKING-DNT]
document.
6.3.1 Interaction with existing user privacy controls
Multiple systems may be setting, sending, and receiving DNT and/or Opt-Out
signals at the same time, it'll be important to ensure industry and web
browser vendors are on the same page with respect to honoring user choices
in circumstances where "mixed signals" may be received.
As a general principle, more specific settings override less specific
settings.
1. No DNT Signal / No Opt-Out: Treat as DNT unset
2. DNT Signal / No Opt-Out: Treat as DNT:1
3. Opt-Out / No DNT Signal: Treat as DNT:1
4. Opt-Out / DNT User-Granted Exception: Treat as DNT:0 for that site;
DNT User-Granted Exception is honored
6.3.2 Logged In Transactions
Note
Add note that we may be able to handle this section entirely within the
consent definition, rather than calling it out; potentially thought an
example in the consent section. Concern about UI creep.
Issue 65: How does logged in and logged out state work
6.4 Disregarding Non-Compliant User Agents
Note
this section is the topic of active debate.
Third parties MUST NOT disregard DNT:1 headers whose syntax is correctly
formed even if the third party does not believe that the DNT:1 header was
set with the explicit and informed consent of the user.
If the operator of a third-party domain has a good faith belief that a
user agent is sending a DNT:1 without the explicit and informed consent of
the user, the operator MAY disregard the DNT:1 header and collect, use,
and retain information about the user as if no DNT signal had been sent.
If the operator disregards the DNT signal, the operator MUST signal to the
user agent that it is disregarding the header as described in the
companion [TRACKING-DNT] document.
No provision on Disregarding Non-Compliant User Agents.
6.5 Degrading User Experience for DNT:1 users
Note
We have consensus that it's fine to degrade the experience for DNT:1
transactions, but need to find the text.
Issue 93: Should 1st parties be able to degrade a user experience or
charge money for content based on DNT?
6.6 Public Disclosure of Compliance
Note
Final wording awaits how the response is designed in the TRACKING-DNT
recommendation, but we agree upon the general direction below.
In order to be in compliance with this specification, a third party must
make a public commitment that it complies with this standard. A "public
commitment" may consist of a statement in a privacy policy, a response
header, a machine-readable tracking status resource at a well-known
location, or any other reasonable means. This standard does not require a
specific form of public commitment.
6.6.1 Third Party Auditing
Issue 21: Enable external audit of DNT compliance
Tracking Status Qualifiers may include a value to indicate auditing.
A. Acknowledgements
This specification consists of input from many discussions within and
around the W3C Tracking Protection Working Group, along with written
contributions from Haakon Flage Bratsberg (Opera Software), Amy Colando
(Microsoft Corporation), Roy T. Fielding (Adobe), Tom Lowenthal (Mozilla),
Ted Leung (The Walt Disney Company), Jonathan Mayer (Stanford University),
Ninja Marnau (Invited Expert), Matthias Schunter (IBM), John M. Simpson
(Invited Expert), Kevin G. Smith (Adobe), Rob van Eijk (Invited Expert),
Rigo Wenning (W3C), and Shane Wiley (Yahoo!).
The DNT header field is based on the original Do Not Track submission by
Jonathan Mayer (Stanford), Arvind Narayanan (Stanford), and Sid Stamm
(Mozilla). The DOM API for NavigatorDoNotTrack is based on the Web
Tracking Protection submission by Andy Zeigler, Adrian Bateman, and Eliot
Graff (Microsoft). Many thanks to Robin Berjon for ReSpec.js.
B. References
B.1 Normative references
[HTTP11]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June
1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt
[TRACKING-DNT]
Roy T. Fielding; David Singer. Tracking Preference Expression
(DNT). 13 March 2012. W3C Working Draft. (Work in progress.) URL:
http://www.w3.org/TR/2012/WD-tracking-dnt-20120313/
B.2 Informative references
[KnowPrivacy]
Joshua Gomez; Travis Pinnick; Ashkan Soltani. KnowPrivacy. 1 June
2009. URL:
http://www.knowprivacy.org/report/KnowPrivacy_Final_Report.pdf
Received on Thursday, 20 September 2012 06:49:21 UTC