W3C home > Mailing lists > Public > public-tracking@w3.org > March 2012

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 7 Mar 2012 22:17:29 -0800
Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
Message-Id: <8B46ECAA-5D8E-464B-A3ED-463E091BB883@gbiv.com>
To: Jonathan Mayer <jmayer@stanford.edu>
On Mar 7, 2012, at 4:21 PM, Jonathan Mayer wrote:
> 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.

And as I already pointed out in the case of outsourcing, it leads to
contradictions in the spec that make it unimplementable in practice.

>> 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.

As I am sure you are aware, when the commissioners talk about collection
it is referring to what you defined as retention.  The proposal I have
made does not in any way allow unabated collection of browser history,
nor can it override any of the existing or future regulations that might
apply to such an activity.  I am assuming that the exemptions will be
defined by this WG in a way that limits such retention, just as in
the example I gave regarding frequency capping.  If we can't figure
out a way to do that, then the specification will not be implemented.

> 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.

You don't have to.  I do.  I will not tolerate a W3C recommendation in
which two people in the same WG can't even have a conversation about
what it means because each are using the same term to mean two entirely
different things.

....Roy
Received on Thursday, 8 March 2012 06:17:59 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:26 UTC