W3C home > Mailing lists > Public > public-tracking@w3.org > October 2012

RE: Proposal for alternative exceptions API

From: Fred Andrews <fredandw@live.com>
Date: Fri, 5 Oct 2012 11:51:52 +0000
Message-ID: <BLU002-W2158DA150F5110547A0F19EAA8B0@phx.gbl>
To: Adrian Bateman <adrianba@microsoft.com>, "public-tracking@w3.org" <public-tracking@w3.org>

When the UA UI is used, the user at least knows that they added the exception, and can have a record of this.  This may be an important fact if their expressed privacy preference is not respected and it causes them some harm.  Under your proposal an evil website could just claim that the user had agreed to the exception and the user would be in a much weaker position to dispute the matter.


From: adrianba@microsoft.com
To: public-tracking@w3.org
Date: Fri, 5 Oct 2012 05:10:06 +0000
Subject: Proposal for alternative exceptions API

I’ve spent the last couple of days at the F2F refining a proposal I’ve been working on for an alternative exception API for TPE. My goal is to design an API that trusts web sites to manage their
 exceptions (in the same way we trust them to respect DNT:1) with consent from their users. At the same time we need to protect users from malicious sites that might seek to modify DNT settings for sites that they don’t actually control. The proposal is below
 and I look forward to discussing more widely with people today.
New approach to Exceptions API.
This proposal:

Removes the need for the User Agent to provide UI for the exception. Section 6.8 of TPE expects sites will explain the need for the exception before calling the API. If the site has already done most of the
 work then this should be sufficient in the general trust model of DNT.

Adds the ability for sites to request exceptions for the applicable domain (e.g. stats.example.com can set an exception for all of example.com).

Adds the ability for the list of sites (for explicit exceptions) to also ask for domains (specific syntax is still an open issue).

Has the downside that it involves the public suffix list (but hopefully in a way that is compatible with current cookie implementations).
Goals of the Exceptions API

Send DNT:0 instead of DNT:1 in resource requests for which there is an exception

Maintain the exceptions in a more persistent storage than generic browser storage (e.g. cookies)

Prevent evil.com from being able to store exceptions for other sites

Avoid browser UI that (probably) isn’t very customizable and that interrupts the user’s flow (and could need to be shown over and over on any given site)
Since DNT is a trust based system (we have to trust that sites correctly apply DNT:1) we should trust those same sites to only call the exceptions API when they have permission for an exception from the user. The site
 must obtain explicit informed consent from the user to ensure that the exception reflects the user’s preference. This means no UA trusted UI is required and the site has control of the entire user experience including explaining the context-specific value
 of agreeing to the exception.
Two APIs grant exceptions: one for site-wide and one for web-wide. The site-wide API allows a site to store that all resource requests made from visiting that site at the
top-level browsing context should have DNT:0. The web wide API allows a site to store that all requests to its resources from any site should get DNT:0 and operates on the script
 browsing context (not top level) e.g. for the location of an iframe.
  void SetSiteWideException(optional DOMString
domain, optional sequence<DOMString> arrayOfSites);
  void SetWebWideException(optional DOMString
If domain is not specified or is null or empty then the script origin of the browsing context is used. If
domain is supplied and not empty then it is treated in the same way as the domain parameter to cookies (allows setting for subdomains). This means that you can set an exception for any domain that
domain-matches to the current script origin. The user agent should ensure that this is not a public suffix using an up-to-date public suffix list, such as the one maintained by the Mozilla project
 at http://publicsuffix.org/ (so example.com is allowed and co.uk is not allowed). This means
www.example.com can set example.com as the domain and site.name.example.com can set name.example.com or example.com but
www.example.com cannot set
arrayOfSites is equivalent to the arrayOfDomainStrings in the current spec and if specified says which specific sites will get DNT:0 rather than for all requests. User Agents MAY choose
 to ignore the arrayOfSites even if provided and treat this as a general site-wide exception. The information is provided for browsers that choose to support this stricter exception. Strings in the
arrayOfSites may be “wildcards” by starting with “*.” [Open Issue: is this the right syntax since it is different to
User Agents MAY store these exception settings with no UI (the onus is on the site to ensure that the exception reflects the preference of the user). User Agents MAY confirm the exception with the user before using
 it but this is not required. User Agents MAY include a configuration UI that allows users to see their current exceptions and optionally modify the list (e.g. remove a previously granted exception).
  bool QuerySiteWideException(optional DOMString
domain, optional sequence<DOMString> arrayOfSites);
  bool QueryWebWideException(optional DOMString
The Query* methods return true if an exception is (still) in place matching the supplied parameters. This allows sites to determine if a user has rescinded an exception (for example through a management UI).
  void RemoveSiteWideException(optional DOMString
  void RemoveWebWideException(optional DOMString
The Remove* methods remove any exceptions that the user agent has stored for a matching
Definition: “top-level site” means the hostname of the origin of the top-level browsing context.
SetSiteWideException Examples

www.example.com calls SetSiteWideException(). This means any resource requests made where
www.example.com is the top-level site (for example, an iframe or img) would receive DNT:0.

www.example.com calls SetSiteWideException(“example.com”). This means any resource made where example.com or any subdomain of example.com (for example news.example.com) is
 the top-level site would receive DNT:0.

www.example.com calls SetSiteWideException(“”, [”*.microsoft.com”, “*.msn.com”]). This means that from
www.example.com any resource that matches *.microsoft.com or *.msn.com would get DNT:0. All other resources would still get the default signal. [[This assumes we allow wildcards, which is an open issue at this point]].

www.example.com calls SetSiteWideException(“example.com”, [”*.microsoft.com”, “*.msn.com”]). This is the same as example 3 but for all resources matching on example.com and
 any subdomains.
SetWebWideException Examples

www.example.com calls SetWebWideException(). This means any resource request where the origin is
www.example.com from any site will be sent DNT:0.

www.example.com calls SetWebWideException(“example.com”). This means any resource request where the origin is example.com or any subdomain of example.com (for example beacon.example.com)
 from any site will receive DNT:0.

www.donottrackchoices.com includes an iframe that downloads a page from
www.example.com. The page in the iframe calls SetWebWideException. This behaves the same as examples 1 and 2 because SetWebWideException works at the browsing context level not the top-level browsing context. This would
 allow choice sites to set these site wide exceptions for a number of sites using iframes and cross-document messaging (postMessage).
Received on Friday, 5 October 2012 11:52:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:41:16 UTC