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

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

From: Rigo Wenning <rigo@w3.org>
Date: Wed, 22 Feb 2012 18:13:27 +0100
To: public-tracking@w3.org
Cc: "Roy T. Fielding" <fielding@gbiv.com>
Message-ID: <14000822.j1Bxqho8sW@hegel.sophia.w3.org>
Hi Roy, 

why don't we take the P3P compact vocab or even the full statement vocab at 
the well-known location? Those are well established and understood semantics. 

http://www.w3.org/TR/P3P11/#compact_policy_vocabulary

Best, 

Rigo

On Saturday 11 February 2012 05:31:01 Roy T. Fielding wrote:
> 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 Wednesday, 22 February 2012 17:13:59 UTC

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