- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Wed, 12 Jun 2013 15:40:58 +0100
- To: "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>, "'Nicholas Doty'" <npdoty@w3.org>
- Cc: "'Shane Wiley'" <wileys@yahoo-inc.com>, "'Rob van Eijk'" <rob@blaeu.com>, <public-tracking@w3.org>
- Message-ID: <0fc801ce677a$daaaa2d0$8fffe870$@baycloud.com>
In my view the root of this problem is in using the DNT header to convey signals for 2 situations. 1. The user has specified a general preference not to be tracked. 2. Independent of 1, the use has given consent to be tracked by a particular data controller. This covers both consent to a first-party site (and perhaps its embedded third-parties), and consent to be tracked by a particular-third party anywhere (aka web-wide UGE). 1 is irrelevant in Europe because we have a fundamental right (not to have personal data collected without consent) and law to guarantee that. Arguments about how to be sure it has been set purposely by the user and what its default state should be can be limited to non-EU participants and need not affect the requirement for 2. Also, we should not use the word "exception" for situation 2. This is independent of the general preference so needs not be defined as an "exception" to it. As has been pointed out by David Singer, the word has a particular meaning for the logic of program flow and its use here is confusing. It would be better to call this the "Consent signal", although in general any mechanism to convey it should be extensible to more than this limited (and yet undefined!) meaning. We should have non-normative text as Matthias has suggested, but it needs to cover the very common use-case of a single data controller responsible for an estate of many distinct domains. We have already discussed this but not agreed on a solution for it within the TPE. Because the DNT signal is limited to a single tri-state (1,0 or unset), and does not even have mechanisms for sunset revocation, this situation, and perhaps others, will continue to require some other mechanism, probably based on cookies or localStorage. This mechanism could not be simply one-off to be overridden by a UGE because the fact that consent had been acquired by the data controller could not be encoded in the DNT header (there is not enough bits) and so OOB consent would have to be permanently relied upon. If we had the luxury to fix this by adding to the TPE now I would propose we build on the existing cookie standard. The HTTP cookie mechanism covers most of the requirements for a Consent Signal, in fact this is what we usually mean when we talk of OOB consent (or OOBE). The TPE would only need to extend the mechanism slightly in order for it to be used for our purpose, i.e. to enable top origin domain script to set short duration cookies in the context origin of embedded third-parties (so distributary HTTP requests will include it in the cookie header, but it would not apply to other contexts). To ensure transparency we could specify the name of the (consent signalling) cookie and how its value was encoded. A properly formatted consent cookie would override a DNT:1 signal and would be site-specific. Mike From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org] Sent: 12 June 2013 09:21 To: Nicholas Doty Cc: Shane Wiley; Rob van Eijk; public-tracking@w3.org (public-tracking@w3.org) Subject: Re: Batch closing of TPE related issues 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)" <mailto:mts-std@schunter.org> <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> 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> 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> 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> 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> 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 14:41:34 UTC