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

Jonathan, 

you start from the following definition:
Example: http://tools.ietf.org/html/draft-mayer-do-not-track-00#section-9.2 
where it says:
Tracking includes collection, retention, and use of all data related to the 
request and response

This definition even goes beyond personal data or it assumes that all IP 
traffic is personal data and looks at a single HTTP interaction as its 
limitation. Seen from such a standpoint, the all encompassing definition isn't 
providing any lines and edges. Logically, this is fine. We define a scope by 
saying all traffic data. Now we have defined our set and from here we define 
the items that we put out again. By this way, you have defined a general 
prohibition of processing of data with exceptions in the context of the HTTP 
protocol. This goes WAY beyond any definition in the EU that only addresses 
personal data. This means you just moved _everything_ into the regulated 
domain and now you have to cover _everything_ needed by an exception. Because 
otherwise it will fall into the general prohibition. This also means that the 
things not predicted will fall into the general prohibition which is a reason 
to get serious liability and IT security concerns. 

The EU system avoids this by limiting its restrictions to "personal data" as 
other data is not covered by the protection goals set by the European 
Convention on Human Rights Art.8. (Privacy). If there is no "person" attached 
to the data (identifiable!), there is no need for protection => out of scope. 
Here the default points to processing permission. 

We have to carefully chose the field where we want the default to point to a 
prohibition of processing of personal data to cope with the fortuity of life. 
If we only allow what we know, we are completely immobilized by our own rules. 

The ePrivacy Directive has to depart from the Definitions of the data privacy 
directive (95/46EC) and can't just define traffic data as not relevant. 
Relevant is personal data. But what the ePrivacy Directive does is giving a 
blanket permission for the processing of data for security, billing and fraud 
protection etc (look at Art. 4 where it calls for the implementation of 
security features and monitoring is one of those)

But in light of the above, having all data collection being  "tracking" and 
now making a security exception is reducing the freedom for security and fraud 
protection to the rules allowed by the Specification. As the ePrivacy 
directive even calls for that security, I see no harm in saying the data 
collection for security is not "tracking". 

And Roy, saying "everything is tracking" and then saying "security and fraud 
prevention is allowed", thus having broad blanket exceptions, may come 
functionally close to what you try to achieve. Because the blanket exception 
would also cover the unknown future cases. Do we know already now what the 
latest trick is in agent based intrusion detection? What data they have to 
collect?

And, Jonathan, I agree with your concern that "security" could be 
misunderstood as a figleaf to continue collection like before under a 
different flag. But wait, that is covered in Roy's definition and in the 
compliance document as under DNT=1 it couldn't be used for other purposes. 

What remains is a dispute about a general data minimization principle that is 
actually a good idea, part of the EU regulation, but goes beyond what we are 
chartered to do and is IMHO reserved to the regulator to establish. To the 
industry I can only say that data minimization is sparing money and making 
your services more efficient. But all this is IMHO beyond the field of DNT. 

So I still like Roy's definition as it does the trick.

Both of you should note that collection is not retention, respectively. There 
is a good reason to treat them differently. I can spell that out if you want.

Did that help? If not, lets phone..

Rigo




On Thursday 08 March 2012 12:32:45 Jonathan Mayer wrote:
> Rigo,
> 
> I don't follow - could you please try rephrasing?
> 
> Thanks,
> Jonathan
> 
> On Mar 8, 2012, at 12:26 PM, Rigo Wenning wrote:
> > Jonathan, Roy,
> > 
> > On Wednesday 07 March 2012 12:16:50 Roy T. Fielding wrote:
> >>> 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. 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.
> > 
> > IMHO, your dispute here is a red herring. If even the ePrivacy Directive
> > allows for protocol chatter for security  and normal  interactions, we
> > shouldn't go beyond that here. See Article 6 Jonathan:
> > http://eur-
> > lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2002L0058:20091219:EN
> > :HTML
> > 
> > So the best is the enemy of the good here. I still think we can reach
> > consensus on a definition.
> > 
> > Rigo

Received on Thursday, 8 March 2012 21:46:20 UTC