Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNT:1 extension for audience measurement (EU ePR) #65

Open
rvaneijk opened this issue Oct 20, 2017 · 5 comments
Open

DNT:1 extension for audience measurement (EU ePR) #65

rvaneijk opened this issue Oct 20, 2017 · 5 comments

Comments

@rvaneijk
Copy link
Contributor

We should take the EU use case for a web wide opt-out for the purpose of audience measurement (aka web analytics) into account. We discussed the opt-out on many occasions, e.g. the global considerations taskforce in Berlin (2013). The current development is that the approach for web analytics is a carefully balanced one. The text of the LIBE compromise amendments for the ePR is as follows:

Article 8
Protection of information transmitted to, stored in, related to, processed by and collected from users’ terminal equipment

The use of processing and storage capabilities of terminal equipment and the collection of information from users’ terminal equipment, including about its software and hardware, other
than by the user concerned shall be prohibited, except on the following grounds:
(...)
(d) if it is technically necessary for measuring the reach of an information society service requested by the user, provided that such measurement is carried out by the
provider or on behalf of the provider, or by a web analytics agency acting in the public interest including for scientific purpose; that the data is aggregated and the user is given a possibility to
object; and further provided that no personal data is made accessible to any third party and that such measurement does not adversely affect the fundamental rights of the user; Where audience measuring takes place on behalf of an information society service provider, the data collected shall be processed only for that provider and shall be kept separate from the data collected in the course of audience measuring on behalf of other providers; or
(...)

See also the thread on public-tracking-comments: https://lists.w3.org/Archives/Public/public-tracking-comments/2017Oct/0022.html

@rvaneijk
Copy link
Contributor Author

Dear Kim,
Thank you for the response. The referenced documents do not contain any technical solution. Is there any effective opt-out solution we can have a look at?

@rvaneijk
Copy link
Contributor Author

Great, tnx for the feedback. Please note that in my view there are two kinds of opt-outs; web-wide and site-specific opt-out. The current TPE can already express web-wide opt-out DNT:1 by sending it to webwide.com whenever, e.g. a pixel is loaded from it, assuming it’s not the top-level resource.

If a-publisher.com provides an site-specific opt-out for the purpose of web analytics through DNT, I think the tracking protection working group should think through the use case further. A possible path forward is to extend the API, e.g., storing a user requested opt-out for webanalytics.com on sitespecific.com.

@michael-oneill
Copy link
Collaborator

We could extend the API to be able to specify the header in the UGE store call, i.e. a DNTVal string property as suggested in issue #6. This could also meet some of the requirements for issue # 60.

It would let a first-party specify the header to be received (either itself web wide, or site specifically by targeted sub-resources). The DNTValvalue would be parsed in the storeTrackingException handler, and the UGE rejected unless either:

  1. It simply contains the value "1", or
  2. It contains a value of the form "0&p={any UTF8 string}", where anything after the first "0" is optional.

The first form is for registering DNT:1 in the case that the DNT general preference was unset, to indicate objection to web audience measurement (web-wide or site-specific)

The second form is for registering purposes as per Issue #60

After the first character (0 or 1), the value is structured as a list of zero or more attributes as name-value pairs separated by "&", which is a widely used convention for encoding cookie values. We only specify the "p" attribute for now, but other extensions could be supported in future and this format would allow them to be contained in the header in any order.
A zero length attribute list would simply consist of "0", which would also be the default if the DNTVal property was null or undefined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@rvaneijk @michael-oneill and others