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

RE: Concerns regarding "store"-style DNT exceptions Re: Batch closing of issues ISSUE-144

From: Mike O'Neill <michael.oneill@baycloud.com>
Date: Thu, 31 Jan 2013 11:52:51 -0000
To: "'Nicholas Doty'" <npdoty@w3.org>
Cc: <public-tracking@w3.org>
Message-ID: <04bc01cdffa9$7fce39f0$7f6aadd0$@baycloud.com>


I agree. User consent is fundamental and we should not undermine its
validity for the sake of convenience. 


The original asynchronous API had the multiple same-party problem i.e. we
should not call for the user to be continually bombarded with another UI for
multiple websites with the same data-controller. But we should not throw the
baby out with the bath water. I suggested one way round that back in
October, and there will be other ways (like using the same-party array) for
doing that.


As I said this is especially important for the web-wide exceptions, but you
have pointed out credible dangers even for the site-specific ones.





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

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

## 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.





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



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.




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



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


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.



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.



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

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?



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

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

Received on Thursday, 31 January 2013 11:53:38 UTC

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