TPE changes for the exceptions API

On Aug 7, 2012, at 9:06 , "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org> wrote:

> I'd like to thank Roy and David for preparing the next major revision of the TPE spec!

Thanks, Matthias!

I did most of the requested edits to the exceptions API.  What is missing is trivial in concept, I am just not quite sure how to effect this one change (changing the cancel calls to have a return value) -- I have asked Roy for help.

Otherwise, I have tried, again, to find a balance that I hope industry, advocates, and UA implementers can live with.



Changes are all to the site-specific request.  The cancel calls, and the web-wide, are unchanged.

The site-specific call can now indicate an optional list of third-parties it needs; if this parameter is missing, the request is for a site-wide exception.  Whether it is there or not, the UA can 'broaden' to a site-wide exception if it likes -- as long as it tells the caller.  the call-back now distinguishes between "you got 'no' as an answer, you got your explicit list, you got a site-wide". This saves the extra round-trip that the previous version had if the UA wants the partners list -- it can be supplied in the API.  It also decouples the informative 'partners' list in the well-known resource from the exception API.

There has been continuing anxiety over the manageability of the site-specific explicit lists ('first party A needs an exception for these explicit trusted third parties'), for both the server and UA sides.  The above 'permission' (broadening to site-wide) makes life easier for the UA, but leaves the server with an uncomfortable problem: 

* what if I ask for exceptions for my needed and trusted third-parties {a, b, c}, am told I got the exception, allow (for example) free access to my site to continue, but later the user removes {b, c} leaving only {a} getting dnt:0 on my site?  

The server now has its exception only partially satisfied, and worse, it's rather hard to detect on the part of the first party.  In a previous discussion, where I wondered about having the first party tell the thirds that they have an exception, I was told that was 'hard'. If relaying forward the "we have an exception" FROM the first party to the thirds is hard, it's probably even harder to get a back-channel FROM the thirds back to the first party  --  "he sent me a dnt:1!".

What I suggest, and write in this revision, is that the user-agent MUST treat each call of the API as an atomic 'unit', granting and maintaining the list in its entirety or not at all. This actually can simplify the UI, in that now you're presenting 'web wide' and 'site specific' exceptions to the user (if you want to).  But it really makes life much easier for the server:  you get a simple binary yes/no on what you need.  In particular, because of the way the matching rules work, if a first-party 'example.com' asks for an exception for {fine-ads.com, trusty-analytics.com, example.com} (i.e. includes itself in its list), then as long as the exception exists, IT will get the dnt:0 as well as fine-ads and trusty-analytics.  So now it has an easy way to monitor for the continued life of the exception -- ask for a dnt:0 for myself, for as long as the exception exists.

Some may worry that this is a hard-to-police 'must' (it's about database management, not protocol), but I think it's as easy to detect a violation of this as for the requirement that the UA 'must not' set a default :-).



I tidied up the cross-origin stuff;  in order to allow the use of libraries, it is the origin of the document that *embeds* the script, not the origin of the script itself, that is the implicit parameter.  This matches the practice, as I understand it, in HTML (CORS etc.).  Nick might correct me :-).


The cancel calls remain very simple; 'please clean all [web-wide | site-specific] exceptions for me, this first party', i.e. return the first party to a known clean state.  This is easier to write, describe, and manage, I think, for both ends.


Issues being considered:

In the current model, calls are for fully-qualified domain names (no sub-domains etc.),.  

What header (dnt:0 or dnt:1) a site gets is determined simply by the matching rules -- redirects have no effect. 

There is one corner case which is hard to support:  mashed-up content which is in turn ad-supported.  it's not clear how to distinguish between embedded content which is embedding ads (and hence the top-level domain stays the same) and embedded content that should start a new context.  If you don't get the issue, I am happy to expand, but this email is already too long, and I think this is an edge case we can defer for a while.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Wednesday, 8 August 2012 00:12:26 UTC