RE: Batch closing of TPE related issues

 

In my view the root of this problem is in using the DNT header to convey
signals for 2 situations.

 

1.      The user has specified a general preference not to be tracked.

2.      Independent of 1, the use has given consent to be tracked by a
particular data controller. This covers both consent to a first-party site
(and perhaps its embedded third-parties), and consent to be tracked by a
particular-third party anywhere (aka web-wide UGE). 

 

1 is irrelevant in Europe because we have a fundamental right (not to have
personal data collected without consent) and law to guarantee that.
Arguments about how to be sure it has been set purposely by the user and
what its default state should be can be limited to non-EU participants and
need not affect the requirement for 2.

 

Also, we should not use the word "exception" for situation 2. This is
independent of the general preference so needs not be defined as an
"exception" to it. As has been pointed out by David Singer, the word has a
particular meaning for the logic of program flow and its use here is
confusing. It would be better to call this the "Consent signal", although in
general any mechanism to convey it should be extensible to more than this
limited (and yet undefined!) meaning.

 

We should have non-normative text as Matthias has suggested, but it needs to
cover the very common use-case of a single data controller responsible for
an estate of many distinct domains. We have already discussed this but not
agreed on a solution for it within the TPE. 

 

Because the DNT signal is limited to a single tri-state (1,0 or unset), and
does not even have mechanisms for sunset revocation, this situation, and
perhaps others, will continue to require some other mechanism, probably
based on cookies or localStorage. This mechanism could not be simply one-off
to be overridden by a UGE because the fact that consent had been acquired by
the data controller could not be encoded in the DNT header (there is not
enough bits) and so OOB consent would have to be permanently relied upon.

 

If we had the luxury to fix this by adding to the TPE now I would propose we
build on the existing cookie standard. The HTTP cookie mechanism covers most
of the requirements for a Consent Signal, in fact this is what we usually
mean when we talk of OOB consent (or OOBE). The TPE would only need to
extend the mechanism slightly in order for it to be used for our purpose,
i.e. to enable top origin domain script to set short duration cookies in the
context origin of embedded third-parties (so distributary HTTP requests will
include it in the cookie header, but it would not apply to other contexts).
To ensure transparency we could specify the name of the (consent signalling)
cookie and how its value was encoded. A properly formatted consent cookie
would override a DNT:1 signal and would be site-specific.

 

Mike

 

 

 

 

 

 

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