- From: Sean Harvey <sharvey@google.com>
- Date: Mon, 24 Oct 2011 14:12:29 -0400
- To: "public-tracking@w3.org Group WG" <public-tracking@w3.org>
- Message-ID: <CAFy-vuf8kopC-uC3Sjk0ZEQZ6QzNDcjM_+HbJ1ZgtnSHXKJydw@mail.gmail.com>
This is a really constructive conversation and I’m doing my best to keep abreast of it so that we can properly reflect it in the strawman doc with Justin & the chairs. I have a couple of thoughts about things I think we should consider that I want to add briefly. Defining tracking is trickier than one might think, and we should be attuned to the long-term ramifications of whichever approach we take. Currently we’re focused on exception use cases and the temptation is to essentially define “tracking” as “everything but x”. Should we continue with this approach there are two issues we need to be aware of: 1. This will sound slightly pedantic, but the danger of forgetting something obvious or basic in the list of exceptions, for example referrer URLs have been mentioned, and there are other obvious examples of data sharing cross-site: HTTP headers, TCP/IP handshakes, etc. These are examples of cross-site data sharing with your browser that do not uniquely identify you to the server you’re interacting with (though the issue of uncommon http headers was briefly raised by EFF), but are data sharing nonetheless. I think it’s therefore important to add definitionally that we are talking about pseudonymous (or personal) identification of an individual, an individual browser instance, or an individual device for some business or other purpose. 2. The other danger of an exceptions-based definition of “tracking” is that it is highly restrictive of future business models in potentially unpredictable ways. Two years ago we would not be considering definitions of “first party” that may or may not include embedded video content from YouTube or like buttons from Facebook; and it is possible that we would have collectively written an exceptions-based standard that didn’t work very well in this new landscape. It’s therefore worth at least discussing if we want the definition to identify what we are trying to address outside the context of the exceptions – NOT that we make the same mistake on the other end by creating a harms-based definition, but that we quantify the harms we are trying to address and tailoring our definition of tracking to them to a degree. 3. The dialogue on the Issue 5 email chain has only sometimes reflected one of the important conversations we had in Cambridge, and that was that cross-entity data sharing is a more foundational concern than the first/third party distinction, which is really just an imperfect short cut to the former. My opinion at this stage (though I’m certainly open to persuasion) would be that we need to note the following issues here: · Should first parties be exempted only to the extent that they do not combine their data with individual-level data from third parties? If I’m a first party and I see a DNT header, should I still be restricted from adding data collected from a DNT-passing customer to individual-level data from an offline third party company’s database? Should I be allowed to append it or combine it with data collected with individual-level offsite data I have purchased? · By the same token there are instances where a "third party domain" is used by a publisher as a software tool for analytics or ad serving. If that third-party tool is combining data from multiple sites, then obviously that falls under the definition of “tracking”. But what if it is merely a software tool for the first party’s use only & the first party is the sole data owner? In this instance it is probable that the third party software tool is "first party" under the current DNT definition options, which again emphasizes we are focused on cross-site data sharing rather than the first/third party distinction.
Received on Monday, 24 October 2011 21:10:44 UTC