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

On Mar 7, 2012, at 12:16 PM, Roy T. Fielding wrote:

> On Mar 7, 2012, at 7:04 AM, Jonathan Mayer wrote:
> 
>> Substantively, then, I think we're *very* close.
>> 
>> I (and, as I understand it, quite a few others in the group) favor a blanket third-party collection/retention/use limitation, with an exception for information that could not be used to correlate browsing activity and an exception for protocol information.  (There are, of course, some fine details we might not agree on.  For example: What does a server have to do if the client sends an old ID cookie?  A "hi, here's my SSN" cookie?  What does a server have to do over time with protocol information?)
> 
> Please understand that those aren't exceptions.  They are contradictions.

If by "contradictions" you mean "exceptions that will get used all the time," then yes.  The analytical framework I've advocated, and that's currently in place in the document, is structured to surface substantive issues and speed progress in the group.  It is not necessarily the way someone approaching these issues for the first time would think about them.

To put that all quite differently: By "exception," I mean a logical carve-out from the general rule.  I don't mean a provision that will be used only exceptionally.

> We cannot protect against fraud and simultaneously blanket-prohibit
> collection.  We can prohibit use for tracking and retention beyond what
> is necessary for the fraud/legal/security exemptions.

I think you may be getting at two ideas here.

First: some information will be collected from browsers that send DNT: 1.  Yes.  Of course.

Second, if I follow your reasoning correctly...
Premise 1: Some exceptions (e.g. fraud prevention) will allow collection and correlation of browsing activity in some scenarios.
Conclusion: We have to focus on use limitations, not collection limitations.

I think that reasoning is flawed; it silently assumes a second premise.
Premise 2: At least one exception will routinely kick in that allows collecting and correlating browsing activity.

I flatly reject that premise; it undermines the privacy control that I believe should be central to Do Not Track.  I will not accept a Do Not Track standard that allows unabated collection of browsing history.  More importantly, three FTC Commissioners, two EC Vice-Presidents, and the Article 29 Working Party will not accept a Do Not Track standard that allows unabated collection of browsing history.

That said, there are many ways of creatively reaching consensus on fraud prevention (and similar issues).  I've had some very productive conversations with advertising participants in the working group about implementing a tiered-response approach to fraud prevention (e.g. if there is good cause to believe an IP address is associated in fraudulent activity, such as loading 100 ads in under 1 second, then an ID cookie, fingerprinting, etc. would all be fair game).

>> That said, as others have expressed, I'd prefer to avoid the quagmire of defining the word "tracking."  The topic has repeatedly proven a waste of the group's time.  I see no need for us to reach consensus on magic words; we need consensus on substance. 
> 
> Given that the protocol is "Do Not Track", this issue has more
> substance then the entire rest of the compliance document.

You've vocally repeated this view for nearly six months.  I, and many others, remain in complete disagreement on the need for a consensus Grand Unified Theory of Tracking.  We're not going to settle that - but, thankfully, we don't have to.

>> One last point.  I thoroughly disagree with what you said here:
>> 
>>> One thing I am quite certain of is that the WG does not have even
>>> the remotest sense of what "we're trying to address", and that goes
>>> for both industry and advocates.  It is remarkable just how far both
>>> sides have been unwilling to address it with actual text, even on
>>> their own websites.
>> 
>> Many stakeholders know exactly what they want Do Not Track to do.  I (and others), in fact, have advocated the substance of what you propose for over a year.  Example: http://tools.ietf.org/html/draft-mayer-do-not-track-00#section-9.2
> 
> You are neither "we" nor the "WG", so it doesn't apply to you,
> nor to "many stakeholders" in isolation, but rather on what we have
> agreed to as a group.
> 
> The comment I made at the IETF meeting in Prague is that your draft's
> definition of tracking is unusable because every server on the planet
> does retention, and use of data related to the request
> and response.  Furthermore, scoping tracking that wide does not even
> remotely correspond to the English meaning of that term.
> 
> The goal of my definition is to find a middle ground between folks
> who think they can deny data collection (even though the server must
> receive the request in order to process it and *will* retain that
> information to combat fraud and security attacks) and those who
> think the discussion must be limited to cross-site tracking by
> third-parties who do not silo by first-party, while at the same time
> providing a solution that will address the consent issue that has
> been demanded by regulators for all parties (not just third parties).

I am all in favor of a middle ground.  I think, substantively, our views have much in common.

Where we differ is in how to achieve that middle ground.  You would proceed by conflating myriad issues into the definitions of "Do Not Track" and "tracking."  I would unpack the issues that the group needs to address, then attain consensus issue by issue with clarity and precision.

> What you should be asking is whether the definition is sufficient
> to address the privacy and consent issues that have been raised and
> discovered by your research, not whether it matches your current or
> past suggested solutions regarding data collection.
> 
> ....Roy
>