Hi David,

 

I may have missed something but the Confirm UGE API could do with some explanatory text.

 

1)      The ConfirmSiteSpecificTrackingException also applies to a grant which had been requested web-wide. A web-wide exception by definition applies site-specifically on all sites and the match algorithm in 7.3.2 works for this ( [document-origin, target] matches [*, web-wide-document-origin] if target == web-wide-document-origin)

This is not completely clear in the current text so maybe we should change the function description to:

 

Called by a page to confirm a tracking exception.

This function can be used to confirm a site-specific exception or a web-wide exception that has been granted for the document-origin or sub-requests issued from it.

 

2)      I assume the .domain property in ConfirmExceptionPropertyBag is (in keeping with the SOP) cookie-like as described in 7.4.1. This is not obvious so it should be stated, though this API only seems useful to check for exceptions on subdomains of the document-origin.

 

 

For Issue-262 I looked at the JavaScript necessary to determine which of a list of bidders had granted exceptions, which is possible using the ConfirmSiteSpecificTrackingException but the code is long winded. You have to check for the complete list then repetitively check component sub-lists till you get a set of lists that the API returns true for, and the input list length could be in thousands for the ad-exchange use case.

 

If this is predicted to be a common use-case (the tracking protection component of the recently announced Mozilla Polaris project https://wiki.mozilla.org/Polaris could lead to ad-exchanges having to check for UGEs) perhaps we should consider changing the API to return either a Boolean array or an array of indices to the input arrayOfDomainStrings. While we are at it there  seems to be little point in the ConfirmWebWideTrackingException  API anyway, why not make it redundant and rename the site-specific one to ConfirmTrackingException. (This also helps avoid these ridiculously long function names).

 

Mike