Re: issues and questions in the latest TPE draft

I think we have a balanced approach now.  As I understand it, the current situation is

* the site thinks it needs an exception.  It explains to the user why, and what that means, in its own expression ('UI'), i.e., web pages, frames, whatever it likes. It gets the user to the point where they understand and are ready to agree.
* it then (a) either calls the API to ask the UA to confirm and record that grant or (b) remembers this "out of band".

In case (a) we call it in-band because the request is made directly through the UA, and the existence of the exception is reflected by the consequent DNT:0 signal sent 'in band' (in the transaction).  In case (b), the existence of the exception is established without the user-agent being aware (through some appropriate dialogue with the user, which I suppose could theoretically not even involve web pages).

As i see it, the optional parameters to the API are there to enable the site to express that this formal API request is linked to that conversation the site and the user already had.


Example (in band):  user visits newspaper.com with DNT:1.  The newspaper is monetized through tracking-supported advertising.  It sees the DNT:1 and re-directs to a page that explains that the user eitehr needs to subscribe, or grant an exception.  "If you grant an exception, my chosen advertisers, who are truly upstanding netizens, will track you when you visit this site, and show you advertisements based on your what they observe and record."  The user indicates 'ok, deal', and the API is called, and one of the explanatory parameters says "This grants an exception for the upstanding netizens that newspaper.com identified, when visiting that site."  The explanatory text now links this (in the user's mind) to the pages and conversation he's seen, and all is OK.


Example (out of band): user signs up with newspapermogul.com for a reduced-rate subscription to all their papers (Bogville News, Swamptown Chronicle, Marshy Times, and so on), agreeing to the condition that all the mogul's newspapers advertisers can track this user. Since this agreement was reached on a different site from the ones the user will visit, and those visitable sites are many, it's easier for the newspapermogul site to relay that exception to the papers 'out of band'.  They then also tell their advertisers (e.g. in the dynamic URLs created, again 'out of band') that 'we have an exception here, folks'.  These sites all indicate status 'C' (consent received).  If the UA wants to 'police' this, it might ask the user "Swamptown Chronicle are claiming that they have an exception from you; do you agree?" but that's a question for the UA and the user; we don't talk about it.


As Shane and others say, I think we have a good balance of UI here (mostly done in pages that can be designed to be as explanatory as the site needs, with final confirmation for in-band through the API and its implied minor UI) and also of mechanism (use of the API and the UA ability to record and manage, vs. use of out of band mechanisms).


I am not sure I see a problem, except maybe the example could be improved?



On Aug 29, 2012, at 10:18 , "SULLIVAN, BRYAN L" <bs3131@att.com> wrote:

>> In Seattle we discussed that Servers could optionally record an OOB (Out
>> of Band) Exception within the UA but with a flag to state this was set
>> by the Server.  This gives the positive option of central management
>> with links back to the Server to alter the choice (versus managing the
>> choice directly in the UA).  I thought this was a nice balanced approach
>> to the issue - a middle-ground.  Are we still supportive of this
>> outcome?  I hope so...
>> 
> This sounds like a good way to provide transparency to the user. As I've noted before, I have concerns about the scalability of the preferences management experience when you consider all the devices and browsers (or Web user agents in general) that users will use. So the OOB preferences management approach could become the norm for some users, and should be explicitly supported by the DNT standard at least such that OOB-managed preferences can be clearly identified to the user.
> 
> Bryan Sullivan 
> 
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 29 August 2012 18:12:16 UTC