Re: Batch closing of TPE related issues

I didn't understand ISSUE-192 to be about the capability for revocation of user-granted exceptions within the browser, but a question as to whether the API for storing user-granted exceptions in the user agent should include capabilities for cookie semantics, including timed expiration or secure-only. I agree with the resolution that it doesn't seem at this time like those capabilities are needed. To Rob's point, I don't think ISSUE-192 addresses the question of user control of revoking user-granted exceptions; we should go ahead and close it.

When the idea of user-granted exceptions as stored in the browser (rather than consent mediated by the browser) was first proposed, I did try to express concern about the confusing situation of simultaneously using stored user-granted exceptions and out-of-band consent. One key advantage of having user-granted exceptions stored by the user agent is that the user can inspect them in a single place and revoke granted permissions at a time of their choosing. If users revoke these exceptions but the consent is also stored through some out-of-band means and so the user continues to be told that they have consented to being tracked in a specific context, it would be surprising to the user and it might become difficult to opt-back-out.

I'm not sure any new normative text is needed here, but I think in order to make the user-granted exception system usable, we could provide non-normative guidance to implementers to not surprise users by simultaneously using in-band and out-of-band signals and second-guessing a change to DNT:1.

Thanks,
Nick

On Jun 10, 2013, at 7:41 AM, Shane Wiley <wileys@yahoo-inc.com> wrote:

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