Re: issues and questions in the latest TPE draft

On Aug 22, 2012, at 12:15 PM, David Singer <singer@apple.com> wrote:
>> Finally, section 6.7 includes non-normative language that states that UA's may implement exception management as they see fit, and gives an example of a UA prompt to allow a requested exception. Although this is non-normative, I have concerns about the impact. In my view, the requesting party (i.e. the publisher) should control the messaging of the request, and the UA should provide only a simple yes/no confirmation. The example given will create a terrible user experience, as the user will be presented with multiple and possible conflicting explanations of the request. Let's not encourage this. Canit we please remove it?
>> 
> 
> I agree with you on the model of the exceptions -- that the site's pages should explain what's going on, and that the API call and resulting UI should be a confirmation.  I wonder if, if that is the case, we need all the explanatory parameters to the API, and I agree that re-writing 6.7 in the light of that model would be good.

It sounds like the concern is over the possibility of having a UI that uses an explanatory string or a "more info" URI rather than just having a non-normative example at all.

Are there cases where the user sees conflicting explanations of the request? I guess a truly confusing site could provide contradictory statements in its HTML content before the JS call and the optional explanationString parameter (or the detailURI), but our APIs certainly won't prevent sites from choosing to be confusing and sites that don't wish to use the string parameter can simply not use it. The suggestion in January was that a browser could have a good incentive to present this to the user and that optional parameters (and no UI requirements) could provide variety among vendors. 

My understanding is that in this thread [0] Jonathan, Shane and Sid ultimately agreed on this approach, and it's been supported in each re-drafting since.

[0] http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0321.html

>> Again, forgive me if I'm missing background on this, but Section 6.8 states that "User agents may instantiate NavigatorDoNotTrack.requestSiteSpecificTrackingException even when navigator.doNotTrack is null." Shouldn't this be a MUST? Sites will rely on this being present. What's the rationale for making it optional?
> 
> 
> Current matter of debate.  I see little difference, as said in another email, between (a) no API (b) an API that always says no and (c) a user that always says no.  I am hesitant to design products, rather than protocols, here.  If people stop using a browser because they can't visit sites, because those sites require an exception and can't get one with their current browser, that's a product issue.

Section 6.8 covers the possibility of providing an exception API even when no preference has been expressed. In general, I wouldn't expect sites to rely on the ability to request an exception when no DNT header is present to begin with, which is when navigator.doNotTrack is null. (While I agree with Dave Singer's general take on presence/configured behavior of the API method, Section 6.8 is only for the special case of unset DNT.)

Thanks,
Nick