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

Nick,

Thank you for the thoughtful exploration of incentives for allowing exception setting from Servers.  I thought we as a working group had originally agreed that if a Site has collected out-of-band (OOB) consent from a user, that they could proactively store this in the UA for appropriate relay on subsequent interactions.  Weren't you supportive of that position?  If so, I'm curious how this process changes that?

There is little incentive for Sites to adopt DNT if direct consent mechanisms are second questioned by the UA as they will not be able to relay the context and value exchange messaging in which the consent was originally captured (basically, a Site would be opening up its direct consent with users to a UA confirmation).  As each exception transaction is recorded, it is readily available for advocates and regulators to interrogate for appropriate processing and informed consent.  This continues to be an exercise in burdening the rest of the ecosystem to attempt to weed out bad actors that will likely not implement DNT in the first place.  The edge cases you've explored are just that - edge cases - and we should avoid developing remedies to those situations at the cost of the entire standard.

There is a chain of dependencies within the Site, UA, and User ecosystem to develop trust in DNT.  The first step is that each party desire implementing the standard in the first place.  If very few Sites implement DNT in the first place, then User trust will not develop.  I believe we'll see self-regulation step up globally to wipe out the edge-cases you've outlined.

I would ask the working group to continue to avoid overburdening and disintermediating Sites from their Users in this standard.  The current proposal for allowing Sites to register user granted exceptions in the UA is the right course, is supported by many/most in the working group, and will drive higher adoption of the DNT standard - the first step needed to drive User trust in the utility and confidence in DNT.

- Shane

<Thought Exploration:  We could support both consent approaches if we desire - one based on Site Consent and the other on UA Consent.  If Sites obtain consent directly, we keep the current proposal to allow direct exception entry in the UA.  If a Site would rather not build this functionality, they can pass the Exception Request to the UA for handling.  I believe the feeling in the group was that very few Sites would trust UAs to provide this experience in a balanced manner and therefore it would receive little, if any, adoption.  So why build it in the first place?>

From: Nicholas Doty [mailto:npdoty@w3.org]
Sent: Thursday, January 31, 2013 3:04 AM
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<mailto: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<mailto: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<mailto:public-tracking@w3.org> (public-tracking@w3.org<mailto: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<mailto: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.