RE: Batch closing of TPE related issues

[+ 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