W3C home > Mailing lists > Public > public-tracking@w3.org > September 2012

plain text of compliance spec as of 14 Sep 2012

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 19 Sep 2012 23:48:54 -0700
Message-Id: <FC3C056B-CF92-4943-AD6C-6353525CCC4F@gbiv.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:34 UTC