RE: Batch closing of TPE related issues

Matthias,

I’m fine with the CACHING approach (some edits to remove the concept of “sharing”) but disagree on the bar on the co-use of UGE and OOBC.  As I highlighted in the last email, I believe we should use the flag we discussed in Bellevue when an UGE entry is linked to an OOBC.  This will provide the needed transparency to the user and point them back to the control mechanism for that OOBC.

CACHING
- Sites may cache their own UGE status with a user and use this status in situations where the Site cannot speak to the UA directly
- If Sites receive updated information on the next interaction with the UA, they need to refresh this cached information

INTERPLAY
- Sites may register UGE as part of an OOBC event with a user but this MUST be associated with the OOBC flag for appropriate transparency to the user
- UGE entries with the OOBC flag MUST be accompanied by a link to the Site control mechanism for that OOBC
- If a user clears their UGE entries, UAs SHOULD notify the user if they have OOBC flags for any entries as these MAY be rewritten on the next interaction with that Site

- Shane

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: Wednesday, June 12, 2013 8:31 AM
To: public-tracking@w3.org
Subject: Re: Batch closing of TPE related issues

Hi Shane,

thanks for the clarification. Now I understand your use case better.

How about language along those lines:

CACHING
- Sites may cache and pass on UGE's to other servers
- If they receive updated information, they need to refresh this cached information and need to inform the other servers

INTERPLAY
- Sites should avoid using OOBC (out of band consent) and UGE concurrently for the same user,
   i.e. if UGE is stored in a browser, then UUBC should be invalidated and
   if OOBC is used (and the user is aware of this), then UGE should be removed


Opinions/Feedback?

Matthias

On 12/06/2013 16:06, Shane Wiley wrote:
[+ Public Tracking Mail List – (with Matthias’ permission)]

Matthias,

Thank you for the quick response.  Please see my comments below:

- Shane

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: Wednesday, June 12, 2013 1:14 AM
To: Shane Wiley
Subject: Re: Batch closing of TPE related issues

Hi Shane,

thanks for your input!

It sounds like I would consider this scenario "caching" (which we should discuss).


[If you’d like to refer to this as “caching” I’m fine with that.]

I believe that there is no scenario where the server cannot talk to the UA:
[Disagree – we’ve already outlined that S2S (server-to-server) communications will not have the option to speak to the UA directly.]
we assume that all requests are accompanied by a DNT;1 or DNT;0 (controlled by the UGE). I.e., if a server receives DNT;1 and cannot talk to the UA, then you either need to accept the DNT;1, trigger the exception mechanism again, and (if this does not work), go for an explicit out of band exception in a transparent fashion "Your UA does not support DNT, is it OK to personalise this page". In this scenario there is no need for removing the UGE since the UA sent DNT;1 (which should indicate that there was no UGE in the first place).


[Disagree – this is a valid marketplace situation that needs to be addressed.  Attempting to FORCE compliance when a Server knows otherwise will drive down adoption significantly.  In this scenario (and we are speaking about a single, narrow use case) the Server in this scenario has already requested an exception and has been granted one.  The issue here is that the Server with the UGE is unable to speak to the UA directly to confirm the fact so it needs to rely on its best knowledge at that time.]
My main concern is that the UA should always trump the server, i.e., if a UGE was present at some time
then the server can cache this information (I would not call this an out of band exception).
If the UGE is now deleted (i.e., the same UA visited you with DNT;1 and you no longer find this UGE), then you need to update your cache.


[Agreed – at the very next interaction with the UA, the Server should update its UGE setting within its own cookie if the user has in fact removed it.]

I believe that "refreshing" the UGE based on the information you cached earlier raises privacy concerns since it voids the benefits of "transparency" (user knows what UGE have been granted) and "control" (user can control UGE).


[It’s the other way around – the Server “cache” (to use your term) would be updated on next interaction with the UA.  The UA always trumps when you can finally speak to it (outside of OOBC).]

What I believe is OK is to convert an UGE into an out-of-band exception by
  (a) Removing the UGE
  (b) Explicitly asking for out of band consent.


[Disagree – forcing OOBC to have a weaker persistence state than the DNT signal is not fair.  UGE is meant to be the mechanism that brings parity to this situation.]

btw: If you like, feel free to send parts of this conversation to the public mailing list.


[I’ll move the entire chain to the public list now.  Thank you Matthias.]


Regards,
matthias



On 11/06/2013 18:34, Shane Wiley wrote:
Matthias,

This is a singular use case.  If a Server is able to obtain a signal from the UA, that trumps.  In cases where the Server is unable to speak to the UA, then they are able to rely on their own signal they may have stored during the UGE event.  Fair?

- Shane

From: Matthias Schunter (Intel Corporation) [mailto:mts-std@schunter.org]
Sent: Monday, June 10, 2013 11:41 PM
To: Shane Wiley
Subject: Re: Batch closing of TPE related issues

Hi Shane,

Why should a user agent (and a user) offer this additional storing capability, if it does not give the user control over their exceptions?
I believe that UGE and out-of-band exceptions should be mutually exclusive, i.e., if you claim an out-of-band exception, you should delete the UGE.
To avoid giving users the impression that they have control (which in this case, they no longer have).

matthias




On 10/06/2013 16:41, Shane Wiley 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<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