W3C home > Mailing lists > Public > public-tracking@w3.org > August 2012

Re: action-231, issue-153 requirements on other software that sets DNT headers

From: Vinay Goel <vigoel@adobe.com>
Date: Wed, 22 Aug 2012 21:22:18 -0700
To: Justin Brookman <jbrookman@cdt.org>, "public-tracking@w3.org" <public-tracking@w3.org>
Message-ID: <CC5B22C5.11C24%vigoel@adobe.com>
Hi Justin,

You bring up an excellent point that I've been struggling with myself ó on whether a response header to the UA saying 'I refuse to honor this header' is enough.  The problem I'm struggling with is that I don't see a practical way websites can provide more notice in a consistent manner that's helpful to consumers.  I believe the UA could via making available the results of the response header, but thatís a whole-nother discussion.

Here is an example that will hopefully illustrate the challenge.  I believe the site notice paradigm breaks down in at least a few situations: a) where the third party has no direct communication with the consumer, thus being dependent on the website/publisher; and b) when there are multiple third parties on the same page, and the third parties treat headers via IE10 differently.  If we are hoping for quick and widespread adoption, we have to make it relatively easy for the websites to adopt without placing significant challenges/notice requirements.  Note: I am making an assumption that ad firms will be implementing DNT as an all-or-nothing thing; meaning if and how they honor DNT will be for all clients; it will not be managed at a per-client level.  {If ad networks are approaching this in a different manner, please let me know}

Background:
- Both Foo Marketing Co and Bar Marketing Co are site retargeting firms.  Neither company has a consumer-recognizable brand, yet both companies are highly regarded within the ad ecosystem and are members of both the DAA and the NAI
- Acme Retailer has a large online website, and it wants to promote its products on every major publisher
- Acme uses both Foo and Bar to buy targeted display ads on different networks; and so Acme has both Foo and Bar tags on its site
- Foo has stated within its own Privacy Policy that it recognizes the DNT:1 header regardless of the UA; whereas Bar has stated within its own Privacy Policy that it recognizes the DNT:1 header for what it considers compliant browsers (and as such, it would recognize the DNT:1 header for Safari and Firefox but return 'I refuse' for IE10.
- Acme and the publishers that display Acme's ads are the only sites that communicate directly with the consumer; neither Foo nor Bar do

Question:  How is the consumer suppose to understand whether the DNT setting is being honored?
- Perhaps Acme is responsible for setting the policy on what type of DNT recognition it requires of its vendors.  If so, for simplicity sakes when implementing DNT, Acme would either take the lowest common denominator (practice) and state that it refuses IE 10 (since Bar does) or only work with vendors that have the same practice (which limits the website, causing it to question whether to continue to comply with DNT).
- This creates a tricky situation because it will likely lead to all vendors having the same practice, or vendors having different practices but consumers thinking they all have the same.  If Acme does say that it refuses to honor IE 10, but does for retargeting ads bought through Foo, the consumer could claim they were mislead since Bar still could serve them a targeted ad.
- I don't see an easy way for Acme to provide the consumer with completely factual information on what is happening because the two vendors have different practices.  And, by placing requirements on Acme to coordinate/provide vendor-level breakdowns will (my guess) likely place significant burdens on DNT adoption.

Have others thought through how third parties can effectively communicate its implementation details beyond the response header?  If so, please share as I'm struggling to envision one that brings adoption.  And, if we are unable to come up with a good process for this, the knee jerk reaction should not be 'that's why third parties cannot refuse the IE10 setting'.  The reaction should be 'understanding that its likely a large percentage of 3rd parties will refuse the IE10 setting because it is set by default for Express Settings, what's the best way forward to still move adoption rates forward.'

-Vinay
--

Vinay Goel

Privacy Product Manager

Adobe

1540 Broadway - 9th Floor

New York, NY, 10036
917.934.0867 (tel)

From: Justin Brookman <jbrookman@cdt.org<mailto:jbrookman@cdt.org>>
Date: Wednesday, August 22, 2012 11:09 PM
To: "public-tracking@w3.org<mailto:public-tracking@w3.org>" <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Subject: Re: action-231, issue-153 requirements on other software that sets DNT headers
Resent-From: <public-tracking@w3.org<mailto:public-tracking@w3.org>>
Resent-Date: Wednesday, August 22, 2012 11:10 PM

It is simply not true that IE10's header has no meaning.  At the end of the day, for implementers of this specification, IE10's DNT:1 header meaning is whatever this spec says it is.  The problem comes if the spec says that any party gets to subjectively decide what IE10's header means.

To forestall having the same exact argument with you for the nth time, I will reiterate my concession that it may be OK for parties to have different rules for responding to different UAs (including refusing to provide content).  I'm just not sure a response header to the UA that "I refuse to honor this header" without requiring more is sufficiently transparent from the user's persepctive.

Sent via mobile, please excuse curtness and typos


-----Original message-----
From: "Roy T. Fielding" <fielding@gbiv.com<mailto:fielding@gbiv.com>>
To: Justin Brookman <jbrookman@cdt.org<mailto:jbrookman@cdt.org>>
Cc: public-tracking@w3.org<mailto:public-tracking@w3.org>
Sent: Thu, Aug 23, 2012 02:47:38 GMT+00:00
Subject: Re: action-231, issue-153 requirements on other software that sets DNT headers

On Aug 22, 2012, at 5:57 PM, Justin Brookman wrote:

As Shane has said, the key is transparency: you can't just receive a DNT:1 signal and go about your tracking business.

That simply isn't true. DNT sent from MSIE 10.0 has no meaning.
It is equivalent to not sending DNT, as far as "tracking business"
is concerned, whatever we might mean by tracking.

  You have to get permission to track,

Only in certain jurisdictions.

or tell the user you refuse to deliver them content while DNT:1 is on,

That's certainly an option.

or refuse to provide service to the user agent at all.

No, the user agent sent a request.  The site will respond as requested
and do whatever applicable regional laws allow with the data collected.

  I saw a news story recently that Wired is already doing this for just IE10 users --- grant permission to track, or we'll just serve you snippets.  They don't claim that IE10 isn't compliant---rather they presume the validity of the signal---they just say "here are your choices."  Of course, this may not be compliant with European law, but I believe the group had decided that sites could degrade users' experiences who don't grant exceptions.

Removing the DNT signal does not, in any way, impact compliance
with EU laws.

I had been uncomfortable with sites or third parties saying "come back with a different browser" due to allegations of noncompliance, but it helps to consider that they could do it anyway---as long as it's transparent to the user what's going on.

I'll be happy to make removal of the DNT field transparent to the
UA if there is a mechanism to do so.  The UA can choose how to
communicate that to the user.

....Roy

________________________________
Confidentiality Notice: The contents of this e-mail (including any attachments) may be confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited. <ACL>
Received on Thursday, 23 August 2012 04:23:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:38:54 UTC