- 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