Re: ISSUE-5: What is the definition of tracking?

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.