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

Normative text for exceptions based on adrianba's proposal (ACTION-313)

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Thu, 25 Oct 2012 15:31:44 +0100
To: <public-tracking@w3.org>
Message-ID: <087901cdb2bd$7571d590$605580b0$@baycloud.com>
 

 

From: Mike O'Neill [mailto:michael.oneill@baycloud.com] 
Sent: 25 October 2012 15:05
To: 'ifette@google.com'
Subject: RE: Normative text for exceptions based on adrianba's proposal (ACTION-313)

 

Ian,

 

Adrian had a domain parameter so exceptions could be added for subdomains, matched with document origin. which I think that would be useful. Did you forget that or did you mean it to be removed?. I agree we need to keep siteName, detailURI etc so that the exceptions can be shown to the user later.

 

Mike

 

From: Ian Fette (イアンフェッティ) [mailto:ifette@google.com] 
Sent: 24 October 2012 20:41
To: public-tracking@w3.org Group WG
Subject: Normative text for exceptions based on adrianba's proposal (ACTION-313)

 

The following is a stab at normative text based on Adrian's proposal [1] that he brought forward at the Amsterdam f2f. I don't want to go through the hassle of exactly spelling out all the details (parameter names, types, nullable, optional, etc) before we have agreement on the API so pardon the pseudocode.

 

API to request site-specific exceptions:

 

interface NavigatorDoNotTrack {

integer storeSiteSpecificTrackingException(optional sequence<DOMString> arrayOfDomainStrings,  optional optional siteName, optional optional explanationString, optional optional detailURI);

}

 

Most of the parameters remain the same, except instead of having a callback, the API is turned into a synchronous response where the only failure mode is the result of a syntax error. 

 

Return type: (we probably need to discuss this. Note 3.2.1 in WebIDL, moving away from integer codes in the style of enumeration to strings. In general though, this isn't really a change as a result of Adrian's proposal but an orthogonal issue.

 

If the request does not include the arrayOfDomainStrings, then this request is for a site-wide exception. Otherwise each string in arrayOfDomainStrings specifies a target. When called, requestSiteSpecificTrackingException must return immediately. The return value has one of three states. 0 (or a string per 3.2.1 of WebIDL) represents a syntax error or other such error that the exception technically can not be stored as the site requested it. 1/2 remain as is.

 

...

 

6.8 User interface guidelines

 

User agents MUST store exceptions upon request from a website via the APIs documented earlier in this section. As the request is synchronous, user agents MUST NOT block the request on any user confirmation or interaction. User agents MAY present indications to the user that an exception has been stored, and MAY subsequently revoke stored exceptions.

 

The following text is non-normative.

 

User agents are free to implement exception management user interfaces as they see fit...

 

...

 

A user agent that chooses to highlight when tracking exceptions have been stored might provide an interface like the following.

 

- an icon in the status bar indicating that an exception has been stored, which, when clicked on, gives the user more information about the exception and an option to revoke such an exception.

 

- an infobar stating "Example News (news.example.com) has indicated to Browser that you have consented to granting it exceptions to your general Do Not Track preference. If you believe this is incorrect, click Revoke."

 

- no UI at all

 

In this example, the domain listed...

 

 

 

"The user agent might then store that decision, and answer future requests based on this stored preference. A user agent might provide the user with an interface to explicitly remove (or add) user-granted exceptions." -> "A user agent might provide the user with an interface to explicitly remove (or add) user-granted exceptions."

 

Remove: Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification.

 

[1] http://lists.w3.org/Archives/Public/public-tracking/2012Oct/0112.html
Received on Thursday, 25 October 2012 14:32:38 UTC

This archive was generated by hypermail 2.3.1 : Friday, 21 June 2013 10:11:37 UTC