Delivering Tk response via meta tag, and extending it to contain a reference to the TSR

[michael-oneill]

Tracking Status Resource in the Tk Response Header and delivering it via a meta http-equiv tag

Organisations sometimes have to manage several, perhaps thousands, of websites, often developed and maintained by marketing agencies and other contracted parties. Logistically it can be difficult to manage the multiple servers run by these disparate parties in a coordinated way.

An example of where this is required is delivering a Tk response header, especially when the out-of-band consent (OOBC) mechanism must be used. If a user's browser does not support the DNT Exception (Consent) API then the server must determine from the request if tracking consent has been given by that user, before inserting the correct Tk response header. This will in most cases involve looking up the value of an authentication cookie in an external database, and the code to do this would have to reside in the server, and it, or its underlying logic, would have to be shared among the different parties.

Another example is the delivery and maintenance of the Tracking Status Resource at the "well known" location. Every origin would have to contain a reference (at /.well-known/dnt) to the current resource, which may have to be maintained by the company's legal or data protection function.

While it is possible in the current TPE to target any URI as the declared Tracking Status Resource using a chain of HTTP Redirects, getting all a company's servers to initiate the correct server-side redirection code can be difficult.

Both of these issues could be addressed by explicitly allowing the delivery of Tk responses within the returned HTML content, and communicating an alternative TSR URI within the response. It is relatively easy to supply a JavaScript library reference to be inserted in every HTML head-section, and this is a well understood industry practice.

This mechanism would only take effect in situations where an origin server did not return a Tk header, and where it did not already return a well formed JSON resource to a GET to /.well-known/dnt.

This proposal calls for the ability to specify the Tracking Status Resource within the value of the Tk response header, and be able to declare any Tk response header in an HTML head section using a meta tag with the standard http-equiv attribute.

In future there is likely to be a standardised policy resource for an entire origin (e.g web site) where security and policy oriented headers can be declared. The motivation for this is managing the "header bloat" issue arising from new recommendations such as Content-Security-Policy. It would make sense to append the Tracking Status Resource to this, and incorporating a reference inside a header is a natural way to do it. If every site must have a set of cached origin-wide resources it would be best to combine their functionality so only one extra round-trip was needed, and to minimise the size of the cache.

A valid URI after a "%" character in the Tk header will be construed as a valid Tracking Status Resource, unless a valid resource is also located at {origin server domain}/.well-known/dnt, in whch case that resource is taken as the only valid one.

If a Tk response header exists the meta tag is ignored. If a Tracking Status Resource exists at {origin server domain}/.well-known/dnt then any "%" component of any Tk response , in a header or in the HTML, is ignored.

The new Tk response header is defined formally by the following ABNF

            Tk-field-name  = "TK"
            Tk-field-value = TSV [ ";" status-id] [ "%" URI-reference]
            status-id =  1*id-char
            id-char =  ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
            URI-reference is defined as per [[RFC3986]]
         

Tk response header via meta tag

The server MAY supply a Tk response via an HTML [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) elements with [http-equiv](http://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv) attributes that are an ASCII case-insensitive match for the string "Tk". For example:

<meta http-equiv="Tk" content="N">

<meta http-equiv="Tk" content="C%https://corporate-site.com/.well-known/dnt">

Add the following entry to the pragma directives for the [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element:

Tracking response (`http-equiv="Tk"`)

1. If a Tk response header exists abort these steps.
2. If the Document’s [head](http://www.w3.org/TR/html5/document-metadata.html#the-head-element) element is not an ancestor of the [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element, abort these steps.
3. If the [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element lacks a [content](http://www.w3.org/TR/html5/document-metadata.html#attr-meta-content) attribute, abort these steps.
4. Let trackingResponse be the value of the [content](http://www.w3.org/TR/html5/document-metadata.html#attr-meta-content) attribute of the [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element.

Authors are strongly encouraged to place [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) elements as early in the document as possible, because policies in [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) elements are not applied to content which precedes them.

Note: Modifications to the [content](http://www.w3.org/TR/html5/document-metadata.html#attr-meta-content) attribute of a [meta](http://www.w3.org/TR/html5/document-metadata.html#the-meta-element) element after the element has been parsed will be ignored.

[npdoty]

@michael-oneill will separate into two issues (http-equiv; and use of meta elements or combining with other origin policy)

[michael-oneill]

This issue has been split following our call on 30/11/2016 There are now 2 new issues 10,11