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

On Wed, Mar 7, 2012 at 4:21 PM, Jonathan Mayer <jmayer@stanford.edu> 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.
>
> 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).
>


I don't buy the premise that you will be able to detect all sorts of
suspicious activity at the time it occurs and only log 'suspicious'
activity. Many times you discover a fraudulent scheme / party acting
fraudulently, and then you look over your logs to determine the extent of
the fraud and take appropriate action. This implies having logs to look
over.



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