Re: ISSUE-5: definition of tracking

Roy, 

On Wednesday 05 September 2012 11:21:27 Roy T. Fielding wrote:
> On Sep 5, 2012, at 9:04 AM, Rigo Wenning wrote:
> > whether you exclude access logs from the initial definitions
> > or
> > whether you cover them by permitted uses is just a matter of
> > taste.
> No, it is a matter of laws and regulations.  If a company says
> that it complies with the "Do Not Track" signal and the user has
> reason to believe (without reading *any* specification) that it
> means no access log will be retained past the current
> transaction, then the company can be held liable even if the
> specification says retention of the access log is permitted. 
> Fine text cannot overrule common perception when there is no
> expectation that a user will read the fine text (it isn't even
> presented to them as part of the standard, and certainly doesn't
> reflect current UI for the DNT configuration).

You have a funny idea about laws and regulations. If the above were 
true, the entire concept of a DNT protocol would be useless. I think 
not even the FTC follows your argumentation here. Ok, if we admit 
damages for drying the poodle in the microwave oven, we may end up 
with legal angst. 
> 
> The purpose of a single, one or two sentence definition of what
> DNT:1 means (and also what DNT:0 means) is so that it can be
> included in the UI, either directly or via tooltip/documentation,
> and thus become part of the nomenclature that can be reasonably
> understood by the user setting that config.

You can't replace the difficult compromise of the Compliance 
Specification by tweaking the tracking-definition. Privacy is too 
complex to do that. And privacy is not a simple message to the 
consumer. It is a bucket that has a complex meaning, for services 
and consumers alike. A UI wording, as the tokens we exchange, can 
only be representations of a much complexer thing. And if this isn't 
clear, it should be indicated in the Specification to prevent that 
some wild judge can take the Specification for exactly that 
argumentation. (Do we have to cope with the dumbest possible user?)
> 
> Furthermore, it allows us to make progress on the rest of the
> specification with a common understanding of what the
> specification is intended to accomplish, as opposed to what we
> just experienced on the call.

But access logs are just another issue masked in a definition that 
is not granular enough to provide room for compromise.
> 
> > So please do not use the definition for the access log
> > argument. 
> No, we can use fine print to further *restrict* the scope of
> retention, because the user is not going to complain about
> further constraints on what they have already permitted.  We
> cannot use fine print to broaden the scope to allow things that
> do not appear to be allowed by the definition.

How would you restrict something you just declared out of scope by 
definition? I think that doesn't work. 

Rigo

Received on Wednesday, 5 September 2012 19:56:49 UTC