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

I believe what we discussed in Amsterdam was that we wished to keep the
property that a site may only add an exception for itself. In the browser,
we have no way of knowing that www.example.com == example.com. The cookies
model of "domains" as opposed to origins is horribly broken already and
becoming more so, and no new spec in the past few years has built upon that
-- relying instead on strict origin matching.

-Ian

On Thu, Oct 25, 2012 at 7:31 AM, Mike O'Neill
<michael.oneill@baycloud.com>wrote:

> ** **
>
> ** **
>
> *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 <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*
> ***
>