index.html 55.3 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html dir="ltr" lang="en"><head>
    <title>Tracking Preference Expression (DNT)</title>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">


  <style type="text/css">
/*****************************************************************
 * ReSpec CSS
 * Robin Berjon (robin at berjon dot com)
 * v0.05 - 2009-07-31
 *****************************************************************/


/* --- INLINES --- */
em.rfc2119 {
    text-transform:     lowercase;
    font-variant:       small-caps;
    font-style:         normal;
    color:              #900;
}

h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
    border: none;
}

dfn {
    font-weight:    bold;
}

a.internalDFN {
    color:  inherit;
    border-bottom:  1px solid #99c;
    text-decoration:    none;
}

a.externalDFN {
    color:  inherit;
    border-bottom:  1px dotted #ccc;
    text-decoration:    none;
}

a.bibref {
    text-decoration:    none;
}

code {
    color:  #ff4500;
}


/* --- WEB IDL --- */
pre.idl {
    border-top: 1px solid #90b8de;
    border-bottom: 1px solid #90b8de;
    padding:    1em;
    line-height:    120%;
}

pre.idl::before {
    content:    "WebIDL";
    display:    block;
    width:      150px;
    background: #90b8de;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

.idlType {
    color:  #ff4500;
    font-weight:    bold;
    text-decoration:    none;
}

/*.idlModule*/
/*.idlModuleID*/
/*.idlInterface*/
.idlInterfaceID, .idlDictionaryID {
    font-weight:    bold;
    color:  #005a9c;
}

.idlSuperclass {
    font-style: italic;
    color:  #005a9c;
}

/*.idlAttribute*/
.idlAttrType, .idlFieldType, .idlMemberType {
    color:  #005a9c;
}
.idlAttrName, .idlFieldName, .idlMemberName {
    color:  #ff4500;
}
.idlAttrName a, .idlFieldName a, .idlMemberName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlMethod*/
.idlMethType {
    color:  #005a9c;
}
.idlMethName {
    color:  #ff4500;
}
.idlMethName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlParam*/
.idlParamType {
    color:  #005a9c;
}
.idlParamName {
    font-style: italic;
}

.extAttr {
    color:  #666;
}

/*.idlConst*/
.idlConstType {
    color:  #005a9c;
}
.idlConstName {
    color:  #ff4500;
}
.idlConstName a {
    color:  #ff4500;
    border-bottom:  1px dotted #ff4500;
    text-decoration: none;
}

/*.idlException*/
.idlExceptionID {
    font-weight:    bold;
    color:  #c00;
}

.idlTypedefID, .idlTypedefType {
    color:  #005a9c;
}

.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
    color:  #c00;
    font-weight:    normal;
}

.excName a {
    font-family:    monospace;
}

.idlRaises a.idlType, .excName a.idlType {
    border-bottom:  1px dotted #c00;
}

.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
    width:  45px;
    text-align: center;
}
.excGetSetTrue, .prmNullTrue, .prmOptTrue { color:  #0c0; }
.excGetSetFalse, .prmNullFalse, .prmOptFalse { color:  #c00; }

.idlImplements a {
    font-weight:    bold;
}

dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
    margin-left:    2em;
}

.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
    font-weight:    normal;
}

.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
    font-weight:    bold;
    color:  #000;
    font-family:    monospace;
}

.attributes dt code, .fields dt code, .dictionary-members dt code {
    background:  #ffffd2;
}

.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
    color:  #005a9c;
    background:  transparent;
    font-family:    inherit;
    font-weight:    normal;
    font-style: italic;
}

.methods dt code {
    background:  #d9e6f8;
}

.constants dt code {
    background:  #ddffd2;
}

.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
    margin-bottom:  1em;
}

table.parameters, table.exceptions {
    border-spacing: 0;
    border-collapse:    collapse;
    margin: 0.5em 0;
    width:  100%;
}
table.parameters { border-bottom:  1px solid #90b8de; }
table.exceptions { border-bottom:  1px solid #deb890; }

.parameters th, .exceptions th {
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
    font-family:    initial;
    font-weight:    normal;
    text-shadow:    #666 1px 1px 0;
}
.parameters th { background: #90b8de; }
.exceptions th { background: #deb890; }

.parameters td, .exceptions td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
    vertical-align: top;
}

.parameters tr:first-child td, .exceptions tr:first-child td {
    border-top: none;
}

.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
    width:  100px;
}

.parameters td.prmType {
    width:  120px;
}

table.exceptions table {
    border-spacing: 0;
    border-collapse:    collapse;
    width:  100%;
}

/* --- TOC --- */
.toc a {
    text-decoration:    none;
}

a .secno {
    color:  #000;
}

/* --- TABLE --- */
table.simple {
    border-spacing: 0;
    border-collapse:    collapse;
    border-bottom:  3px solid #005a9c;
}

.simple th {
    background: #005a9c;
    color:  #fff;
    padding:    3px 5px;
    text-align: left;
}

.simple th[scope="row"] {
    background: inherit;
    color:  inherit;
    border-top: 1px solid #ddd;
}

.simple td {
    padding:    3px 10px;
    border-top: 1px solid #ddd;
}

.simple tr:nth-child(even) {
    background: #f0f6ff;
}

/* --- DL --- */
.section dd > p:first-child {
    margin-top: 0;
}

.section dd > p:last-child {
    margin-bottom: 0;
}

.section dd {
    margin-bottom:  1em;
}

.section dl.attrs dd, .section dl.eldef dd {
    margin-bottom:  0;
}

/* --- EXAMPLES --- */
pre.example {
    border-top: 1px solid #ff4500;
    border-bottom: 1px solid #ff4500;
    padding:    1em;
    margin-top: 1em;
}

pre.example::before {
    content:    "Example";
    display:    block;
    width:      150px;
    background: #ff4500;
    color:  #fff;
    font-family:    initial;
    padding:    3px;
    font-weight:    bold;
    margin: -1em 0 1em -1em;
}

/* --- EDITORIAL NOTES --- */
.issue {
    padding:    1em;
    margin: 1em 0em 0em;
    border: 1px solid #f00;
    background: #ffc;
}

.issue::before {
    content:    "Issue";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #f00;
    background: #fff;
    padding:    3px 1em;
}

.note {
    margin: 1em 0em 0em;
    padding:    1em;
    border: 2px solid #cff6d9;
    background: #e2fff0;
}

.note::before {
    content:    "Note";
    display:    block;
    width:  150px;
    margin: -1.5em 0 0.5em 0;
    font-weight:    bold;
    border: 1px solid #cff6d9;
    background: #fff;
    padding:    3px 1em;
}

/* --- Best Practices --- */
div.practice {
    border: solid #bebebe 1px;
    margin: 2em 1em 1em 2em;
}

span.practicelab {
    margin: 1.5em 0.5em 1em 1em;
    font-weight: bold;
    font-style: italic;
}

span.practicelab   { background: #dfffff; }

span.practicelab {
    position: relative;
    padding: 0 0.5em;
    top: -1.5em;
}

p.practicedesc {
    margin: 1.5em 0.5em 1em 1em;
}

@media screen {
    p.practicedesc {
        position: relative;
        top: -2em;
        padding: 0;
        margin: 1.5em 0.5em -1em 1em;
    }
}

/* --- SYNTAX HIGHLIGHTING --- */
pre.sh_sourceCode {
  background-color: white;
  color: black;
  font-style: normal;
  font-weight: normal;
}

pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; }           /* language keywords */
pre.sh_sourceCode .sh_type { color: #666; }                            /* basic types */
pre.sh_sourceCode .sh_usertype { color: teal; }                             /* user defined types */
pre.sh_sourceCode .sh_string { color: red; font-family: monospace; }        /* strings and chars */
pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; }     /* regular expressions */
pre.sh_sourceCode .sh_specialchar { color: 	#ffc0cb; font-family: monospace; }  /* e.g., \n, \t, \\ */
pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; }         /* comments */
pre.sh_sourceCode .sh_number { color: purple; }                             /* literal numbers */
pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; }       /* e.g., #include, import */
pre.sh_sourceCode .sh_symbol { color: blue; }                            /* e.g., *, + */
pre.sh_sourceCode .sh_function { color: black; font-weight: bold; }         /* function calls and declarations */
pre.sh_sourceCode .sh_cbracket { color: red; }                              /* block brackets (e.g., {, }) */
pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; }   /* TODO and FIXME */

/* Predefined variables and functions (for instance glsl) */
pre.sh_sourceCode .sh_predef_var { color: #00008B; }
pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }

/* for OOP */
pre.sh_sourceCode .sh_classname { color: teal; }

/* line numbers (not yet implemented) */
pre.sh_sourceCode .sh_linenum { display: none; }

/* Internet related */
pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }

/* for ChangeLog and Log files */
pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }

/* for Prolog, Perl... */
pre.sh_sourceCode .sh_variable { color: #006400; }

/* for LaTeX */
pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
pre.sh_sourceCode .sh_argument { color: #006400; }
pre.sh_sourceCode .sh_optionalargument { color: purple; }
pre.sh_sourceCode .sh_math { color: orange; }
pre.sh_sourceCode .sh_bibtex { color: blue; }

/* for diffs */
pre.sh_sourceCode .sh_oldfile { color: orange; }
pre.sh_sourceCode .sh_newfile { color: #006400; }
pre.sh_sourceCode .sh_difflines { color: blue; }

/* for css */
pre.sh_sourceCode .sh_selector { color: purple; }
pre.sh_sourceCode .sh_property { color: blue; }
pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }

/* other */
pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
pre.sh_sourceCode .sh_paren { color: red; }
pre.sh_sourceCode .sh_attribute { color: #006400; }

</style><link charset="utf-8" type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head>
  <body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p><h1 class="title" id="title">Tracking Preference Expression (DNT)</h1><h2 id="w3c-working-draft-14-november-2011">W3C Working Draft 14 November 2011</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/">http://www.w3.org/TR/2011/WD-tracking-dnt-20111114/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/tracking-dnt/">http://www.w3.org/TR/tracking-dnt/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html">http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html</a></dd><dt>Editor:</dt><dd><a href="http://roy.gbiv.com/">Roy T. Fielding</a>, <a href="http://www.adobe.com/">Adobe</a></dd>

</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>

    <div class="introductory section" id="abstract"><h2>Abstract</h2>
      This specification defines the technical mechanisms for expressing a
      cross-site tracking preference via the <a class="internalDFN" href="#dfn-dnt-1">DNT</a> request header field in
      HTTP, via an HTML DOM property readable by embedded scripts, and via
      properties accessible to various user agent plug-in or extension APIs.
      It also defines mechanisms for sites to signal whether and how they
      honor this preference, both in the form of a machine-readable policy
      at a well-known location for first-party sites and a <q>Tracking</q>
      response header field for third-party resources that engage in
      cross-site tracking, and a mechanism for allowing the user to approve
      site-specific exceptions to DNT as desired.
    </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

      <p>This draft does not represent a final working group consensus, though an attempt has been made to highlight areas where issues have been identified and present multiple alternatives if they have been discussed.</p>
    <p>This document was published by the <a href="http://www.w3.org/2011/tracking-protection/">Tracking Protection Working Group</a> as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-tracking@w3.org">public-tracking@w3.org</a> (<a href="mailto:public-tracking-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-tracking/">archives</a>). All feedback is welcome.</p><p>Publication as a Working 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.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/49311/status" rel="disclosure">public list of any patent disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p></div><div class="section" id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#notational"><span class="secno">2. </span>Notational Conventions</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">2.1 </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#notation"><span class="secno">2.2 </span>Formal Syntax</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">2.3 </span>Terminology</a></li></ul></li><li class="tocline"><a class="tocxref" href="#determining"><span class="secno">3. </span>Determining User Preference</a></li><li class="tocline"><a class="tocxref" href="#expressing"><span class="secno">4. </span>Expressing a Tracking Preference</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dnt-header-field"><span class="secno">4.1 </span>DNT request header field</a></li><li class="tocline"><a class="tocxref" href="#js-dom"><span class="secno">4.2 </span>HTML DOM Interfaces</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#attributes"><span class="secno">4.2.1 </span>Attributes</a></li><li class="tocline"><a class="tocxref" href="#js-implements"><span class="secno">4.2.2 </span>Implements</a></li></ul></li><li class="tocline"><a class="tocxref" href="#plug-ins"><span class="secno">4.3 </span>Plug-In APIs</a></li></ul></li><li class="tocline"><a class="tocxref" href="#responding"><span class="secno">5. </span>Communicating a Tracking Status</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#response-goals"><span class="secno">5.1 </span>Goals</a></li><li class="tocline"><a class="tocxref" href="#response-criteria"><span class="secno">5.2 </span>Criteria</a></li><li class="tocline"><a class="tocxref" href="#response-options"><span class="secno">5.3 </span>Options</a></li><li class="tocline"><a class="tocxref" href="#response-policy"><span class="secno">5.4 </span>Machine-readable Tracking Policy</a></li><li class="tocline"><a class="tocxref" href="#response-header-field"><span class="secno">5.5 </span>Tracking response header field</a></li><li class="tocline"><a class="tocxref" href="#response-error"><span class="secno">5.6 </span>Status code for Tracking Required</a></li><li class="tocline"><a class="tocxref" href="#exceptions"><span class="secno">5.7 </span>Site-specific Exceptions</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#permanent-exceptions"><span class="secno">5.7.1 </span>Use case: Site-specific exceptions should persist</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#resolved"><span class="secno">B. </span>Closed Issues</a></li><li class="tocline"><a class="tocxref" href="#postponed"><span class="secno">C. </span>Postponed Issues</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">D. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">D.1 </span>Normative references</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">D.2 </span>Informative references</a></li></ul></li></ul></div>


    <div class="section" id="introduction">
      <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>

      <p>
        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.
      </p>
      <p>
        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 <dfn id="dfn-first-party">first-party</dfn> 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.
      </p>

      <p>
        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 analytics providers through the insertion of tracking
        elements on each page.
      </p>
      <p>
        Advertising revenue is the single largest source of funding on the
        Web.  Since advertisers desire an audience that is receptive to
        whatever they happen to be advertising, a significant premium is
        assigned to sites that can demonstrate a favorable target audience,
        and even more so for sites that are able to identify their audience
        dynamically and adjust the advertising displayed to be specific to
        the interests of that user.  In an attempt to better understand or
        predict those interests, some advertising mechanisms follow a user's
        actions over time, collect data on the observed behavior, and use
        that data for targeting future advertisements: a practice commonly
        referred to as online behavioral advertising (OBA).
      </p>
      <p>
        Like analytics data collection, Web sites often contract with
        third-party advertising networks for the tasks of selecting,
        delivering, and measuring the advertising shown on their sites, while
        advertisers often contract with third-party verification companies
        to provide independent accounting of ad impressions and fraud
        detection.
      </p>
      <p>

        There are numerous techniques for integrating advertising
        networks into a website, though most involve some form of embedded
        resource request to a site controlled by the advertising network.
        Since the advertising networks are supplying ads for multiple sites,
        they are capable of monitoring how often a given ad is displayed
        to that same user agent across their entire network (frequency capping).
        Naturally, advertisers consider frequency capping to be a desirable
        feature, and thus it is common for advertisers to contractually limit
        advertising campaigns to a maximum impression count per user.  As a
        result, advertising networks track users from site to site
        even when OBA is not in use.
      </p>
      <p>
        In many cases, Web users welcome the use of data collection for
        personalization and targeted advertising, since it can allow a site
        to tailor the user experience to their specific desires, reduce ads
        that are irrelevant or repetitive, and avoid the imposition of more
        direct revenue in the form of subscription-only services.
        In other cases, personalization and targeting can be perceived as
        <q>creepy</q>, intrusive, and sometimes simply incorrect.
        In particular, targeting and personalization can evoke strong
        negative feelings when data collected at a trusted site is used,
        without the user's consent, for targeting ads on some other site
        with which they have no personal trust relationship.  When cross-site
        tracking or cross-site sharing of data collection does not match the
        user's expectations regarding privacy, the result can be a very
        angry customer.
      </p>
      <p>
        None of the participants in this Web of customization and targeted
        advertising want to offend the user.  For advertisers, it is
        counterproductive.  For Web site owners, it drives away their
        audience and income.  For advertising networks, it leads to blocking
        and lost advertisers.  Therefore, we need a mechanism for the user
        to express their own preference regarding cross-site tracking that is
        both simple to configure and efficient when implemented.
        Likewise, since some Web sites may be dependent on the revenue
        obtained from targeted advertising and unwilling (or unable) to
        permit use of their content without cross-site data collection,
        we need a mechanism for sites to alert the user to those requirements
        and allow the user to configure an exception to DNT for specific sites.
      </p>
      <p>

        This specification defines the HTTP request header field <a class="internalDFN" href="#dfn-dnt-1">DNT</a> for
        expressing a tracking preference on the Web, a well-known location
        (URI) for providing a machine-readable site-wide policy regarding DNT
        compliance, and the HTTP response header field <a>Tracking</a> for
        third-party resources engaged in dynamic tracking behavior to
        communicate their compliance or non-compliance with the user's
        expressed preference.
      </p>
      <p>
        A companion document, <q><a href="http://www.w3.org/TR/tracking-compliance/">Tracking
        Compliance and Scope</a></q>, more precisely 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.
      </p>
    </div>

    <div class="section" id="notational">
      <!--OddPage--><h2><span class="secno">2. </span>Notational Conventions</h2>

      <div class="section" id="requirements">
        <h3><span class="secno">2.1 </span>Requirements</h3>
        <p>The key words <em title="must" class="rfc2119">must</em>,
          <em title="must not" class="rfc2119">must not</em>,
          <em title="required" class="rfc2119">required</em>,
          <em title="should" class="rfc2119">should</em>,
          <em title="should not" class="rfc2119">should not</em>,
          <em title="recommended" class="rfc2119">recommended</em>,
          <em title="may" class="rfc2119">may</em>, and
          <em title="optional" class="rfc2119">optional</em> in this
          specification are to be interpreted as described in
          [<cite><a href="#bib-RFC2119" rel="biblioentry" class="bibref">RFC2119</a></cite>].</p>

      </div>

      <div class="section" id="notation">
        <h3><span class="secno">2.2 </span>Formal Syntax</h3>
        <p>This specification uses Augmented Backus-Naur Form [<cite><a href="#bib-ABNF" rel="biblioentry" class="bibref">ABNF</a></cite>]
          to define network protocol syntax and WebIDL [<cite><a href="#bib-WEBIDL" rel="biblioentry" class="bibref">WEBIDL</a></cite>] for
          defining scripting APIs.</p>
      </div>

      <div class="section" id="terminology">
        <h3><span class="secno">2.3 </span>Terminology</h3>

        <p>
          This specification uses the term <dfn id="dfn-user-agent">user agent</dfn> to refer to
          any of the various client programs capable of initiating HTTP
          requests, including browsers, spiders (web-based robots),
          command-line tools, native applications, and mobile apps [<cite><a href="#bib-HTTP11" rel="biblioentry" class="bibref">HTTP11</a></cite>].
        </p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/13">ISSUE-13 </a>: What are the requirements for DNT on apps/native software in addition to browsers?<br>
          <strong>[PENDING REVIEW]</strong>
          The above paragraph aims at resolving this issue.
        </p>
      </div>
    </div>

    <div class="section" id="determining">

      <!--OddPage--><h2><span class="secno">3. </span>Determining User Preference</h2>

      <p>
        The goal of this protocol is to allow a user to express their
        personal preference regarding cross-site tracking to each server and
        web application that they communicate with via HTTP, thereby allowing
        each server to either adjust their behavior to meet the user's
        expectations or reach a separate agreement with the user to satisfy
        both parties.  Key to that notion of expression is that it <em title="must" class="rfc2119">must</em>
        reflect the user's preference, not the preference of some
        institutional or
        network-imposed mechanism outside the user's control.
      </p>
      <p>
        The remainder of this specification defines the protocol in terms
        of whether DNT is <dfn id="dfn-enabled">enabled</dfn> or <dfn id="dfn-not-enabled">not enabled</dfn>.
        We do not specify how that preference is configured:
        the user agent is responsible for determining the user experience
        by which this preference is set.
      </p>

      <p>
        For example, a user might configure their own user agent to
        tell servers <q>do not track me cross-site</q>, install a plug-in
        or extension that is specifically designed to add that expression,
        or make a choice for privacy that then implicitly includes a
        tracking preference (e.g., <q>Privacy settings: high</q>).  For each
        of these cases, we say that DNT is <a class="internalDFN" href="#dfn-enabled">enabled</a>.
      </p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/4">ISSUE-4</a>:   What is the default for DNT in client configuration (opt-in or opt-out)?<br>
        <strong>[PENDING REVIEW]</strong>

        Proposed text above.
      </p>
    </div>

    <div class="section" id="expressing">
      <!--OddPage--><h2><span class="secno">4. </span>Expressing a Tracking Preference</h2>

      <p>
        When a user has configured a tracking preference, that preference
        needs to be expressed to all mechanisms that might perform or
        initiate tracking by third parties, including sites that the user agent
        communicates with via HTTP, scripts that can extend behavior on
        pages, and plug-ins or extensions that might be installed and
        activated for various media types.
      </p>

      <div class="section" id="dnt-header-field">
        <h3><span class="secno">4.1 </span>DNT request header field</h3>

        <p>
          The <dfn id="dfn-dnt">DNT</dfn> header field is hereby defined as the means for
          expressing a user's tracking preference via HTTP [<cite><a href="#bib-HTTP11" rel="biblioentry" class="bibref">HTTP11</a></cite>].
          A user agent <em title="must" class="rfc2119">must</em> send the <dfn id="dfn-dnt-1">DNT</dfn> header field on all HTTP
          requests if (and only if) DNT is <a class="internalDFN" href="#dfn-enabled">enabled</a>.  A user
          agent <em title="must not" class="rfc2119">must not</em> send the <a class="internalDFN" href="#dfn-dnt-1">DNT</a> header field if DNT is
          <a class="internalDFN" href="#dfn-not-enabled">not enabled</a>.
        </p>

        <pre class="abnf"><dfn id="dfn-dnt-field-name">DNT-field-name</dfn>  = "DNT"                          ; case-insensitive
<dfn id="dfn-dnt-field-value">DNT-field-value</dfn> = ( "0" / "1" ) *DNT-extension   ; case-sensitive
<dfn id="dfn-dnt-extension">DNT-extension</dfn>   = %x21-2B / %x2D-7E              ; visible ASCII except ","
        </pre>
        <p>
          The DNT field-value sent by a user agent <em title="must" class="rfc2119">must</em> begin with the
          character "1" (%x31) if DNT is <a class="internalDFN" href="#dfn-enabled">enabled</a> and there is not,
          to the user agent's knowledge, a specific exception for the origin
          server targeted by this request.
          If DNT is <a class="internalDFN" href="#dfn-enabled">enabled</a> and there is a specific exception for
          the target origin server via some mechanism understood by the
          user agent, then the DNT field-value sent by a user agent <em title="must" class="rfc2119">must</em> begin
          with the character "0" (%x30).
        </p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/78">ISSUE-78</a>: What is the difference between absence of DNT header and DNT = 0?<br>
          <strong>[PENDING REVIEW]</strong>
          Proposed text above defines that a "0" may only be sent when DNT is
          enabled and some mechanism known to the user agent has specifically
          made an exception for this origin server.  Note that we have not
          defined such a mechanism (and probably won't do so).  If DNT is
          disabled or not implemented, no DNT header field is sent.
        </p>
        <pre class="example">GET /something/here HTTP/1.1
Host: example.com
DNT: 1</pre>
        <p>
          An HTTP intermediary <em title="must not" class="rfc2119">must not</em> add, delete, or modify the DNT header
          field in requests forwarded through that intermediary unless that
          intermediary has been specifically installed or configured to do so
          by the user making the requests.  For example, an Internet Service
          Provider <em title="must not" class="rfc2119">must not</em> inject <q>DNT: 1</q> on behalf of all of their
          users who have not selected a choice.
        </p>

        <p>
          The remainder of the DNT field-value after the initial character is
          reserved for future extensions.  User agents that do not implement
          such extensions <em title="must not" class="rfc2119">must not</em> send DNT-extension characters in the DNT
          field-value.  Servers that do not implement such extensions <em title="should" class="rfc2119">should</em>
          ignore anything beyond the first character.
        </p>
        <p>
          DNT extensions are to be interpreted as modifiers to the
          main preference expressed by the first digit, such that the main
          preference will be obeyed if the recipient does not understand the
          extension.  Hence, a DNT-field-value of "1xyz" can be thought of
          as <q>DNT is enabled, but if you understand the refinements defined
          by x, y, or z, then adjust my preferences according to those
          refinements.</q>  Extensions can only transmitted if DNT is
          <a class="internalDFN" href="#dfn-enabled">enabled</a>.  The extension syntax excludes the comma (",")
          character in order to to differentiate valid field values from an
          invalid occurrence of multiple DNT header fields that have been
          combined as a single comma-separated list by a generic HTTP parser.
        </p>

        <p class="note">
          Designers of future extensions should note that, if enabled,
          DNT is sent on every request and is thus in the critical
          path for a server attempting to read and act on every request.
          Use as few extension characters as possible.
        </p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/82">ISSUE-82</a>: Should the DNT header be extensible with additional parameters?<br>
          <strong>[PENDING REVIEW]</strong>
          The above paragraphs allow for an extension string. At this point,
          no extensions have been defined.
        </p>
      </div>

      <div class="section" id="js-dom">
        <h3><span class="secno">4.2 </span>HTML DOM Interfaces</h3>

        <p>
          The <a class="idlType" href="#idl-def-NavigatorDoNotTrack"><code>NavigatorDoNotTrack</code></a> interface provides a means for
          the user's cross-site tracking preference to be expressed to
          web applications running within a page rendered by the user agent.
        </p>

        <pre class="idl"><span class="idlInterface" id="idl-def-NavigatorDoNotTrack">[<span class="extAttr">NoInterfaceObject</span>]
interface <span class="idlInterfaceID">NavigatorDoNotTrack</span> {

<span class="idlAttribute">    readonly attribute <span class="idlAttrType"><a>DOMString</a></span> <span class="idlAttrName"><a href="#widl-NavigatorDoNotTrack-doNotTrack">doNotTrack</a></span>;</span>
};</span>
</pre><div class="section" id="attributes"><h4><span class="secno">4.2.1 </span>Attributes</h4><dl class="attributes"><dt id="widl-NavigatorDoNotTrack-doNotTrack"><code>doNotTrack</code> of type <span class="idlAttrType"><a>DOMString</a></span>, readonly</dt><dd>

            When DNT is <a class="internalDFN" href="#dfn-enabled">enabled</a>, the doNotTrack attribute <em title="must" class="rfc2119">must</em> have a
            string value that is the same as the <a class="internalDFN" href="#dfn-dnt-field-value">DNT-field-value</a>
            defined in <a href="#dnt-header-field" class="sectionRef">section 4.1 DNT request header field</a>.
            If DNT is <a class="internalDFN" href="#dfn-not-enabled">not enabled</a>, the value is <code>null</code>.
          <div><em>No exceptions.</em></div></dd></dl></div>

        <div class="section" id="js-implements">
          <h4><span class="secno">4.2.2 </span>Implements</h4>
          <pre class="idl"><span class="idlImplements"><a>Navigator</a> implements <a class="idlType" href="#idl-def-NavigatorDoNotTrack"><code>NavigatorDoNotTrack</code></a>;</span></pre><div class="idlImplementsDesc">
             Objects implementing the <code>Navigator</code> interface
             [<cite><a href="#bib-NAVIGATOR" rel="biblioentry" class="bibref">NAVIGATOR</a></cite>] (e.g., the <code>window.navigator</code> object)
             <em title="must" class="rfc2119">must</em> also implement the <code>NavigatorDoNotTrack</code>

             interface.
             An instance of <code>NavigatorDoNotTrack</code> is obtained
             by using binding-specific casting methods on an instance of
             <code>Navigator</code>.
          </div>
        </div>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/84">ISSUE-84</a>: Do we need a JavaScript API / DOM property for client-side js access to Do Not Track status?<br>
          <strong>[PENDING REVIEW]</strong>

          We believe that we need such an API. This section proposes one.
        </p>
      </div>

      <div class="section" id="plug-ins">
        <h3><span class="secno">4.3 </span>Plug-In APIs</h3>

        <p>
          User agents often include user-installable component parts,
          commonly known as <dfn id="dfn-plug-ins">plug-ins</dfn> or
          <dfn id="dfn-browser-extensions">browser extensions</dfn>, that are capable of making their own
          network requests.  From the user's perspective, these components
          are considered part of the user agent and thus ought to respect the
          user's configuration of a tracking preference.  However, plug-ins
          do not normally have read access to the browser configuration.
          Therefore, we will define here various mechanisms for communicating
          the DNT preference via common plug-in APIs.
        </p>

      </div>
    </div>

    <div class="section" id="responding">
      <!--OddPage--><h2><span class="secno">5. </span>Communicating a Tracking Status</h2>
        The companion document, <q><a href="http://www.w3.org/TR/tracking-compliance/">Tracking
        Compliance and Scope</a></q>, defines how service providers are
        expected to comply when they receive an expression of the user's
        tracking preference via any of the mechanisms described in
        <a href="#expressing" class="sectionRef">section 4. Expressing a Tracking Preference</a>.
      <p></p>

      <p>
        If no DNT preference is received, it may indicate either that
        the user has chosen to allow cross-site tracking or that their
        user agent does not support this protocol for expressing DNT
        (e.g., user agents deployed prior to this protocol's existence).
        In the absence of regulatory, legal, or other requirements, servers
        are free to interpret the lack of a DNT header as they find most
        appropriate for the given user, particularly when considered in
        light of the user's privacy expectations and cultural circumstances.
      </p>
      <p>
        This section defines how a server communicates its compliance with
        tracking preferences, including whether it will honor the user's
        preference, require some form of site-specific exception, or indicate
        that it already has the user's permission via some other agreement
        (e.g., a subscription or account agreement).  Optionally, links can be
        provided to human-readable information regarding the site's tracking
        policies or where to go to opt-in, opt-out, or edit their personal
        information.
      </p>

      <div class="section" id="response-goals">
        <h3><span class="secno">5.1 </span>Goals</h3>

        <p>
          The following goals have been identified as reasons for having a
          response from the server:
        </p>
        <ol>
          <li>Auditing compliance by servers</li>
          <li>Measuring deployment of DNT</li>
          <li>Transparency
          <ul>
            <li>allow user awareness of DNT status per-site/element</li>
            <li>indicate what elements on page have ack'd/honored DNT</li>
          </ul>
          </li>
          <li>Guidance for site-specific exceptions</li>
        </ol>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/98">ISSUE-98</a>: Consider applicable laws and regulations, such as Article 5(3) of the EU ePrivacy Directive</p>

      </div>

      <div class="section" id="response-criteria">
        <h3><span class="secno">5.2 </span>Criteria</h3>

        <p>
          The following criteria have been identified as constraints on the
          response design:
        </p>
        <ol>

          <li>Minimize impact on cacheable responses</li>
          <li>Simplicity</li>
          <li>Scalability</li>
          <li>Express fine-grained track/no-track for pieces of a site</li>
        </ol>
      </div>

      <div class="section" id="response-options">
        <h3><span class="secno">5.3 </span>Options</h3>

        <p>
          There have been many suggestions, but not much consensus, on how
          servers ought to respond when DNT is enabled.  The various
          suggestions can be roughly categorized as follows:
        </p>
        <ul>
          <li>No response.</li>

          <li>A well-known location for machine-readable site-wide policy.</li>
          <li>A static link header field for machine-readable policy.</li>
          <li>A static header field indicating that DNT is honored.</li>
          <li>A dynamic header field indicating that tracking is enabled or
            disabled for this user (and why).</li>
        </ul>
        <p>
          and also some combinations of the above.  For example, we might
          define that compliant servers provide a machine-readable site-wide
          policy that indicates how they honor DNT, what sites are considered
          the same brand, and links to resources for providing site-specific
          exceptions to DNT or editing collected tracking data.  We could
          then limit use of a tracking response header field to only those
          dynamic responses for third-party resources that engage in tracking.
        </p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/81">ISSUE-81</a>: Do we need a response at all from server?<br>
          <strong>[PENDING REVIEW]</strong>
          Yes: The users expect to be able to see whether a DNT header is
          accepted, rejected, or sent into the void.
        </p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/79">ISSUE-79</a>: Should a server respond if a user sent DNT:0?</p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/51">ISSUE-51</a>: Should 1st party have any response to DNT signal</p>

      </div>

      <div class="section" id="response-policy">
        <h3><span class="secno">5.4 </span>Machine-readable Tracking Policy</h3>

        <p>This can be defined as either a well-known location, as
          defined by RFC5785, or as a Link header field sent in response
          to any request (regardless of DNT).</p>
        <ul>
          <li>e.g., "http://example.com/.well-known/tracking"</li>

          <li>machine-readable (JSON or similar)</li>
          <li>include booleans for compliance</li>
          <li>optionally include list of domains for same-brand scope</li>
          <li>optionally include link to user-readable policy document</li>
          <li>optionally include link to opt-in/out form</li>
          <li>optionally include link to edit data collected</li>

          <li>accessible before making use of site's services</li>
          <li>allows third-party sites to indicate their own policies</li>
        </ul>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/47">ISSUE-47</a>: Should the response from the server point to a URI of a policy (or an existing protocol) rather than a single bit in the protocol?</p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/80">ISSUE-80</a>: Instead of responding with a Link: header URI, does it make sense to use a well-known location for this policy?</p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/87">ISSUE-87</a>: Should there be an option for the server to respond with "I don't know what my policy is"</p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/61">ISSUE-61</a>: A site could publish a list of the other domains that are associated with them</p>
      </div>

      <div class="section" id="response-header-field">
        <h3><span class="secno">5.5 </span>Tracking response header field</h3>

        <ul>
          <li>sent on all responses?</li>

          <li>sent only on dynamic/tracking responses?</li>
          <li>different on dynamic vs static responses?
              E.g, static headers for elements that never track (like <q>i am neutral</q>) and dynamic headers when <q>I am a tracking element and I accept your choice to not be tracked</q></li>
          <li>does it indicate when a site believes it has an exemption from DNT,
            such that the user can react appropriately if it isn't true. ...
              The header could say <q>I see that you say DNT, but i am
              tracking you for the following reasons.</q>
          </li><li>it is sometimes contextual whether you are tracking or not.
        </li></ul>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/76">ISSUE-76</a>: Should a server echo the DNT header to confirm receipt?</p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/48">ISSUE-48</a>: Response from the server could both acknowledge receipt of a value and (separately) whether the server will honor it</p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/90">ISSUE-90</a>: Interaction of DNT with caching and intermediaries</p>
      </div>

      <div class="section" id="response-error">
        <h3><span class="secno">5.6 </span>Status code for Tracking Required</h3>

        <p>An HTTP error response status code might be useful for indicating
          that the site refuses service unless the user either logs into a
          subscription account or agrees to an exception to DNT for this
          site and its contracted third-party sites.
      </p></div>

      <div class="section" id="exceptions">
        <h3><span class="secno">5.7 </span>Site-specific Exceptions</h3>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/43">ISSUE-43</a>: Sites should be able to let the user know their options when they arrive with Do Not Track</p>
        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/27">ISSUE-27</a>: How should the "opt back in" mechanism be designed?</p>

        <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/46">ISSUE-46</a>: Enable users to do more granular blocking based on whether the site responds honoring Do Not Track</p>

        <div class="section" id="permanent-exceptions">
          <h4><span class="secno">5.7.1 </span>Use case: Site-specific exceptions should persist</h4>

          <p>It would annoy users of DNT if they are presented with an
            exception dialog each time they visit a site.</p>
          <ol>
            <li>User turns on DNT and visits Example.com</li>

            <li>Example.com does not receive a signal it's on the
              exception list</li>
            <li>Example.com requests exception to DNT from user to access
              content for free</li>
            <li>User grants exception to Example.com (and perhaps
              listed parties)</li>
            <li>User views content</li>
            <li>User returns to Example.com a week later</li>
            <li>DNT signal is still turned on but Example.com is sent an
              exception flag (or else doesn't send a DNT signal at all)
            </li><li>In either case, it'll be important that Example.com know
              to not trigger the exception request for this
              user/web browser/device</li>

          </ol>
        </div>

      </div>
    </div>


    <div id="acknowledgements" class="appendix section">
      <!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
      <p>

        This specification consists of input from many discussions within
        and around the W3C Tracking Protection Working Group, along with
        written contributions from
        Roy&nbsp;T.&nbsp;Fielding (Adobe),
        Tom&nbsp;Lowenthal (Mozilla),
        Aleecia&nbsp;M.&nbsp;McDonald (Mozilla),
        Matthias&nbsp;Schunter (IBM),
        and Shane&nbsp;Wiley (Yahoo!).
      </p>
      <p>
        The DNT header field is based on the original <em>Do Not Track</em>
        submission by Jonathan&nbsp;Mayer (Stanford), Arvind&nbsp;Narayanan
        (Stanford), and Sid&nbsp;Stamm (Mozilla).
        The DOM API for <code>NavigatorDoNotTrack</code> is based on the
        <em>Web Tracking Protection</em> submission by Andy&nbsp;Zeigler,
        Adrian&nbsp;Bateman, and Eliot&nbsp;Graff (Microsoft).
        Many thanks to Robin&nbsp;Berjon for ReSpec.js.
      </p>

    </div>

    <div class="section" id="resolved">
      <!--OddPage--><h2><span class="secno">B. </span>Closed Issues</h2>

      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/2">ISSUE-2</a>:   What is the meaning of DNT (Do Not Track) header?<br>
        <strong>[CLOSED]</strong>

        "Does the presence of a DNT header field on requests always indicate
        an explicit choice". <br>
        The answer we agreed upon is "yes".
      </p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/50">ISSUE-50</a>: Are DNT headers sent to first parties? <b>Yes</b></p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/70">ISSUE-70</a>: Does a past HTTP request with DNT set affect future HTTP requests? <b>No</b></p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/40">ISSUE-40</a>: Enable Do Not Track just for a session, rather than being stored<br>

        <strong>[CLOSED]</strong>
        Resolved in DNT Call 2011-10-26: The user agents are free to send
        different DNT values for different sessions.  We agreed that this is
        a user-interface issue and out of scope on its own.
      </p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/68">ISSUE-68</a>: Should there be functionality for syncing preferences about tracking across different browsers?<br>
        <strong>[CLOSED]</strong>
        Resolved in DNT Call 2011-10-26: The user agents may or may not sync.
        However, this is out of scope for this spec.
      </p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/42">ISSUE-42</a>: Feedback to the user from the browser when Do Not Track is turned on</p>

    </div>

    <div class="section" id="postponed">
      <!--OddPage--><h2><span class="secno">C. </span>Postponed Issues</h2>

      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/44">ISSUE-44</a>: Ability to measure/detect who is honoring Do Not Track at a technical level<br>
        <strong>[POSTPONED]</strong>

        The info at the well-known URI declares whether a server promises to
        follow DNT. Whether it actually does (or just pretends to do so) is
        hard to determine and should be addressed later.
      </p>
      <p class="issue"><a href="http://www.w3.org/2011/tracking-protection/track/issues/64">ISSUE-64</a>: How does site preference management work with DNT<br>
        <strong>[POSTPONED]</strong>
        To what extent cookies can be used for preference management (such as
        storing a language preference) will be resolved later.
      </p>
    </div>


<div class="appendix section" id="references"><!--OddPage--><h2><span class="secno">D. </span>References</h2><div class="section" id="normative-references"><h3><span class="secno">D.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-ABNF">[ABNF]</dt><dd>D. Crocker and P. Overell. <a href="http://www.ietf.org/rfc/rfc5234.txt"><cite>Augmented BNF for Syntax Specifications: ABNF.</cite></a> January 2008. Internet RFC 5234. URL: <a href="http://www.ietf.org/rfc/rfc5234.txt">http://www.ietf.org/rfc/rfc5234.txt</a>

</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd>R. Fielding; et al. <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1.</cite></a> June 1999. Internet RFC 2616. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>
</dd><dt id="bib-NAVIGATOR">[NAVIGATOR]</dt><dd>Ian Hickson, David Hyatt. <a href="http://dev.w3.org/html5/spec/timers.html#navigator"><cite>Navigator interface in HTML5.</cite></a> 15 April 2011. Editors' draft. (Work in progress.) URL: <a href="http://dev.w3.org/html5/spec/timers.html#navigator">http://dev.w3.org/html5/spec/timers.html#navigator</a>
</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119.  URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>

</dd><dt id="bib-WEBIDL">[WEBIDL]</dt><dd>Cameron McCormack. <a href="http://www.w3.org/TR/2008/WD-WebIDL-20081219"><cite>Web IDL.</cite></a> 19 December 2008. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/2008/WD-WebIDL-20081219">http://www.w3.org/TR/2008/WD-WebIDL-20081219</a>
</dd></dl></div><div class="section" id="informative-references"><h3><span class="secno">D.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>