Re: Agenda for July 18, 2012 DNT WG Call on TPE

Hi David


I prepared the current draft a few days ago, and Matthias and I have been checking it.  The draft is now checked in, and this is what we should review.  

I regret that I am at an MPEG meeting, and though I hope to call in, I may not make it (and the network here is suffering from some overload problems, so I may well have IRC issues if I do).

The minor changes in this document are:
* changed terminology from "on/off/unset" to "DNT:1, DNT:0, unset"
* added the example of a user being asked at first use for their preference
* and some minor editorial, punctuation etc.

A major change is the adding of the 'audit' information to the well-known resource, and some cleanup of the initial language.  I think Roy can describe these edits better than I.



The other major change is to the exceptions API, to implement Matthias' proposal to address Ian's concern over the implementability of site-specific exceptions.  This is as an alternative to the previous text, which has parameters for the third-parties that the top-level site wants; this revision removes them.  I am not sure that I support this, but I drafted it as Matthias reports it was a compromise and we needed specific text to review.



In this draft, the list of domains parameter to the APIs for both requesting site-specific exceptions, and cancelling them, has been removed. The cancel case is easy to explain: it removes all site-exceptions (both specific and site-wide) from the list of remembered exception grants.

The request API says that the UA should look for the 'partners' part of the well-known resource, and use that as the list to remember who to send DNT:0 to.  If it doesn't exist, or if the UA chooses, it remembers a site-wide exception ('[domain, *]').  I wrote it as 'should' as there are real consequences to the UA 'broadening' the list from a specific set of third-parties, to all third-parties who ever occur:
* for the site, it may have third-parties it needs to have tracking permissions, and that it knows and trusts (ad partners, for the most part), and other third parties that either it doesn't need, or maybe doesn't even know, and therefore doesn't have the same level of trust in;
* for the user, they are being asked to approve an open-ended request ("every third party who does or might ever appear on this site").  (Yet it remains true that users for the most part will have no idea who most of the third parties are, will not recognize their names, and will probably glaze over if presented a list of explicit domain names. Even if the UA uses the 'partners' list, the UA might summarize for the user: "an exception for a specific list of third-parties that might appear on examplenews.com", as opposed to "an exception for all third parties who ever appear on examplenews.com").

One obvious example of "other third parties" are sites that mash-in content from other places, and those mashed-in sites may, in turn, pull in yet more third parties, and so on. Also, social-networking and other buttons should probably be getting web-wide permissions, not getting grand-fathered in to site exceptions like this, and again, if they pull in yet more third-parties, it's by no means clear that the main site needs or wants to give the buttons, and their parties, a 'free ride'.  These concerns led me to write it as a 'should' use the partners list, yet 'may' use site-wide, and are the reason I am still concerned about this design.

I am aware of two edits that still need to happen:
* Nick Doty has graciously done the research to get the terminology and behavior around script-origins correct, and his edits need to be done; the current text rather vaguely refers to "top-level domain" and though we can probably understand what it means, it needs tightening up;
* The current language about a database of tuples is intended to provide a processing model to make it clear what the UA needs to remember, and what effect it has on the headers sent in future HTTP requests should be; it's just a model. However, some think it mandates a particular implementation, which is not the intention - it's just a processing model. The text needs to be edited to make this clear.

* * * * 

Why am I concerned that neither sites nor UAs will like *any* exception API?

Let's walk through the sequence of what happens when (IBE) the site uses this API ("in-band exception"), and (OOBE) the site remembers what we call "out-of-band exceptions".

User Iam Shy turns on do-not-track.  Some time later they visit examplenews.com; examplenews.com monetizes its operation through targetted advertising, and noticing the DNT:1 header, re-directs Iam Shy to a page which explains that they need to allow some tracking if they want to use the site. The user reads the explanation page, and decides to agree; they click some function on the page that says so.

Under IBE, it then executes the script request for a site exception, and the UA somehow asks for confirmation from the user, the user confirms, and the UA remembers the grant.  
Under OOBE, the site remembers the grant somehow (e.g. it leaves a cookie that merely says "this user has granted an OOBE", but there are other ways also).

Now Iam Shy goes back to a content page on examplenews.com.  
Under IBE, some or all third-parties get sent a DNT:0;  
under OOBE, the site conveys to all the third-parties it cares about that the user has granted the exception (e.g. in the URL that is formed to pull-in their content, as a CGI parameter.) 

Under IBE, the UA knows of the exception; 
under OOBE, something in the response headers or well-known resource informs the user/UA that the out-of-band exception has occurred.

There are similar comparison flows for web-wide (the user visits trackmyreading.com, and it points out that the site won't work without a web-wide exception, and so on), and indeed for the cancellation of exceptions.  These all involve pages that explain and set the stage, followed up in the IBE case with a final script call to record the decision.

Issues:

Under IBE:
* the main site doesn't know whether all the requested grants will survive; some UAs might allow the user to change their mind and delete some from the database of remembered grants; we could write that it's not allowed to have the user do this fine-grained fiddling, but it's still a situation the top-level site (examplenews.com) cannot detect and has to trust; many sites may prefer to keep the situation consistent and locally managed, rather than deferring to the UA to remember the grant of exception;
* the UA has this quite awkward 'implied UI' to manage
* the UA has yet-another 'database' to keep, manage, and maybe give a UI for (though this is not required)

Under OOBE:
* the site has to relay to its third-parties (the ones it cares about, at least) the grant, and if they pull in more third-parties, that relay has to carry on; this probably means dynamic URL construction;
* the user has no idea who this grant will be relayed to (the third parties)
* it's harder for the UA/user to detect that a site claims it's had a grant of exception

I am sure these lists are rather incomplete, and would welcome people pointing out more issues with in-band or out-of-band exceptions.


On Jul 17, 2012, at 21:34 , David Wainberg wrote:

> Hi Matthias,
> 
> Thanks for the agenda. Can you or David please confirm the specific text we'll be reviewing? Thanks.
> 
> Cheers,
> 
> David
> 
> On 7/17/12 2:05 PM, Matthias Schunter wrote:
>> Chair: Matthias
>> Main topics:  TPE Spec at 
>>                         http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
>> 
>> ---------------------------
>> Administrative
>> ---------------------------
>> 
>> 1. Selection of scribe
>> 
>> 2. Quick scan of weeks & conflicts for the next Face2Face in Europe
>> 
>> 3. Newly published minutes since the last call?
>> 
>> ---------------------------
>> Old business
>> ---------------------------
>> 
>> 3.  Review of overdue action items: 
>>      https://www.w3.org/2011/tracking-protection/track/actions/overdue
>> 
>> 4.  Status of OPEN  ISSUES and assignment of Actions:
>>      http://www.w3.org/2011/tracking-protection/track/products/2
>>   
>> 
>> ---------------------------
>> New business
>> ---------------------------
>> 
>> 4.  David presents the revised site-specific exception framework + discussion
>> 
>> 5. User agent behavior [ISSUE-144]
>>      What statements do we want to include in the TPE on user agent behavior?
>> 
>> ---------------------------
>> 
>> 7. Announce next meeting & adjourn
>> 
>> ================ Infrastructure =================
>> 
>> Zakim teleconference bridge:
>> VoIP:    sip:zakim@voip.w3.org
>> Phone +1.617.761.6200 passcode TRACK (87225)
>> IRC Chat: irc.w3.org, port 6665, #dnt
> 

On Jul 17, 2012, at 21:34 , David Wainberg wrote:

> Hi Matthias,
> 
> Thanks for the agenda. Can you or David please confirm the specific text we'll be reviewing? Thanks.
> 
> Cheers,
> 
> David
> 
> On 7/17/12 2:05 PM, Matthias Schunter wrote:
>> Chair: Matthias
>> Main topics:  TPE Spec at 
>>                         http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html
>> 
>> ---------------------------
>> Administrative
>> ---------------------------
>> 
>> 1. Selection of scribe
>> 
>> 2. Quick scan of weeks & conflicts for the next Face2Face in Europe
>> 
>> 3. Newly published minutes since the last call?
>> 
>> ---------------------------
>> Old business
>> ---------------------------
>> 
>> 3.  Review of overdue action items: 
>>      https://www.w3.org/2011/tracking-protection/track/actions/overdue
>> 
>> 4.  Status of OPEN  ISSUES and assignment of Actions:
>>      http://www.w3.org/2011/tracking-protection/track/products/2
>>   
>> 
>> ---------------------------
>> New business
>> ---------------------------
>> 
>> 4.  David presents the revised site-specific exception framework + discussion
>> 
>> 5. User agent behavior [ISSUE-144]
>>      What statements do we want to include in the TPE on user agent behavior?
>> 
>> ---------------------------
>> 
>> 7. Announce next meeting & adjourn
>> 
>> ================ Infrastructure =================
>> 
>> Zakim teleconference bridge:
>> VoIP:    sip:zakim@voip.w3.org
>> Phone +1.617.761.6200 passcode TRACK (87225)
>> IRC Chat: irc.w3.org, port 6665, #dnt
> 

David Singer
Multimedia and Software Standards, Apple Inc.