W3C home > Mailing lists > Public > public-tracking@w3.org > June 2013

Re: Batch closing of TPE related issues

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Wed, 12 Jun 2013 10:21:12 +0200
Message-ID: <51B82F78.8010000@schunter.org>
To: Nicholas Doty <npdoty@w3.org>
CC: Shane Wiley <wileys@yahoo-inc.com>, Rob van Eijk <rob@blaeu.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
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 
> <mailto: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 <mailto:std@schunter.org>]
>> *Sent:*Monday, June 10, 2013 5:40 AM
>> *To:*Rob van Eijk
>> *Cc:*public-tracking@w3.org <mailto:public-tracking@w3.org> 
>> (public-tracking@w3.org <mailto: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
>>
>>       
>>
>>       
>>
>>       
>>
>>       
>>
>>       
>>
>>       
>>
>
Received on Wednesday, 12 June 2013 08:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:41 UTC