W3C home > Mailing lists > Public > public-tracking@w3.org > June 2013

Re: Batch closing of TPE related issues

From: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>
Date: Wed, 12 Jun 2013 17:30:45 +0200
Message-ID: <51B89425.2@schunter.org>
To: public-tracking@w3.org
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 serverreceives 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 supportDNT, 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
>
>               
>
>               
>
>               
>
>               
>
>               
>
>               
>
Received on Wednesday, 12 June 2013 15:31:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:39:41 UTC