- From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
- Date: Wed, 12 Jun 2013 10:21:12 +0200
- 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>
- Message-ID: <51B82F78.8010000@schunter.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