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

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

From: Jonathan Mayer <jmayer@stanford.edu>
Date: Thu, 8 Mar 2012 00:45:28 -0800
Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
Message-Id: <87436CB3-F795-4E74-8F6C-14542CDCF8CC@stanford.edu>
To: Roy T. Fielding <fielding@gbiv.com>
Roy,

I've written some thoughts below.  I don't believe it would be productive to focus further on your proposal.  Admirable as your aims were, the conversations on specifics have grown increasingly confused on all sides.  If there are specific issues you'd like to follow up on, please draw them out individually.

Jonathan

On Mar 7, 2012, at 10:17 PM, Roy T. Fielding wrote:

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

If by "contradiction" you mean logical inconsistency, I sure don't see any.  If by "contradiction" you mean "striking a balance between user privacy and economic benefits," then absolutely.

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

With the caveat that I don't, of course, speak for any policymaking individual or organization: I don't believe you accurately characterize the views of many leaders in the field.  There are, broadly, two ways in which a website might learn information from a browser: "active collection," where the site goes out of its way to learn from the browser (e.g. cookies, fingerprinting), and "passive collection," where the site receives protocol information by virtue of HTTP, TCP, IP, etc. traffic from a browser.  The present view among many top policymakers, as I understand it, would consider all "active collection" a form of "collection."  There is some uncertainty on whether ephemeral "passive collection" would be "collection."

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

To clarify, let me use the "active collection" and "passive collection" terminology.

I would object to any proposal that allows routine active collection of a user's browsing history, and that does not impose significant retention limits on passively collected browsing history.

I think your proposal trends in that direction.  But given that you've manage to confuse a sizable share of the working group, I'm not planning to dwell on it further.

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

If you insist on having some definition of the term "tracking" in the document, that's easy.  We could either affix the label to the headline no-collection/retention/use rule (the approach in the Internet-Draft), or we could attach it to whatever the standard substantively prohibits (example: "'Tracking' encompasses any practice that is prohibited by this specification.").

If you insist on having metaphysical agreement on what the magic word "tracking" means, that's completely unnecessary.  

> ....Roy
> 
> 
Received on Thursday, 8 March 2012 08:46:02 UTC

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