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

Thanks Kevin. We agree and think this approach would have the greatest chance at success.  With these clean lines of distinction, more companies could quickly implement it. Also, it would be more easily understood by the general public.



On Dec 9, 2011, at 7:26 PM, "Kevin Smith" <kevsmith@adobe.com<mailto:kevsmith@adobe.com>> wrote:

I would like to revisit a previously and hotly debated subject.  It has been brought up and shelved many times, but I believe it is still the core stumbling block to our efforts to progress.

We have the definition (which I grossly abbreviated here):
Do Not Track (DNT) = Do not track or target this user in any way except according to a list of well-defined (but yet to be determined) exceptions – the foremost of which is that a 1st party may track regardless of the presence of a DNT header (within some limitations).

An alternative suggestion that I believe is in alignment with the majority of the TPWG member’s opinions could be:

Do Not Cross Track (DNXT henceforth) = Do not share or track data across unaffiliated non-commonly branded sites – again with possible exceptions.  In this case, exceptions would be much simpler as this would apply equally to both 1st and 3rd parties as neither are allowed to cross track – all exceptions would be true exceptions to when cross tracking is permissible)

The confusion I see in almost every thread is that we *all* say DNT when *most* of us mean DNXT.  In fact, we actually start with DNT but then via an extensive use of increasingly complicated exceptions we change the definition of DNT to mean DNXT and not refer to DNT at all.  This adds a great deal of complexity to all of our decisions.  It’s no wonder that new participants and media alike are so confused by much of the existing conversations.  I believe this discrepancy complicates nearly every issue and is the source of many of the cyclical arguments that seem to constantly bog us down.

The most obvious consequence of this approach is the considerable focus it places on the differences between 1st and 3rd parties.  This subject has come to nearly monopolize the majority of our discussions and frequently prevents progress from being made.  The need to define every aspect of a 1st or 3rd party and how they react and the communication between them and how one can turn into the other and how to identify what service is what party and when, and the concern that 3rd parties will find ways to consider themselves 1st parties … all come from the fact that we have stated that a 1st party can track you when a 3rd party cannot.  I believe that was simply a way of backing into DNXT – preventing cross tracking.  What if we drastically simplified everything by simply saying tracking and targeting is only prohibited when done across sites (non-same-branded etc etc).  This would mean that both 1st and 3rd parties could record things about the visitor as long as it is kept siloed in the context of the site they are visiting.  One may argue that they do not want a hidden service such as a DSP recording anything about them, but I suggest that if those 3rd party services cannot connect your activities to your activities on other sites or use that data outside of the context of the original site, they have very little incentive to collect it under their current business models.  And if they alter their business models such that they can provide value in the context of the original site, than they would be behaving very similarly to what we have defined as 1st party outsourcing or 3rd party as a 1st party.

For example, we have spent some time discussing widgets and how well they have to be branded or how much interaction is required to consider them a 1st party (ie a weather widget or google maps etc).  This is all unnecessary complexity.  It does not matter what party the widget is.  Under DNXT it cannot cross track.  I don’t think there would be a ton of concern if google or the weather widget in the examples discussed only tracked you in the context of the site on which they are embedded.  For instance, google could remember your zoom level or the coordinates to which you panned, and the weather site may default to the zip code you entered.  Nor do I see a problem if the weather widget records that it received a hit on site X from a user in zip code Y for the purposes of better understanding their audience and which sites drive better engagement.  I think the widget ought to be able to record details like this regardless of user interaction, and even if the widget is below the fold and never actually seen.  The possible privacy concern occurs if that weather widget which is embedded in many different sites connects the data it records to a non-siloed visitor id and uses the data collected across those sites to create a profile tracking individual’s surfing patterns, user interests, etc.  Hence, the concern is not whether they are a 1st or 3rd party or even whether they are tracking, but rather whether they are using data outside of the context in which it was collected and connecting data from multiple contexts to a single user.

I see three main problems caused by using an exception based DNT rather than DNXT:

1.       Standards do not match the intuitive expectations that it sets – I know we have talked about it – but the name just does not match the intent.

2.       Confusion between those in the group that think we are trying to solve DNT (and perhaps that we should solve DNT), when in reality most of us are trying to solve DNXT.  This leads to many cyclical arguments and much revisiting in areas where we thought we had consensus.

3.       Both our documentation and our discussions are much more complicated than they need to be since both the definition of what we are try to accomplish is so heavily exception based.  We are currently investing so much of our efforts in defining every aspect of the different parties rather than actually focusing on defining how DNT (or DNXT) works.

Here is a quick list of the subjects that I think either go away, or are significantly simpler if we take the DNXT approach:

·         Issue 2: What is the meaning of DNT header?

·         Issue 5: What is the definition of tracking?

·         Issue 9: Understand all the different first- and third party cases

·         Issue 10: What is a first party?

·         Issue 17: Data use by a 1st party

·         Issue 19: Data collection / Data use (3rd party)

·         Issue 26: Providing data to 3rd party widgets – does that imply consent?

·         Issue 41: Consistent way to discuss tracking with users

·         Issue 49: 3rd party as 1st party

·         Issue 50: Are DNT headers sent to first parties

·         Issue 51: Should 1st party have any response to DNT signal

·         Issue 54: Can first  provide targeting based on registration information even while sending DNT<http://www.w3.org/2011/tracking-protection/track/issues/54>

·         Issue 59: Should the first party be informed about whether the user has sent a DNT header to third parties on their site?<http://www.w3.org/2011/tracking-protection/track/issues/59>

·         Issue 60: Will a recipient know if it itself is a 1st or 3rd party?<http://www.w3.org/2011/tracking-protection/track/issues/60>

·         Issue 66: Can user be allowed to consent to both third party and first party to override general DNT?<http://www.w3.org/2011/tracking-protection/track/issues/66>

·         Issue 73: In order for analytics or other contracting to count as first-party: by contract, by technical silo, both silo and contract<http://www.w3.org/2011/tracking-protection/track/issues/73>

·         Issue 77: How does a website determine if it is a first or third party and should this be included in the protocol?<http://www.w3.org/2011/tracking-protection/track/issues/77>

·         Issue-89: Does DNT mean at a high level: (a) no customization, users are seen for the first time, every time. (b) DNT is about data moving between sites.<http://www.w3.org/2011/tracking-protection/track/issues/89>

·         Issue-91: Might want prohibitions on first parties re-selling data to get around the intent of DNT<http://www.w3.org/2011/tracking-protection/track/issues/91>

·         Issue-94: Is “Do Not Track” the right name to use?


I also collected a few examples from our recent email threads which demonstrate the amount of confusion which I attribute to this issue.  However, adding those in made this already novel-length email look like The Lord of the Rings trilogy so I left them out.  But if anyone is interested I could post a few.

In summary - I know that the group is fairly split on the issue but that many believe changing terminology is not even an option because of previous investments, implementations, and definitions made by various parties and the existing level of community understanding around the term DoNotTrack.  However, as I have watched media response, the reactions of new group members, and even interaction between those of us that have been involved since day 1, it has become increasingly obvious to me that we will not be able to realize the theoretical benefits offered by matching existing terminology, because we are not matching the expectations associated with them.  Rather, it seems clear that those same preconceived notions and 3rd party investments will remain a millstone around our necks thwarting our progress continually.  Note: I am not talking about the Header syntax – that can remain DNT or XYZ or anything else, I am however saying that we should start referring to the setting, contextually at least, as Do Not Cross Track, and I believe this single change will simplify a great many of our existing issues and reduce the # of times we end up revisiting the same arguments (not counting this one of course :))