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

Hi David,

I think we agree and that it is important to spell this out explicitly in
the spec:
- UAs MAY display registered exceptions
- UAs MAY ask users to reconfirm exceptions to be registered
- UAs MAY allow users to modify registered exceptions
- or UAs may use even smarter ways to ensure that the exceptions stored
  are in-line with the actual preferences of the users

I also like the idea to start lightweight (no SHOULD/MUST) and expect that
UAs will later implement additional tooling if they perceive their users
at risk.


> Hi Nick
> I think one of the major problems was being clear who was responsible for
> consent.  Previously, the site had to determine consent, and then the UA
> had to confirm it.
> * That leaves it badly ambiguous; who exactly is responsible for the
> consent?  We don't want the sites and the UA each saying "well, we thought
> the other side was mostly responsible for explaining and getting consent".
>  The new model makes it very clear that the site gets consent, and the
> site has to explain.
> * We all hate "are you sure?" prompts and modal interjections into our
> workflow.  If things work correctly, you've just visited a page at the
> publishing site, and they've explained what an exception is, why you might
> agree, and what the consequences are.  You click the page "yes, I agree"
> button and -- dang it! -- the UA puts up a "please confirm that you agree"
> dialog.  At best, it's annoying, and at worst, the terms and style used
> are sufficiently different that it's more confusing than helpful.
> If we *do* start to see sites that call the exception API
> 'surreptitiously" I would expect to see the UAs do more to expose that.
> They are *allowed* under the new model to (a) reject all calls (b) ask the
> user on all calls (c) expose all calls as a 'warning sign' somehow (d)
> expose the database for editing, either on demand, or after a change, or
> when they like (e) have a list of 'suspicious sites' such that when they
> call, much greater scrutiny is applied, and so on.
> On Jan 31, 2013, at 5:03 , Nicholas Doty <> wrote:
>> 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
> David Singer
> Multimedia and Software Standards, Apple Inc.

Received on Monday, 11 February 2013 17:54:40 UTC