W3C home > Mailing lists > Public > public-tracking@w3.org > October 2014

Re: tracking-ISSUE-266: automatic expiration of a tracking preference exception via API parameter [TPE Last Call]

From: Nicholas Doty <npdoty@w3.org>
Date: Tue, 21 Oct 2014 16:18:06 -0700
Cc: David Singer <singer@apple.com>, Mike O'Neill <michael.oneill@baycloud.com>, Tracking Protection Working Group <public-tracking@w3.org>
Message-Id: <7BF5C709-C256-41A7-8758-29785AD2B26B@w3.org>
To: Justin Brookman <jbrookman@cdt.org>
I think my concern with expiration was about implementation/use, especially when it seems possible to accomplish this through other means in many cases.

One thing to do in that case is to mark the feature "at risk" when we go to CR/Call-for-Implementations. If sites and browsers don't implement it, then we would remove the feature at the Proposed Recommendation stage. If we do see interoperable implementation, then evidently it's useful, and we keep it.

Thanks,
Nick

On October 21, 2014, at 2:31 PM, Justin Brookman <jbrookman@cdt.org> wrote:

> David had been the leading opponent of including an expiry parameter for exception-setting APIs; it sounds like he may be willing to support so long as we’re retaining the mechanism for granting web-wide exceptions. Do others object to Mike’s proposed language (or want to tweak it to address their concerns)?
> 
>>>> -----Original Message-----
>>>> From: David Singer [mailto:singer@apple.com]
>>>> Sent: Wednesday, October 15, 2014 10:09 AM
>>>> To: Tracking Protection Working Group
>>>> Subject: Re: tracking-ISSUE-266: automatic expiration of a tracking preference exception via API parameter [TPE Last Call]
>>>> 
>>>> I think that this is a problem most conspicuously for web-wide exceptions, and they effectively emulate the behavior of cookies but in another way.  (Site-wide exceptions and cookies are not similar.)
>>>> 
>>>> The really broken scenario is where the site has a web-wide exception that needs to expire for some reason, and the exceptions API doesn't support expiry. To remember the expiry, the site sets an expiring cookie, and questions or disregards the exception if either it or the cookie is missing. If the site's web-wide resource is non-scripted it is in no position to do anything about confirmation, re-requesting, checking etc. unless the user visits the site itself again.
>>>> 
>>>> Issues:
>>>> * why not use just the cookie?
>>>> * if the cookie is missing but the exception is present, which of the following occurred?
>>>> a) the user deleted cookies but the expiry time is not yet reached
>>>> b) the cookie expired
>>>> c) the user set their general preference to DNT:0  I don't think the site can tell.
>>>> 
>>>> 
>>>> I therefore think that we should either
>>>> 
>>>> 1] add an expiry parameter to both exception-setting APIs (for regularity, though only the web-wide one is problematic) OR 2] delete web-wide exceptions, since they are simply replicating cookies
>>>> 
>>>> 
>>>> Which do people prefer?
>>>> 
>>>> 
>>>> David Singer
>>>> Manager, Software Standards, Apple Inc.

Received on Tuesday, 21 October 2014 23:18:27 UTC

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:45:24 UTC