Re: Today's call: summary on user agent compliance

Hi Rigo,

On 6/11/2012 3:32 AM, Rigo Wenning wrote:
> Tamir,
>
> we have some logic breaks in the below and that leads to the
> Canadien issue, which is IMHO just an instance of a larger problem.
>
> On Friday 08 June 2012 22:56:20 Tamir Israel wrote:
>> The similarities in regime break down, however, where a server
>> rejects a  DNT-1 (because it was set by default), and there is no
>> alternate mechanism left for the user to opt-out. As the server
>> can no longer rely on implicit/opt-out consent in this case,
>> presumably they can no longer track.
> Again, a protocol can't mean that a service MUST respect the things
> in the compliance specification without having committed to it by
> sending ACK.

You are correct that the obligation to comply with a signal will come 
from [Canadian] law, not the spec. But the manner in which the spec 
defines the validity of signals (as opposed to the scope of signals) 
will make a difference for server implementations and this, in turn, 
will impact on the utility of this DNT mechanism in addressing 
regulatory obligations.

> To get to a situation you describe above in the
> Canadian system, a law would have to oblige services to respect
> DNT:1 and apply the rules of the compliance specification for all
> and every request they get with a DNT:1 header. I can't read that
> into the Canadian law.
>
> One can only come to this conclusion if DNT:1 is only applied to
> online behavioral advertisement by third parties. Roy has urged us
> many times to define tracking in this way and the WG consistently
> refused.
>
> One consequence of this refusal is that a DNT:1 header can be sent
> to almost anything. This would turn off single-sign-on and other
> personalized services. So a service must be able to deny DNT:1 if
> the service would not make sense in the DNT:1 - mode.

Food for thought. Offhand, I think the concern I was expressing was not 
that servers should be obligated to respect all DNT-1 signals regardless 
of /scope/. Rather, my concern was that they can reject facially valid 
DNT-1s solely on the basis that they do not deem them to be valid in 
contexts where consent is required.

But let me think about this some more....

> Additionally, the right to opt-out does not create a right to
> receive the content. So in a Canadian context, if a service does not
> offer an opt-out, it can still deny content delivery. What a service
> wouldn't be able to do is to just continue tracking as if nothing
> happened.

This is an interesting question. It is not clear how this would work on 
a site by site case (and I understood the site-specific exceptions might 
be designed to handle such exceptions, but I will take a closer look). 
The OPC did make clear in their guidelines that obligating users to 
consent to online tracking "should not be considered a term or condition 
for individuals to use the Internet generally. There are still other 
forms of advertising that web sites can rely on". I had understood the 
FTC's writings on this to be along the same lines.

> Now if a user has sent DNT:1 and the service responds with NACK and
> the user continues to use that service, the service can reasonably
> assume that the user has implicitly agreed not to opt out. If the
> user still sends DNT:1 headers, the OPC has to decide whether it
> wants the service to trigger an exception in the face of the user to
> stop the non-interaction of two blind-deaf DNT implementations.
>
> Which brings me to the point (which ISSUE should I attach it to?)
> that a compliant user agent SHOULD NOT resend a request with DNT:1
> to a URI after having received an NACK. (Some may want to prompt the
> user, others will find better solutions)

I'm not sure this is the solution. The OPC's guidelines make it clear 
that there has to be an effective, readily available opt-out mechanism 
in place before the server can rely on opt-out consent. The fact that 
the server denies a UA's DNT-1 /on the basis that it deems the signal 
invalid /(not on the basis of scope) and lets the UA know this -- this 
would not amount to consent, so servers will still lack a mechanism for 
achieving consent in this particular context.

Best regards,
Tamir