Re: Batch closing of TPE related issues

I agree with Nick as well. Guidance is necessary to untangle the two 
concepts and answers my concern.

Rob

Matthias Schunter (Intel Corporation) schreef op 2013-06-12 10:21:
> Hi!
> 
>  I agree with Nick. We should offer guidance how user-granted
> exceptions (UGE) and out-of-band exceptions (OOBE) interplay.
> 
>  My take on this is:
>  - The DNT signal is the definitive answer (and reflects the UGE 
> present)
>  - If a site disagrees with the signal, it can ask for an UGE
>  - If a site cannot obtain an UGE, it may ask for an out-of-band
> exception in a transparent fashion
>  - If a user neither accept an UGE nor an OOBE, then the site can
> choose how to service the user
> 
>  Conversions: UGE->OOBE
>  - I believe that UGEs must not be convertable into out of band
> consent since this would
>    reduce transparency and control for the users.
>  - Sites can delete an UGE and establish an OOBE (in this scenario
> the user does not get the impression of control).
> 
>  Conversions: OOBE->UGE
>  - If the site has obtained OOBE with sufficient consent for an UGE,
>    the site should be free to store an UGE in the browser ONCE
>  - In order to meet the user expectations  of control and
> transparency, the OOBE should
>    then be disabled, i.e., if the user deleted the UGE, the site
> would need to obtain a fresh OOBE
> 
>  Any opinions? Feedback? Usecases where this approach does not work?
> 
>  Regards,
>  matthias
> 
> On 12/06/2013 09:06, Nicholas Doty wrote:
> 
>> 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 [1]
>>>> 
>>>> 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 [2]
>>>> 
>>>> 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 [3]
>>>> 
>>>> 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 [4]
>>>> 
>>>> 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 [5]
>>>> 
>>>> 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
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
>>>> 
>>>>  
> 
> 
> 
> Links:
> ------
> [1] http://www.w3.org/2011/tracking-protection/track/issues/112
> [2] http://www.w3.org/2011/tracking-protection/track/issues/152
> [3] http://www.w3.org/2011/tracking-protection/track/issues/167
> [4] http://www.w3.org/2011/tracking-protection/track/issues/182
> [5] http://www.w3.org/2011/tracking-protection/track/issues/192

Received on Wednesday, 12 June 2013 11:28:17 UTC