Issue-144 etc.

I do not know which issue this should be attached to but it came up in the
last call.

 

If you are a European citizen and visit a European website you expect your
fundamental rights to privacy and data protection to be honoured. You do not
need to set the DNT general preference because you are already protected by
law. The European site is obliged to not gather web history or any other
data without "explicit & informed consent", as reiterated the Data Privacy
Directive and the forthcoming GDP Regulation.

 

The DNT protocol lets the site create a simple consent binary signal, which
can to be augmented in Europe by other mechanisms to enable, for example,
finer granularity for the first party's pages or the automatic revocation of
consent after a sunset period. 

 

But DNT is the only way for consent to be signalled reliably to embedded
third-parties.

 

The usual situation is that the data-controllers of embedded third-parties
are US based and there is usually no contractual relationship between the
first-party data-controller and the third-parties. Script is usually just
copy & pasted. There is no reliable way for the third-party to know that the
user is covered by European law (IPv4 or IPv6 addresses cannot do it) , so
will almost definitely take the view that DNT unset means web history can be
gathered.

 

European sites need to have a standard way to signal not only DNT: 0 but
also that their embedded third-parties must not gather web history even if
the DNT general preference is unset. There only alternative to this is to
remove untrusted third-party elements from their sites.

 

There are many ways to signal this requirement e.g. Url query parameters,
postMessage events, header qualifiers etc., but the simplest and cleanest
way is to actually cause the DNT:1 signal to be sent to third-parties in the
context of the European first-party.

 

What I suggest is an API, exactly analogous to storeTrackingException ,
which causes the DNT:1 header to be included when the general preference is
unset. It would be site-specific rather than web-wide, and entirely up to
the first-party site to implement.

 

Cheers

 

Mike 

 

From: Nicholas Doty [mailto:npdoty@w3.org] 
Sent: 31 January 2013 10:04
To: David Singer; Matthias Schunter (Intel Corporation)
Cc: Jonathan Mayer; Shane Wiley; public-tracking@w3.org
(public-tracking@w3.org)
Subject: Concerns regarding "store"-style DNT exceptions Re: Batch closing
of issues ISSUE-144

 

I've raised concerns (in Amsterdam and on each subsequent call where we've
discussed the proposed exception model), but this thread is a good
opportunity to put them into writing. I will try to be clear and concise.

## Incentives for different parties

As has rightly been pointed out, an entirely malicious third party actor
need not use the exception mechanism to get a DNT: 0 signal sent. But given
the first/third party model we're using, it will not generally be the party
who calls storeTrackingException that receives the DNT: 0 signal. First
party publishers who may receive higher revenue from their third-party
advertising partners for visitors with DNT: 0 would be incentivized to call
storeTrackingException to change the user's expressed preference to DNT: 0
even when the user might not actually want to do so. This could even be a
malicious first party, but might commonly be a first party who
misunderstands (copying and pasting code, as in the P3P CP example) or is
incentivized to be unclear in obtaining consent.

This would be a bad experience for users, who would see their preferences
reversed in potentially surprising ways, and lose faith in the DNT system. 

It would be bad for upstanding third parties who wish to rely on DNT: 0's
affirmative meaning (or even rely on it meaning the absence of DNT: 1). If a
third party wishes to ensure that the exception-granting consent was
sufficiently clear and informed, that third party must investigate every
first party it works with to make sure that storeTrackingException is only
called under appropriate circumstances. We have already seen well-documented
concerns raised about a particular browser vendor's set-up for sending DNT:
1 with suggestions from implementers that certain signals may be ignored. To
allow any site at any time to change a user's expressed preference to DNT: 0
would create a much larger problem of vetting, as the number of first
parties a third party works with is potentially very large in comparison to
the number of major browser vendors. If a third party wants its users and
regulators to be confident that users who turn on DNT: 1 will not be tracked
without explicit consent, it may struggle to take advantage of DNT: 0
signals.

And it would be bad for upstanding first parties who may have competitors
more willing to store tracking exceptions with less clear consent. If a
competitor were able to increase its relative revenue by assuming consent
via the Terms of Service and calling storeTrackingException on every page
load, a first party who uses an interstitial or other more explicit consent
process would be disadvantaged.

## Enforcement via first parties

Can't we just ask the first parties who run this code inappropriately to
stop? Given the number of sites on the Web, detecting and enforcing
incorrect or less-than-ideal first-party uses of storeTrackingException()
calls may not be feasible.

In the case of cookie-blocking policies in Internet Explorer based on P3P
Compact Policy headers, many sites sent invalid or inaccurate headers
without a clear understanding of the implications. These were certainly
detectable cases (research papers were published based on crawling some
portion of the Web), but lawsuits on these grounds have been, as far as I
know, unsuccessful. Furthermore, without a detailed standard on consent
necessary for these exceptions (which we in the WG have been understandably
reluctant to get into), enforcement would be more difficult and less
consistent. 

## User interaction

Under some interpretations of the "store"-style proposal, it would be
non-compliant for a user agent to ask a user to confirm before granting an
exception and changing the user's expressed preference. Even implementations
that allow for post-call revocation would create confusing mixed signals. To
allow or require that the DNT signal be modified without the user's
involvement inevitably casts doubt on the meaning of the signal.

By potentially reducing user control and increasing second-guessing around
DNT: 0 signals, I would be concerned about moving forward with a
"store"-style model for user-agent managed user-granted exceptions.

## Alternatives

Previous drafts of this API have required that the user agent (of which
there are many fewer; which might operate under difference incentives; which
might be configured by the user) would determine with the user whether an
exception should be granted or stored. Involving the user and the user's
agent makes the meaning of DNT: 0 more consistent.

It may be that if the API were constructed in a way that it was possible for
a user agent to confirm exception requests with the user that these concerns
would be less strong. We have discussed this on past calls, but it's not
clear that the store approach can accommodate this.

 

Thanks,

Nick

 

On Jan 22, 2013, at 2:28 PM, David Singer <singer@apple.com> wrote:





Jonathan

 

you're only citing hearsay as opposition. If you have an objection or
concern of your own, could you voice it?  I know Nick Doty has expressed
reservations, but this is otherwise all I have heard.

 

Thank you

 

On Jan 22, 2013, at 22:32 , Jonathan Mayer <jmayer@stanford.edu> wrote:





Advertising participants appear to favor no consent requirements and control
over the exception experience.  Advocates favor well-defined consent rules
and browser intermediation in the exception experience.  A vague consent
standard and primarily third-party control over the exception experience
reflect some measure of compromise from both sides, to be sure, but I'd
hardly characterize it as a "middle ground."

 

At any rate, that's all besides the point.  The group does not have
consensus in favor of the new approach.  ISSUE-144 should not be closed.

 

Jonathan

 

On Tuesday, January 22, 2013 at 1:01 PM, Shane Wiley wrote:

Jonathan,

 

To your points, I believe the middle-ground it appears many agreed to (from
both sides - at least at the last F2F and recent calls/IRC) was:

 

- Consent:  keep the need for explicit consent but don't define this in
granular terms (cuts both ways from an activation / exception perspective)

- Exceptions and UAs:  allow exceptions to be directly recorded but allow
UAs to optionally build verifications systems if they so desire

 

If you disagree with these concessions from both sides, please let the group
know.

 

Thank you,

- Shane

 

From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Tuesday, January 22, 2013 12:38 PM
To: Matthias Schunter (Intel Corporation)
Cc: David Singer; public-tracking@w3.org (public-tracking@w3.org)
Subject: Re: Batch closing of issues (ISSUE-144) [pls Respond by Jan 30]

  

Participants from the advertising industry have raised objections about
standards for consent in the new model.  Advocacy group members have
expressed concerns about removing browser chrome from the exception user
experience.  It seems apparent that we do not have a consensus in favor of
the new approach.

  

Jonathan

On Tuesday, January 22, 2013 at 11:26 AM, Matthias Schunter (Intel
Corporation) wrote:

Hi Jonathan,


I believe that we agree to focus on this new approach:
- Many participants expressed preference for the new approach (while saying
that some fine-tuning is still required)
- All participants "can live with" this new approach

>From a privacy perspective, IMHO it is beneficial that user agents can
validate exceptions 
with the actual user and can keep an (editable) database of all granted
exceptions. Also - due to the fact that less
requirements are imposed on the UA - I believe that UAs can compete and
differentiate more effectively with this new approach.

Opinions?

Regards,
matthias

On 22/01/2013 17:57, Jonathan Mayer wrote:

Do we have a consensus in favor of the new approach to exceptions?  It's
been discussed a lot, but as I recall, some members of the group have
reservations. 

On Tuesday, January 22, 2013 at 3:23 AM, David Singer wrote:

If we close these, I suggest that those that are mentioned in the text get
their mentions removed, specifically:

  

On Jan 21, 2013, at 14:07 , Matthias Schunter (Intel Corporation)
<mts-std@schunter.org> wrote:

  

--------------------------------

ISSUE-144: User-granted Exceptions: Constraints on user agent behavior while
granting and for future requests?

http://www.w3.org/2011/tracking-protection/track/issues/144

  

IMHO, the new approach to exceptions has removed the requirements on the
user agent.

As a consequence, I believe we can close this issue.