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