- 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