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