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

ACTION-115: Write up counter-proposal to header with well-known URI

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sat, 11 Feb 2012 05:31:01 -0800
Message-Id: <EF0BDACE-33E9-4643-889C-0F43E266E343@gbiv.com>
To: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
ACTION-115: Write up counter-proposal to header with well-known URI
Related to ISSUE-124, ISSUE-61, ISSUE-90, ISSUE-111

Here is a proposal for a well-known resource space that covers all
previously agreed considerations for a verifiable response to DNT.
It will be easier to read in the editor's draft.


      <section id='status-resource'>
        <h3>Tracking Status Resource</h3>

        <p class="note">This section is new and untested.</p>
        <p>
          An origin server MUST provide a space of well-known resources
          [RFC5785] for obtaining information about the potential tracking
          behavior of each service provided by that origin server.  This
          parallel tree of resources is called the tracking status resource
          space.  Failure to provide such a resource space MAY be considered
          equivalent to not implementing this protocol.
        </p>
        <p>
          The tracking status resource space is defined by the
          following URI Template [RFC_UT_]:
        </p>
<pre>/.well-known/dnt{+pathinfo}</pre>
        <p>
          where the value of <code>pathinfo</code> is equal to the
          path-absolute component of a given reference to that origin server,
          excluding those references already within the above resource space.
          For example, a reference to
        </p>
<pre>http://example.com/over/here?q=hello#top</pre>
        <p>
          MUST have a corresponding tracking status resource identified by
        </p>
<pre>http://example.com/.well-known/dnt/over/here</pre>
        <p>
          A valid retrieval request (e.g., a <code>GET</code> in [HTTP11])
          on a tracking status resource MUST result in either a successful
          response containing a machine-readable representation of the
          corresponding resource's tracking status, as defined below, or
          a redirect that leads to such a representation.  Failure to provide
          access to such a representation MAY be considered equivalent to
          not implementing this protocol.
        </p>
        <p>
          A key advantage of providing the tracking status at a resource
          separate from the site's normal services is that it can be accessed
          and reviewed prior to making use of those services and prior to
          making requests on third-party resources referenced by those
          services.
          All responses to requests on a tracking status resource, including
          redirected requests, MUST NOT include Set-Cookie or Set-Cookie2
          header fields and MUST NOT include content that has the effect of
          initiating additional tracking beyond what is already present for
          the request.  A user agent SHOULD ignore or treat as an error any
          Set-Cookie or Set-Cookie2 header field received in such a response.
        </p>
        <p>
          A tracking status resource space MUST be provided for each origin
          server involved in providing services for a given site in order for
          the service as a whole to be considered conformant to this protocol.
          However, access to these resources MAY be redirected to one or more
          common resources for provision of the tracking status.  If the
          redirect is to a prefix of the tracking status URI within the same
          resource space, as would be the case for the example above if it
          redirected to the
        </p>
<pre>http://example.com/.well-known/dnt/</pre>
        <p>
          URI, then the user agent MAY assume that all resources under that
          <code>pathinfo</code> ("/") share the same tracking status.
        </p>
      
        <section id='status-representation'>
          <h3>Tracking Status Representation</h3>
          <p>
            The representation of a site's tracking status SHALL be provided
            in the "application/json" format [[!RFC4627]] and MUST conform to
            the ABNF in <a href="#status-abnf" class="sectionRef"></a>.
            The following is an example tracking status representation that
            illustrates all of the fields defined by this specification,
            most of which are optional. 
          </p>
<pre class="example">
{
  "path": "/",
  "tracking": true,
  "received": "1",
  "response": "t1",
  "same-site": [
    "example.com",
    "example_vids.net",
    "example_stats.com"
  ],
  "partners": [
    "api.example-third-party.com"
  ],
  "policy": "/tracking.html",
  "edit": "http://example-third-party.com/your/data",
  "options": "http://example-third-party.com/your/consent"
}
</pre>
          <p>
            A representation consists of a single <a>status-object</a> that
            describes the current tracking status for the corresponding
            resource.  If the status object has a <code><a>path</a></code>
            member, then it also describes the tracking status for the
            entire space of resources with the indicated path prefix.
            The <code><a>path</a></code> member MAY be elided if the
            tracking status applies only to the corresponding resource.
            The <code><a>path</a></code> MUST be interpreted relative to the
            originally referenced resource even if the tracking status
            request has been redirected to a different server.
          </p>
          <p>
            The status object MUST have a member named
            <code><a>tracking</a></code> with a boolean value.
            A value of <code><a>false</a></code> indicates that the
            corresponding resource does not perform tracking as defined by
            <q><a href="tracking-compliance.html">Tracking
            Compliance and Scope</a></q>.
            A value of <code><a>true</a></code> indicates that the
            corresponding resource performs tracking and claims to conform to
            all tracking compliance requirements applicable to this site.
            For example, the following demonstrates a minimal tracking status
            representation that is applicable to any resource that does not
            perform tracking.
          </p>
<pre class="example">
{"tracking": false}
</pre>
          <p>
            If <code><a>tracking</a></code> is <code><a>true</a></code>,
            the status object MUST include two additional members, named
            <code><a>received</a></code> and <code><a>response</a></code>,
            and MAY include other members as described below.
          </p>
          <p>
            The <code><a>received</a></code> member MUST have either a
            string value equal to the <a>DNT-field-value</a> received in that
            request or the value <code><a>null</a></code> if no
            <a>DNT-field-value</a> was received.
          </p>
          <p>
            The <code></a>response</a></code> member MUST have a string value
            that indicates the status of tracking applicable specifically to
            this user in light of the received <a>DNT-field-value</a>.
            The string value has the following structure:
          </p>
<pre class="abnf">
<dfn>r-codes</dfn>     = "n"                      ; tracking disabled
               / ("t" *limitations )   ; tracking enabled
                    
<dfn>limitations</dfn> = "1"                      ; first-party
               / "c"                   ; frequency capping
               / "f"                   ; fraud prevention
               / "r"                   ; referral tracking
               / ALPHA / DIGIT         ; TBD
</pre>
          </p>
          <p>
            An OPTIONAL member named <code><a>same-site</a></code> can be
            provided with an array value containing a list of domain names
            that the origin server claims are the same site, to the extent
            they are referenced on this site, since all data collected via
            those references share the same data controller.
          </p>
          <p>
            An OPTIONAL member named <code><a>partners</a></code> can be
            provided with an array value containing a list of
            domain names for third-party services that might track the user
            as a result of using this site and do not have the same
            data controller as this site.
          </p>
          <p>
            An OPTIONAL member named <code><a>policy</a></code> can be
            provided with a string value containing a URI-reference to a
            human-readable document that describes the tracking policy for
            this site.  The content of such a policy document is beyond the
            scope of this protocol and SHOULD ONLY be considered as
            supplemental to what is described by this machine-readable
            tracking status representation.
          </p>
          <p>
            An OPTIONAL member named <code><a>edit</a></code> can be
            provided with a string value containing a URI-reference to a
            resource intended to allow a tracked user agent to review or
            delete data collected by this site, if any such data
            remains associated with this user agent.  The design of such
            a resource and the extent to which it can provide access to
            that data is beyond the scope of this protocol.
          </p>
          <p>
            An OPTIONAL member named <code><a>options</a></code> can be
            provided with a string value containing a URI-reference to a
            resource intended to allow a user agent to <q>opt-in</q>,
            <q>opt-out</q>, or otherwise modify their consent status
            regarding data collection by this site.  The design of such
            a resource and how it might implement an out-of-band consent
            mechanism is beyond the scope of this protocol.
          </p>
          <p>
            Additional <code><a>extension</a></code> members MAY be provided
            in the tracking status object to support future enhancements to
            this protocol.  A user agent SHOULD ignore extension members
            that it does not recognize.
          </p>
          <p>
            Note that the tracking status resource space applies equally to
            both first-party and third-party services.  An example of a
            third-party tracking status is
<pre class="example">
{
  "tracking": true,
  "received": "1",
  "response": "n",
  "policy": "/privacy.html",
  "edit": "/your/data",
  "options": "/your/consent"
}
</pre>
          <p class='issue'><a href="http://www.w3.org/2011/tracking-protection/track/issues/47">ISSUE-47</a>: Should the response from the server indicate a policy that describes the DNT practices of the server?</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>
        </section>

        <section id='status-abnf'>
          <h3>Tracking Status ABNF</h3>
          <p>
            The representation of a site's machine-readable tracking status
            MUST conform to the following ABNF for <a>status-object</a>,
            except that the members within each member-list MAY be provided
            in any order. 
          </p>
        <pre class="abnf">
<dfn>status-object</dfn> = begin-object member-list end-object
<dfn>member-list</dfn>   = [ path ns path-v vs      ]
                tracking       ns tracking-v
                [ vs received  ns received-v  ]
                [ vs response  ns response-v  ]
                [ vs same-site ns same-site-v ]
                [ vs partners  ns partners-v  ]
                [ vs policy    ns policy-v    ]
                [ vs edit      ns edit-v      ]
                [ vs options   ns options-v   ]
                *( vs extension )

<dfn>path</dfn>          = %x22 "path" %x22
<dfn>path-v</dfn>        = string       ; URI absolute-path

<dfn>tracking</dfn>      = %x22 "tracking" %x22
<dfn>tracking-v</dfn>    = true / false

<dfn>received</dfn>      = %x22 "received" %x22
<dfn>received-v</dfn>    = null / string

<dfn>response</dfn>      = %x22 "response" %x22
<dfn>response-v</dfn>    = %x22 <a>r-codes</a> %x22

<dfn>same-site</dfn>     = %x22 "same-site" %x22
<dfn>same-site-v</dfn>   = array-of-strings

<dfn>partners</dfn>      = %x22 "partners" %x22
<dfn>partners-v</dfn>    = array-of-strings

<dfn>policy</dfn>        = %x22 "policy" %x22
<dfn>policy-v</dfn>      = string       ; URI-reference

<dfn>edit</dfn>          = %x22 "edit" %x22
<dfn>edit-v</dfn>        = string       ; URI-reference

<dfn>options</dfn>       = %x22 "options" %x22
<dfn>options-v</dfn>     = string       ; URI-reference

<dfn>extension</dfn>     = object

<dfn>array-of-strings</dfn> = begin-array
                   [ string *( vs string ) ]
                   end-array 

<dfn>ns</dfn>            = &lt;name-separator  (:), as defined in [[!RFC4627]]&gt;
<dfn>vs</dfn>            = &lt;value-separator (,), as defined in [[!RFC4627]]&gt;

<dfn>begin-array</dfn>   = &lt;begin-array  ([), as defined in [[!RFC4627]]&gt;
<dfn>end-array</dfn>     = &lt;end-array    (]), as defined in [[!RFC4627]]&gt;
<dfn>begin-object</dfn>  = &lt;begin-object ({), as defined in [[!RFC4627]]&gt;
<dfn>end-object</dfn>    = &lt;end-object (}), as defined in [[!RFC4627]]&gt;
<dfn>string</dfn>        = &lt;string, as defined in [[!RFC4627]]&gt;
<dfn>true</dfn>          = &lt;true, as defined in [[!RFC4627]]&gt;
<dfn>false</dfn>         = &lt;false, as defined in [[!RFC4627]]&gt;
<dfn>null</dfn>          = &lt;null, as defined in [[!RFC4627]]&gt;
        </pre>
        </section>
      
        <section id='status-caching'>
          <h3>Tracking Status Caching</h3>

          <p>
            If the tracking status is applicable to all users, regardless of
            the received DNT-field-value or other data received via the
            request, then the response SHOULD be marked as cacheable and
            assigned a time-to-live (expiration or max-use) that is sufficient
            to enable shared caching but not greater than the earliest point
            at which the site's tracking behavior might increase.  For example,
            if the tracking status response is set to expire in seven days,
            then the earliest point in time that the site's tracking behavior
            can be increased is seven days after the policy has been updated
            to reflect the new behavior, since old copies might persist in
            caches until the expiration is triggered.  A site's tracking
            behavior can be reduced at any time, with or without a
            corresponding change to the tracking status resource.
          </p>
          <p>
            If the tracking status is only applicable to all users that have
            the same DNT-field-value, then either the response MUST include a
            Cache-Control header field with one of the directives "no-cache",
            "no-store", "must-revalidate", or "max-age=0", or
            the response MUST include a Vary header field that includes "DNT"
            in its field-value.
          </p>
          <p>
            If the tracking status is only applicable to the specific user
            that requested it, then the response MUST include a
            Cache-Control header field with one of the directives "no-cache",
            "no-store", "must-revalidate", or "max-age=0".
          </p>
          <p>
            Regardless of the cache-control settings, it is expected that
            user agents will check the tracking status of a site only once
            per session (at most).  A public Internet site that intends to
            change its tracking status to increase tracking behavior MUST
            update the tracking status resource in accordance with that
            planned behavior at least twenty-four hours prior to activating
            that new behavior on the site.
          </p>
        </section>
      </section>
  


Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>
Received on Saturday, 11 February 2012 13:31:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:45 UTC