- From: <mts-std@schunter.org>
- Date: Thu, 31 Jan 2013 05:06:17 -0800
- To: "Nicholas Doty" <npdoty@w3.org>
- Cc: "David Singer" <singer@apple.com>, "Matthias Schunter (Intel Corporation)" <mts-std@schunter.org>, "Jonathan Mayer" <jmayer@stanford.edu>, "Shane Wiley" <wileys@yahoo-inc.com>, "public-tracking@w3.org (public-tracking@w3.org)" <public-tracking@w3.org>
Hi Nick, Thanks a lot for this input. This was exactly what I had in mind when I asked for “substantiated objections or concerns”. To paraphrase your point (please correct me if I understood wrongly): - You assumed that: - We choose the new exception model where sites “store” exceptions that they have obtained from a user - While browsers MAY validate the exception to be stored with the user most browsers do not implement this validation with the user Under these two assumptions, sites have a strong incentive to “just store an exception” to increase the revenue they obtain from third parties (either maliciously or through negligence such as copy/past of a piece of Javascript). This behaviour will then undermine the trust into DNT (similar to the copy/paste of the compact P3P policies in the past) and will make the DNT;0 signals unreliable for third parties. I suggest we schedule a session in Boston where we discuss how we can mitigate this risk (and other risks that people see with the new exception model. Regards, Matthias > 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. > >
Received on Thursday, 31 January 2013 13:06:40 UTC