- From: Rob van Eijk <rob@blaeu.com>
- Date: Wed, 12 Jun 2013 13:27:37 +0200
- To: "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>
- Cc: Nicholas Doty <npdoty@w3.org>, Shane Wiley <wileys@yahoo-inc.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
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