- From: Jonathan Mayer <jmayer@stanford.edu>
- Date: Wed, 26 Oct 2011 00:13:54 -0700
- To: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
- Message-Id: <ECF725EB-D364-487E-B2C5-C14C95D372FD@stanford.edu>
(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 scripts 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 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
Received on Wednesday, 26 October 2011 07:14:24 UTC