Re: Revised approach to Exceptions

Hi Mike


On Jan 9, 2013, at 4:16 , Mike O'Neill <michael.oneill@baycloud.com> wrote:

> Hi David,
>  
> On the new API (to answer “does this exception that I previously requested still exist?" surely the receipt of a DNT:0 in the request header (or from the current requestDNTStatus()) already indicates that?

Alas, no.  Let's look at both the web and site exceptions.

a) web-wide.  I (example.com) set up a web-wide exception.  Later, I'd like to know if it still exists, or whether the user has changed their mind.  If I ask "what header do I get in the current context?" I might get a DNT:0 answer for at least three reasons:
  a.i) my exception stands
  a.ii) I'm currently embedded on a site that's got a site-wide exception
  a.iii) the user currently has DNT:0 set as their preference
b) site-specific.  Say I (example.com) want an exception just for my trusted advertisers ad1.com and ad2.com.  I set up a site-exception for them.  Now, if I ask "what DNT header do I get in the current context?" that exception does NOT affect the header that comes to me, example.com, but only to those ad sites when embedded on my site.  I'm flying blind.

The current API is answering the question "how am I supposed to be behaving right now?" which is not the same as "does this exception I asked for a while back still stand?".

>  
> If you mean an embedded frame could ask the question about another domain – i.e.  requestDNTstatus(DOMString otherdomain), then we could be introducing a new fingerprinting risk.
> For example script in a frame could set up a web-wide exception for “insurancerisk.com”, which could then be checked anywhere with requestDNTStatus(“insurancerisk,com”), indicating one bit of data about the current user-agent/user. More bits could be added by executing as many dummy WW exception calls needed.
>  
> It is a pity though because this would be a way to solve some of Shane’s use-cases, i.e. you could set up a site specific exception forwebmail.com then query for its existence on webmail.co.uk. This would only work for resources returning HTML though so it would not help with imagecloud.com, so probably not worth the fingerprinting risk.

Right, I am trying to minimize both cross-site scripting and fingerprinting issues (as well as the 'privacy' issue of sites finding out about each other).  But that's not at play here.

David Singer
Multimedia and Software Standards, Apple Inc.