Re: ACTION-175: Draft API method for sites to remove, a la removeTrackingException()

Hi Vincent,

Could you provide more detail on the use case for a user's calling this proposed JavaScript API? For user-agent-managed exceptions, I would expect users would remove persisted exceptions using whatever UI the user agent comes up with rather than via JavaScript on a page. Is this needed for browser plugins, maybe?

ISSUE-83 also seems (via Aleecia's note) to refer to revoking out-of-band consent to override DNT (which would be functionality for a user to initiate). I don't think a JavaScript API will satisfy that case though. Does the URI proposal already cover this with a URI the user can load to modify their options via the optional `options` field?

The upshot of these questions: can we get by with just the removeException method below?

Thanks,
Nick

On May 15, 2012, at 12:15 PM, TOUBIANA, VINCENT (VINCENT) wrote:

> The action item suggests that this API should be called by websites to remove tracking exceptions but the corresponding issue (83) is about user opt-out.
> Therefore, I propose two different APIs:
>         - One that should be called by website to remove exceptions,
>         - One that should be called by users to revoke exceptions (opt-out).
> Vincent
>  
> I Context
>  
> Users may grant site-specific and site-wide exceptions when they visit a website requesting them.  They may later decide to revoke any type of granted exceptions that are stored in their browsers.
> Site specific exception should be stored in the browser under the format <site,domain,value> where value is true if the exception has been granted and false otherwise. Users should not be able to remove site specific exception from the browser but only can only revoke them. It means that the pair <site,domain> remains stored by the browser but it is associated to the value “false”.
>  
> II Remove Exception
>  
> The removeException API should be called:
> By the user at any time to remove site-wide exceptions and web-wide exceptions,
> By a website if it no longer includes a given third party. The website should not be able to revoke an exception but to REMOVE it.  A website can only call this function for exceptions that have been granted on its website. This situation may happen if a first party no longer uses a third party.  If a first party decides to remove an exception for its site, the user may not be notified. 
> II.1 Method
> removeException
> Called by a page or a user to delete a user granted exception
> Parameter Type Nullable Optional Description
> siteDomain DOMString ✘ ✘  
> DomainString DOMString ✘ ✘  
>  
> Return type: Boolean
>  
> Notice that either string could be replaced by a wild card which would be interpreted like “any domain” by the browser. User could thus remove web-wide exceptions, site-specific exception and site-wide exceptions.
> If a website calls removeException with a site domain different of its own domain, the exception is not removed and the function return false.
> If this function is called by the user, at least one of the parameter should be a wildcard. A user should not delete a site specific exception. A user can remove a web-wide exception by calling removeException(*, domain), such call should not revoke the site-specific exceptions that have been granted to this domain.
>  
> III Revoke Exception
> The revoke Exception API should be called by a user at any time and to revoke site-specific exception or a site-wide exception.
>  
> III.2 Method
>  
> revokeException
>       Called by a user to delete a site specific exception.
> Parameter Type Nullable Optional Description
> siteDomain DOMString ✘ ✘  
> DomainString DOMString ✘ ✘  
>  
> Return type: Boolean
>  
> If a user revokes a site-specific exception or a site-wide exception, the browser should not send DNT:0 to the associated site during the next visit. To make such thing possible, the browser should store a list of revoked exceptions.