issue 11

Following today's call, I put the following up as a comment to issue 11

On the call today we discussed using meta http-equiv tags for supplying the
Tk response header, and also the difficulty some sites have implementing a
TSR at the well-known location. These issues are connected because the only
way to to set the {status-id} to indicate a page-specific TSR is with the Tk
response. In addition, when the API is not supported, user consent (if it
has been obtained) must be indicated using the out-of-band mechanism. This
means that a TSV of C must be delivered either in the Tracking property of a
dynamically updated TSR or in a Tk response header.

This is more than just an edge case. It is hard for large companies with
multiple (first-party) sites to specify a set of common rules for a
potentially legally significant TSR, especially when it must be dynamically
created. Sites are often implemented on different platforms by disparate
agencies and service providers, and synchronising these would be a logistic
nightmare. Also, many smaller sites are often hosted by a centralised
service provider that does not offer easy or standardised methods for
setting response headers, or allows their customers to host their own TSRs.

My original proposal combined these issues by extending the Tk header so it
could carry the URI of an independently located TSR, and allowing the header
to be sent in the head section of an html document in an http-equiv tag.

This would allow a first-party site to generate its own Tk: C as well as its
own page-specific TSR without the need for the {status-id} mechanism. It
would still have to ensure that the “Tracking” property and TSV in the TK
header were the same, leading to possible ambiguities. There would also have
to be a redundant roundtrip in many circumstances just to return the TSR.

In the call Roy suggested a simpler approach which I agreed with.

This would be to not bother with the Tk header but only return the TSR JSON
directly in a meta tag. There would only be one TSV (in the encoded TSR),
and the whole TSR would be immediately available without needing an extra
roundtrip.
Remember, this is only required in the cases that a TSR at /well-known/DNT
is not available. If it is this mechanism would just be ignored. This makes
the assumption that if a site can host a well-known TSR it can also generate
a TK header.
This mechanism allows sites to dynamically place the following meta tag in
the head section of any page that needed to comply:

<meta name=’tracking-status-resource’ content=’{“tracking”:”C”,
“compliance”=” http://eur-lex.europa.eu/eprivacy-regulation”,...}’ />

This is simpler and more efficient that the last proposal, does not have the
ambiguities, and fixes both use cases.


https://github.com/w3c/dnt/issues/11#issuecomment-279509720

Received on Monday, 13 February 2017 20:25:58 UTC