RE: Batch closing of TPE related issues

UGE was designed to be a persistent store of the user’s granted exception to a party.  As we’re finding areas where this persistence will not appropriately convey to the Server through the User Agent, why would we not also allow the consent event to be stored elsewhere for those cases?  The UGE experience itself is a consent event, so I’m not sure I understand why this doesn’t allow for external storage like any other out-of-band consent event.

- Shane

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: Monday, June 10, 2013 5:40 AM
To: Rob van Eijk
Cc: public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Batch closing of TPE related issues

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><mailto: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