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

Most users *never* visit our website directly (a common problem), and when
they arrive, if they are able to refuse an in-band exception, despite
having granted an out-of-band exception, then we must be able to rely on
the out-of-band exception.  We will also not be able to even query the
exception API, for a large portion of our hits, since JS will not be
allowed by the publishers.  That entire mechanism is basically useless for
us.  If it works for some sites, that's great; but I am fairly certain that
we will have to rely on out-of-band exceptions.

BTW, unless the spec is going to mandate a common per-machine repository
for exceptions, you will have a problem of different User Agents on a
machine having different sets of granted exceptions. It is not really "one
visit" to set the exception(s); it is at least one visit per UA profile.

--ronan



On Fri, Mar 29, 2013 at 8:40 AM, Mike O'Neill
<michael.oneill@baycloud.com>wrote:

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