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