RE: Batch closing of TPE related issues

Matthias,

I've posted our side conversation to the mailing list.

OOBC (out-of-band consent) is the master rule in all cases - even if the signal is then set within the UGE structure to bring persistence parity to the DNT and UGE signals.

In Bellevue we had agreed to place a flag on UGE signals to enumerate if they were OOBC centric - with a link back to the Server control for the user to exercise their choice going forward.  I'm not sure how this concept was lost but I'd ask we put that back in place.  This will allow UAs to appropriately convey to a user that they store a "copy" of the OOBC signal but point back to the true source for control.

Non-OOBC UGEs would be stored in the UA for direct management (as we've always agreed).

- Shane

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: Wednesday, June 12, 2013 1:21 AM
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<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