W3C home > Mailing lists > Public > public-tracking@w3.org > October 2011

Re: Summary of Options for 1P Learning of 3P DNT Status

From: イアンフェッティ <ifette@google.com>
Date: Sun, 30 Oct 2011 23:38:47 -0700
Message-ID: <CAF4kx8e-YAsacLM_LmLcM8HzeR5-1b1dOXrQLz5iYfOFgAO_pA@mail.gmail.com>
To: Jonathan Mayer <jmayer@stanford.edu>
Cc: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
Reply inline.

On Wed, Oct 26, 2011 at 12:13 AM, Jonathan Mayer <jmayer@stanford.edu>wrote:

> (ACTION-18, ISSUE-59)
>
> There are at least three technical approaches for a first party to learn
> of a third party's Do Not Track status.
>
> 1) The third party notifies the first party through inter-frame
> communication (e.g. postMessage or fragment identifiers).  An example is
> available at http://donottrack.us/cookbook/, under the heading "Request
> Consent - Tracking by Others on This Site."
>
> Benefits:
> -Requires no modifications to browsers
> -Can integrate with any approach to opt-back-in
>
> Drawbacks:
> -Adding support requires trivial (and standardizable) changes to first-
> and third-party
>

For some of these (e.g. postMessage) you don't know if you can log the
event until potentially after you've served the event. That is very
nontrivial. As for fragment identifiers, these aren't sent by the browser
to the server, so you still rely on some script to essentially tell the
server after-the-fact if it can log the request it just serviced. Both of
these are show-stoppers.


>
> 2) The third party notifies the first party through backend communication.
>  For example, the the first and third parties share a unique session
> identifier, and the first party makes a RESTful call to the third party.
>
> Benefits:
> -Requires no modifications to browsers
> -Can integrate with any approach to opt-back-in
>
> Drawbacks:
> -The first and third parties have to establish a shared identifier, add
> support for a backend protocol, and do realtime backend data sharing
>

Again, this is a nightmare to figure out in a way that would not affect
latency while still having the knowledge of whether it's first or third
party at the time of the request.


>
> 3) The browser provides a Do Not Track status API that the first party
> could use.
>
> Benefits:
> -Simple for first parties to develop against
> -Imposes no requirements on third parties
>
> Drawbacks:
> -Requires modifications to browsers
> -Requires browsers to keep track of opt-back-in status
> -Makes browsers more fingerprintable
>

- Drawback: You are still relying on script, and don't know if you can log
the request at the time that you service the request.


In short, none of the above solutions seems workable from my viewpoint.
Received on Monday, 31 October 2011 06:39:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:41 UTC