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

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