- 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>
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> = <name-separator (:), as defined in
> [[!RFC4627]]> <dfn>vs</dfn> = <value-separator (,), as
> defined in [[!RFC4627]]>
>
> <dfn>begin-array</dfn> = <begin-array ([), as defined in
> [[!RFC4627]]> <dfn>end-array</dfn> = <end-array (]), as
> defined in [[!RFC4627]]> <dfn>begin-object</dfn> = <begin-object
> ({), as defined in [[!RFC4627]]> <dfn>end-object</dfn> =
> <end-object (}), as defined in [[!RFC4627]]> <dfn>string</dfn>
> = <string, as defined in [[!RFC4627]]> <dfn>true</dfn> =
> <true, as defined in [[!RFC4627]]> <dfn>false</dfn> =
> <false, as defined in [[!RFC4627]]> <dfn>null</dfn> =
> <null, as defined in [[!RFC4627]]> </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