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

Rigo,

I believe this places us on a trajectory where exceptions will not be exercised by Servers if UAs are allowed to second guess agreements between web sites and users.  We're back to the core element of developing a standard web sites will want to implement.  As UAs will not understand the value proposition between the web site and the user that led to consent in the first place, they'll be put in the position of using non-specific terms to validate a user's Exception without context.  I can't imagine any site wanting to allow their user relationships to be disintermediated in this fashion.  This leads us to a pure OOB exception process where the UA is completely removed from the interaction.  UA will send DNT=1 and the Server/Site will process as DNT=0.  The difficulty here is relaying to all 3rd parties on their site that they have received an exception, but perhaps this is accomplished through other means (for example, passing this element in ad calls).  This removes the persistence parity between the DNT setting and the Exception setting - creating in-balance in the solution (and therefore placing more pressure on the W3C's version of DNT being implemented in mass).

I would recommend we keep the current approach (Server set exceptions w/ status response on each page load) in place for the following reasons:
- Balance - allows parity between DNT setting and Exceptions settings
- Transparency - allows the UA to provide full transparency to the user if it desires
- Centralization - allows a user to manage/revoke their Exceptions in a central location if they desire
- Light-weight - removes the need (but allows the option) for pop-up dialogue boxes to confirm user intentions as this has already been managed elsewhere
- Verifiable - this approach records the users exception in a location that can be easily verified by outside parties (users, advocates, regulators) and, when coupled with status responses, creates a full-loop for validation

- Shane

-----Original Message-----
From: Rigo Wenning [mailto:rigo@w3.org] 
Sent: Saturday, February 09, 2013 6:24 AM
To: public-tracking@w3.org
Cc: Nicholas Doty; David Singer; Matthias Schunter (Intel Corporation); Jonathan Mayer; Shane Wiley
Subject: Re: Concerns regarding "store"-style DNT exceptions Re: Batch closing of issues ISSUE-144

Sorry to come in late. I have been too active in other areas. 

I want to support Nick and give one additional argument: 

For the US market, trust may be the key argument. For the regulated markets, DNT will be used to express and record consent. This then can be scrutinized by the DPAs. In fact, a service uses DNT to get clean and create evidence that they were rightly collecting certain data. 

But if our protocol, API and the resulting log and setting is only dependent on the service side without even the possibility (even if only
theoretic) of the user to see/decide/interact, then the log isn't worth a dime anymore. It is just the expression of a wishful thinking of the service. This will not be accepted as evidence IMHO. So I think browsers MUST be able to control the exception store if this is to represent the user's preference. 

Note that this is just a marginal additional argument for the increased value of resulting log files. I'm pretty sure we can find a solution in Boston.

Rigo

On Thursday 31 January 2013 02:03:54 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.
>

Received on Saturday, 9 February 2013 16:49:00 UTC