RE: Moving "C"onsent from Tracking Status to Permitted Use?

Hi Ronan,

 

A web-wide exception for a panel member would only take one visit to a site
with the same domain, or redirects through the same domain, as your 1x1 gif.
The DNT:0 signal is persistent, and only removable via user's explicit
action so there would be no change necessary to the publisher's site or need
to use an external library.

 

The web-wide exception is transparent and always under the control of the
user who can revoke it through their browser UI. An undefined out-of-band
mechanism cannot do that, and would be too open to being misused. Surely it
would be better to rely on the in-band mechanism to differentiate yourself
from your less respectable competition?

 

 

Mike

 

 

 

From: Ronan Heffernan [mailto:ronansan@gmail.com] 
Sent: 29 March 2013 11:25
To: Mike O'Neill
Cc: Matthias Schunter (Intel Corporation); public-tracking@w3.org
Subject: Re: Moving "C"onsent from Tracking Status to Permitted Use?

 

[Summarizing some off-list back-and-forth with Mike O'Neill:]

I do not think that OOBC is going to be a "transitory mechanism".  The
in-band exception API will not be usable in a great many cases.

For every publisher (major website operator), we have to ask if they will
allow us to send JS to browsers when we are a 3rd party on their site.  Some
providers, especially major providers, tell us "No".  In that case, we have
to use image-based content, not JS-based content.  That disallows  a few of
our advanced features, and will prevent any JS-based API interaction.  I
understand their position; if I ran a major website I would be wary of
allowing 3rd parties to inject JavaScript that could screw-up the appearance
or otherwise degrade the user experience on my site.

We will also not be allowed to "link-off" to another page to get consent.
Publishers will not want *their* users leaving *their* site to go grant/deny
exception to third parties.  If there is a control link or request for
consent in the HTTP header, and that control link or question is going to
trigger a UA popup (or other on-screen element), we will be forbidden by
most major publishers to exercise that feature.  They didn't spend hundreds
of thousands of dollars designing a beautiful (and "sticky") website to have
a bunch of 3rd party user-interaction destroy the user experience.  The
popups will scare uninformed users and destroy the aesthetics of the
site/visit for other users.  So in reality, on most major websites, research
companies and other third parties will never get the opportunity to exercise
the in-band consent mechanism, or even declare their existence in any way
that will result in major UAs putting anything in the user's face. We will
have to operate without being able to interact with users.

One important solution to these problems is OOBC.  

--ronan



On Thu, Mar 28, 2013 at 9:40 AM, Mike O'Neill <michael.oneill@baycloud.com>
wrote:

I think this also solves Adrian's use case, as far as I understand it,  of
establishing consent across devices, i.e. by a user clicking a link in an
email.

If the server can recognise it has OOB consent for this user (using a cookie
probably or a unique URI ) then it can convert it in-band as soon as it can.
i.e. by calling the API if the response is HTML or encouraging the user to
go the domain as a 1st party. There will need to be a way to get round
third-party default blocking (which is becoming the norm) and the consent
API is the best way to do that. OOB response headers might not be good
enough, except for the first time, because it is not as transparent or as
simply revocable.

There should be non-normative text recommending this so OOB consent is
positioned as a transitory mechanism rather than a replacement for the API.

Mike