W3C home > Mailing lists > Public > public-tracking@w3.org > May 2013

RE: issue-189

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Thu, 16 May 2013 12:20:04 +0100
To: "'Roy T. Fielding'" <fielding@gbiv.com>
Cc: <public-tracking@w3.org>
Message-ID: <024801ce5227$511843f0$f348cbd0$@baycloud.com>
The ePrivacy Directive recital said that the user's informed consent for
storage could be signalled through "browser settings". The A29WP and many of
the DPAs issued guidance that existing settings were inadequate because they
were generic i.e. you had to block, for example cookies, on all sites. What
was needed was a site-specific setting similar to the DNT UGE. You are
correct that first-party cookies and localStorage can be controlled by the
origin server with existing APIs but there is no way, other than the DNT UGE
mechanism, for first-parties to have any influence on their embedded
third-parties - other than just removing them.

 

My point was that the definition of DNT across jurisdictions is unclear
(because DNT unset will have different implications for embedded
third-parties) and so the DNT UGE is less useful  to meet the requirements
of Recital 66.

 

On the other hand  it would be possible to specify a resource (in a member
of the TSR) that can be sent an HTTP GET and whose function would be to
remove localStorage and limit the duration (or just delete) HTTP cookies.
This optional resource could be a way for servers that are normally accessed
as third-parties to give users the option to remove tracking identifiers.
Browsers could then decide to offer this function to their users, or origin
servers could enable it (by for example creating a set of iframe  elements
with their src attributes pointing to the "edit" resource of their embedded
third-parties).This does not need any new functionality in UAs to be
implemented.

 

The point is to offer users options to help regain their trust. If this is
not done then the arms race between browsers (and browser extensions) and
non-consensual data collectors will lead to far more generic blocking of
identifiers which could indeed destroy the web.

 

 

Mike

 

 

 

From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: 16 May 2013 00:12
To: Mike O'Neill
Cc: public-tracking@w3.org
Subject: Re: issue-189

 

On May 14, 2013, at 11:49 PM, Mike O'Neill wrote:





It was hoped that the TPE spec could meet the requirements for "browser
settings" referred to in recital 66 of the EU Privacy Directive.  This has
not been done, other than the ability to signal DNT:0 to embedded
third-parties (which is nevertheless diminished by the confusion between the
meaning of DNT unset in different jurisdictions). Given that tracking relies
on storing unique identifiers in the browser, so that subsequent HTTP
transactions from the same device/user can be associated with each other and
the user's web history collected, it would be relatively simple to extend
user control over these identifiers.

 

It is not necessary.  Browser settings and controls over client-side

storage can be unique per browser -- they supposedly compete on UIs.

Likewise, server control over clint-side storage is based on the

origin model and can be accomplished using any resource on the origin,

which might include the edit link or some resource linked from that

resource.  Hence, there is no need for a standard interface

 

 

We could introduce a new member to the Tracking Status Resource JSON called,
say, remove-storage. This contains the URI of a resource that will return a
set-cookie or set-cookie2 header that deletes all cookies indicated in the
request and also return an HTML document containing script that would delete
localStorage. This would allow the user to cause their UA to send a GET to
this resource to remove identifiers that may be used in a third-party
context.

 

If it was thought that it is too late to introduce a protocol element at
this stage we could add this as a requirement on origin servers if the
resource indicated by the "edit" TSR member is accessed with DNT:1. This
would only require some non-normative text to be added to the TRF
description.

 

No, if the server wishes to provide that function, it can do so via

a link/form action from the edit resource.  It would be a poor design

to cause client-side information to disappear when the user simply

wants to find out what controls or prior consent status they might

have access to via the edit link.

 

....Roy

 
Received on Thursday, 16 May 2013 11:20:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:32 UTC