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

Hi Nick,

I agree that the interface to manage exceptions in the UA could be browser specific and thus may not have to be defined in the document. Nevertheless I should then add a line to mention that the browser should change the DNT signal sent to a webpage if an exception has been removed (it should not longer send DNT:0).

I believed it would have make sense to describe how the exceptions where managed inside the browser but I guess it’d be ok to just define the removeException API.

Thanks,

Vincent


Bellow the new text:


II Remove Exception

The removeException API should be called:
·         By a user visiting a website to remove user granted-exceptions,
·         By a website if it no longer includes a given third party (i.e 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<http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html>

✘

✘



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.
A website can only call this function for exceptions that have been granted on its website or for web-wide exceptions that it has been granted. If a website calls removeException with a site domain different of its own domain, the exception is not removed and the function return false. A third party should not remove site-specific exceptions that it has been granted.

A UA should not send DNT:0 to a website on which an exception has been removed.


________________________________
De : Nicholas Doty [mailto:npdoty@w3.org]
Envoyé : mercredi 16 mai 2012 07:56
À : TOUBIANA, VINCENT (VINCENT)
Cc : public-tracking@w3.org
Objet : 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<http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html>

✘

✘



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<http://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html>

✘

✘



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.