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

On Feb 11, 2012, at 5:31 AM, 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

and ISSUE-80 and ISSUE-47.

After getting some sleep, I have revised the proposal to optimize for the
common case (one policy per domain) and to fully describe the verification
process.  A plain text version is below, with HTML in the editor's draft.


  5.1 Tracking Status Resource

   An origin server must provide a well-known resource [RFC5785] at the
   identifier path

      /.well-known/dnt

   (relative to the URI of that origin server) for obtaining information
   about the potential tracking behavior of services provided by that origin
   server. A tracking status resource may be used for verification of DNT
   support, as described in section 5.1.2 Using the Tracking Status.

   A valid retrieval request (e.g., a GET in [HTTP11]) on the well-known URI
   must result in either a successful response containing a machine-readable
   representation of the site-wide tracking status, as defined below, or a
   sequence of redirects that leads to such a representation. A user agent
   may consider failure to provide access to such a representation equivalent
   to the origin server not implementing this protocol. The representation
   might be cached, as described in section 5.1.3 Tracking Status Caching.

   If an origin server contains multiple services that are controlled by
   distinct parties or that might have differing behavior or policies
   regarding tracking, then it may also provide a space of well-known
   resources for obtaining information about the potential tracking behavior
   of each specific service. This parallel tree of resources is called the
   tracking status resource space.

   The tracking status resource space is defined by the following URI
   Template [RFC_UT_]:

      /.well-known/dnt{+pathinfo}

   where the value of pathinfo is equal to the path component [RFC3986] of a
   given reference to that origin server, excluding those references already
   within the above resource space. For example, a reference to

      http://example.com/over/here?q=hello#top

   may have a corresponding tracking status resource identified by

      http://example.com/.well-known/dnt/over/here

   Resources within the tracking status resource space are represented using
   the same format as a site-wide tracking status resource.

   All responses to requests on a tracking status resource, including
   redirected requests, must not include Set-Cookie or Set-Cookie2 header
   fields [RFC6265] and must not include content that would have the effect
   of initiating 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.

    5.1.1 Tracking Status Representation

   The representation of a tracking status resource shall be provided in the
   "application/json" format [RFC4627] and must conform to the ABNF in
   section 5.1.4 Tracking Status ABNF. The following is an example tracking
   status representation that illustrates all of the fields defined by this
   specification, most of which are optional.

      {
        "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"
      }

   A tracking status representation consists of a single status-object
   containing members that describe the tracking status applicable to this
   user agent's request.

   If the status-object has an optional path member, then this object
   describes the tracking status for the entire space of resources that share
   the same path prefix as the value of path. The user agent must interpret
   the path value relative to the originally referenced resource, not the
   resource where it obtained the tracking status representation.

   For the site-wide tracking status resource, the presence of a path member
   with a value of "/" indicates that this status-object applies for the
   entire origin server of the originally referenced resource. If the
   originally referenced resource's path component does not share the same
   prefix as the value of path, or if the path member is absent, then the
   tracking status for the referenced resource may be obtained via a request
   on the corresponding tracking status resource space.

   A status-object must have a member named tracking with a boolean value. A
   value of false indicates that the corresponding resources do not perform
   tracking as it is defined by Tracking Compliance and Scope. A value of
   true 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.

      {"tracking": false}

   The following status-object would indicate that the entire site does not
   perform tracking.

      {"path": "/", "tracking": false}

   If tracking is true, the status-object must include two additional
   members, named received and response, and may include other members as
   described below.

   The received member must have either a string value equal to the
   DNT-field-value received in that request or the value null if no
   DNT-field-value was received. Any invalid characters received in the
   DNT-field-value must be elided from the string value to ensure that
   invalid data is not injected into the JSON result.

   The response member must have a string value that indicates the status of
   tracking applicable specifically to this user in light of the received
   DNT-field-value. The string value begins with "t" (tracking) or "n" (not
   tracking) and may be followed by alphanumeric characters that indicate
   reasons for that status, as described in the following table.

          reasons     meaning                       
             1    Designed for use as a first-party only             
             3    Designed for use as a third-party                  
             a    Limited to advertising audits                      
             c    Prior consent received from this user agent        
             f    Limited to fraud prevention                        
             g    For compliance with regional/geographic            
                  constraints                                        
             q    Limited to advertising frequency capping           
             r    Limited to referral information                    

   An optional member named same-site may 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.

   An optional member named partners may 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 which do not have the
   same data controller as this site.

   An optional member named policy may 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 only supplemental to what is
   described by this machine-readable tracking status representation.

   An optional member named edit may 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.

   An optional member named options may be provided with a string value
   containing a URI-reference to a resource intended to allow a user agent to
   opt-in, opt-out, 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.

   Additional extension members may be provided in the status-object to
   support future enhancements to this protocol. A user agent should ignore
   extension members that it does not recognize.

   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

      {
        "tracking": true,
        "received": "1",
        "response": "n",
        "policy": "/privacy.html",
        "edit": "/your/data",
        "options": "/your/consent"
      }

   ISSUE-47: Should the response from the server indicate a policy that
   describes the DNT practices of the server?
   [PENDING REVIEW] The tracking status resource is a machine-readable policy
   and provides a mechanism for supplying a link to a human-readable policy.

   ISSUE-61: A site could publish a list of the other domains that are
   associated with them
   [PENDING REVIEW] The same-site and partners members provide a means to
   list first-party and third-party domains, respectively.

   ISSUE-124: Alternative DNT implementations that replace HTTP headers with
   something else
   [PENDING REVIEW] The tracking status resource minimizes bandwidth usage
   because only a small proportion of user agents are expected to perform
   active verification, status would only be requested once per site per day,
   and the response can be extensively cached.

   5.1.2 Using the Tracking Status

   A key advantage of providing the tracking status at a resource separate
   from the site's normal services is that the status 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. In
   addition, the presence (or absence) of a site-wide tracking status
   representation is a means for testing deployment of this standard and
   verifying that a site's claims regarding tracking are consistent with the
   site's observed behavior over time.

   A user agent may check the tracking status for a given resource URI by
   making a retrieval request for the well-known address /.well-known/dnt
   relative to that URI.

   If the response is an error, then the service does not implement this
   standard. If the response is a redirect, then follow the redirect to
   obtain the tracking status (up to some reasonable maximum of redirects to
   avoid misconfigured infinite request loops). If the response is
   successful, obtain the tracking status representation from the message
   payload, if possible, or consider it an error.

   Once the tracking status representation is obtained, parse the
   representation as JSON to extract the Javascript status-object. If parsing
   results in a syntax error, the user agent should consider the site to be
   non-conformant with this protocol.

   If the status-object does not have a member named path or if the value of
   path is not "/" and not a prefix of the path component for the URI being
   checked, then find the service-specific tracking status resource by taking
   the template /.well-known/dnt{+pathinfo} and replacing {+pathinfo} with
   the path component of the URI being checked. Perform a retrieval request
   on the service-specific tracking status resource and process the result as
   described above to obtain the specific tracking status.

   The status-object is supposed to have a member named tracking with a
   boolean value. If the value is false, then no tracking is performed for
   the URI being checked. If the value is true, then examine the member named
   received to verify that the DNT header field sent by the user agent has
   been correctly received by the server. If the received value is incorrect,
   there may be an intermediary interfering with transmission of the DNT
   request header field.

   If the received value is correct, then examine the member named response
   to see what the origin server has claimed regarding the tracking status
   for this user agent in light of the received DNT-field-value.

   If the first character of the response value is "n", then the origin
   server claims that it will not track the user agent for requests on the
   URI being checked, and for any URIs with a path prefix matching the path
   member's value, for at least the next 24 hours or until the Cache-Control
   information indicates that this response expires, as described below.

   If the first character of the response value is "t", then the origin
   server claims that it might track the user agent for requests on the URI
   being checked, and for any URIs with a path prefix matching the path
   member's value, for at least the next 24 hours or until the Cache-Control
   information indicates that this response expires.

   The remaining characters of the response value might indicate reasons for
   the above choices or limitations that the origin server will place on its
   tracking.

   The others members of the status-object may be used to help the user agent
   differentiate between a site's first-party and third-party services, to
   provide links to additional human-readable information related to the
   tracking policy, and to provide links for control over past data collected
   or over some consent mechanism outside the scope of this protocol.

   5.1.3 Tracking Status Caching

   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 service'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
   service'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 service's
   tracking behavior can be reduced at any time, with or without a
   corresponding change to the tracking status resource.

   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.

   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".

   Regardless of the cache-control settings, it is expected that user agents
   will check the tracking status of a service 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 service.

   ISSUE-90: Interaction of DNT with caching and intermediaries
   [PENDING REVIEW] The tracking status response explicitly controls caching,
   allows the received DNT-field-value to be echoed to the client, and does
   so in the body to reduce accidental loss in transit.

    5.1.4 Tracking Status ABNF

   The representation of a site's machine-readable tracking status must
   conform to the following ABNF for status-object, except that the members
   within each member-list may be provided in any order.

 status-object = begin-object member-list end-object
 member-list   = [ 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 )

 path          = %x22 "path" %x22
 path-v        = string       ; URI absolute-path

 tracking      = %x22 "tracking" %x22
 tracking-v    = true / false


 received      = %x22 "received" %x22
 received-v    = null / string

 response      = %x22 "response" %x22
 response-v    = %x22 r-codes %x22

 r-codes       = ("t" / "n") *reasons
                    

 reasons       = "1"              ; first-party
                 / "3"            ; third-party
                 / "a"            ; advertising audits
                 / "c"            ; prior consent
                 / "f"            ; fraud prevention
                 / "g"            ; geographic/regional compliance
                 / "q"            ; frequency capping
                 / "r"            ; referrals
                 / ALPHA / DIGIT  ; TBD

 same-site     = %x22 "same-site" %x22
 same-site-v   = array-of-strings

 partners      = %x22 "partners" %x22
 partners-v    = array-of-strings

 policy        = %x22 "policy" %x22

 policy-v      = string       ; URI-reference

 edit          = %x22 "edit" %x22
 edit-v        = string       ; URI-reference

 options       = %x22 "options" %x22
 options-v     = string       ; URI-reference

 extension     = object


 array-of-strings = begin-array
                    [ string *( vs string ) ]
                    end-array

 ns            = <name-separator  (:), as defined in [RFC4627]>
 vs            = <value-separator (,), as defined in [RFC4627]>

 begin-array   = <begin-array     ([), as defined in [RFC4627]>
 end-array     = <end-array       (]), as defined in [RFC4627]>
 begin-object  = <begin-object    ({), as defined in [RFC4627]>

 end-object    = <end-object      (}), as defined in [RFC4627]>
 object        = <object, as defined in [RFC4627]>
 string        = <string, as defined in [RFC4627]>

 true          = <true,   as defined in [RFC4627]>
 false         = <false,  as defined in [RFC4627]>
 null          = <null,   as defined in [RFC4627]>

        

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Principal Scientist, Adobe Systems  <http://adobe.com/enterprise>

Received on Monday, 13 February 2012 08:22:25 UTC