Re: Issue 35 (was Re: Issues for Monday Call)

Note that the privacy property is defined in

   https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.policy <https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.policy>

so that (if not present) the information might be obtained via the links in Controller

   https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.controller <https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.controller>

which itself has a default (if not present) of the site root.  The intent here is that a
server can use its HTTP root resource "/" as the be-all, end-all, full description of
its privacy and tracking policies and not have to send any additional information
in the TSR.  A site can *choose* to separate that information into the various types
of links, but that isn't mandated by TPE because one link is sufficient.

In any case, I don't see how a split is useful in the context of a browser-driven UI.
Sites need to present all cases to all users, since a user might be reading this information
on a separate device (or might have it read to them by another user), might change their
settings after having read it (or while reading it), and might perform related actions
in other windows/tabs while the browser UI remains unchanged.  Moreover, sites
are generally held responsible for adhering to an identified privacy policy whether
or not it has been read by a user, and are sometimes required to re-notify all users
every time any aspect of that policy is changed.

I also don't understand how any browser UI-based consent mechanism is supposed to
work given that the sites are the ones responsible for getting consent, making it revokable,
and perhaps time-limiting its effectiveness.  That's why TPE is designed for consent
being driven by site pages that have no limit to their expressiveness, and why we have
links to resources where a user can manage the consent config:

   https://w3c.github.io/dnt/drafts/tracking-dnt.html#rep.config

As scrappy as that design may seem, I know it will pass muster with legal teams
because it is effectively the same as existing cookie-based consent practices.  If we revisit
the notion that browsers will be governing the UI for consent, everything changes
(including the W3C member patent reviews).

I think we need to be honest about the status of our work and follow the appropriate
process for that status.  Either we have consensus that the current protocol will be
implementable and useful as a recommendation, or we don't. If we don't, then the
right process is to drop out of CR and either stop work or redesign for supporting
implementations.

I'd rather have a bake-off of competing solutions than move forward with an
unimplemented standard.

....Roy

> On Apr 24, 2017, at 10:03 AM, Aleecia M. McDonald <aleecia@aleecia.com> wrote:
> 
> Matthias did not see my text because it was off in github and I sent it very late. Here it is again, then, in full:
> 
> With no standard compliance spec to set a minimum bar, a very common use case for all UIs will be to find a way to present text to users what they consent to when users agree to tracking. A standard hook to do this is both useful and necessary to ensure usability in practice, and address the gaping hole left by shooting the compliance spec. Of course, this also supports US law (AB 370) as well as likely EU law as well.
> 
> Specifically, I propose changes to section, 6.5.8 Policy Property, as follows:
> 
> Change from MAY to SHOULD provide a policy property.
> Either:
> a. Specify that while the exact details are out of spec, the Policy Property SHOULD inform users of what changes between DNT:0 and DNT:1, or
> b. Extend to have two different policy properties, one for DNT:0 and the other for DNT:1.
> (I suspect a is easier for users, and b is easier for implementors. I imagine others will have opinions as to which is better.)
> Additionally, add the following text: User agents implementing Do Not Track SHOULD present this information to users when asking them to make decisions about tracking.
> Of note: this leaves all text in the hands of the companies of how to describe things. It only requires that they do so (as with AB 370) and that they do so in a way that user agents can hook into to make DNT at all usable in practice. This is a mighty low bar.
> 
> ***
> 
> Again duplicative, but the warmest of best wishes to Shane! Fantastic news, and I wish you all happiness in your newly-wed life. Perhaps our spouses can form a DNT support group. :-)
> 
>  Aleecia
> 
>> On Apr 23, 2017, at 8:02 PM, Aleecia M. McDonald <aleecia@aleecia.com <mailto:aleecia@aleecia.com>> wrote:
>> 
>> I’ve submitted https://github.com/w3c/dnt/issues/35 <https://github.com/w3c/dnt/issues/35> in keeping with prior conversations. Sorry I’ve missed the last two calls. 
>> 
>> tl;dr — provide a standard hook for UAs to display to users what they are consenting to when they opt in / opt out. 
>> 
>>  Aleecia