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

Re: Batch closing of TPE related issues

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Mon, 10 Jun 2013 14:39:48 +0200
Message-ID: <51B5C914.80601@schunter.org>
To: Rob van Eijk <rob@blaeu.com>
CC: "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi Rob,

Do I understand you correctly that
- you are concerned if UGEs are translated into out of band exceptions?
- you believe that the revocability of a UGE is an essential feature 
from your perspective
    (and undermining this feature by persisting an UGE as an out-of-band 
exception would undermine this benefit)?

If other people share this concern, we should provide clearer language 
that delineates both exception types. E.g.,  something like this
  - UGE and out-of-band cannot be used at the same time
  - If you persist a UGE in the browser, you are responsible for 
ensuring revocability
    (i.e., if the UGE disappears, then DNT;1 will be implemented and 
complied with)

Opinions / Feedback?


On 06/06/2013 09:35, Rob van Eijk wrote:
> Revocation should be a cornerstone.
> I would therefore suggest not to close this issue and discuss how 
> revocation ties in with expiry or other means of undoing an exception.
> In NL for example there is most likely to be a (local law) requirement 
> to keep consent on record for multiple years.
> I am concerned that an indication that a granted exception at first 
> visit turns into an out of band consent on next visits.
> Another concern is that granting an exception and undoing that are two 
> sides of the same coin. The undoing part could be addressed with 
> (automatic) expiry, revocation, clearing the browser state etc. I do 
> not have a complete picture of all the options to reset a UGA.
> Without turning this into a compliance discussion, the buildingblock 
> to deal with revocation should be looked at more in detail.
> Rob
> "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org> wrote:
>     Hi Team,
>     enclosed is a list of TPE-related ISSUES that I believe can be closed.
>     Please drop me a line if you disagree and believe that some of these
>     issues should be kept open.
>     Thanks a lot!
>     matthias
>     -----------------
>     ISSUE-112: How are sub-domains handled for site-specific exceptions?
>     http://www.w3.org/2011/tracking-protection/track/issues/112
>     Resolution:
>     - Cookie-like
>     - As documented in the spec
>     ISSUE-152: User Agent Compliance: feedback for out-of-band consent
>     http://www.w3.org/2011/tracking-protection/track/issues/152
>     Resolution:
>     - User agents (in the new model) are free to interact with users
>     - We do not mandate that t!
>       hey do
>     so
>     ISSUE-167: Multiple site exceptions
>     http://www.w3.org/2011/tracking-protection/track/issues/167
>     Resolution:
>     - No special approach for multi-site exceptions
>     - Based on implementation experience, we may later revisit the issue
>     ISSUE-182: protocol for user agents to indicate whether a request with
>     DNT set is 1st party or 3rd party
>     http://www.w3.org/2011/tracking-protection/track/issues/182
>     Resolution:
>     - This seems technically impossible
>     - As a consequence, I suggest to close
>     ISSUE-192: Should exceptions have expiry date, secure flag or other
>     cookie-like attributes?
>     http://www.w3.org/2011/tracking-protection/track/issues/192
>     Resolution:
>     - User agents may expire
>     exceptions (or use other mechanisms for
>     aligning them with user preference)
>     - Suggestion: No additional management mechanisms; leave TPE spec as it is
Received on Monday, 10 June 2013 12:40:14 UTC

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