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

Re: ACTION-98: Bring input on ISSUE-111 to the group; otherwise it's closed

From: Nicholas Doty <npdoty@w3.org>
Date: Tue, 21 Feb 2012 22:05:29 -0800
Cc: Matthias Schunter <mts@zurich.ibm.com>, Tracking Protection Working Group WG <public-tracking@w3.org>
Message-Id: <6D809DDB-AE04-43DB-8665-6E4FDCD53C9D@w3.org>
To: Shane Wiley <wileys@yahoo-inc.com>
Hi Shane,

On Feb 21, 2012, at 8:03 PM, Shane Wiley wrote:

> I disagree as this will require polling for site-specific exceptions when itís not necessary (several use cases brought up by the working group where DNT:2 solves similar issues).  Why are you against a browser sending a 1st party the DNT:2 message when that party has site-specific exceptions recorded for their domain?  As browsers will be broadcasting a DNT value (if one exists), then it appears to be better for publishers if a DNT:2 message is sent in those cases where itís appropriate (versus receiving a DNT:1 value and then needing to poll every single time to see if exceptions exist).

I was just providing an alternative that I hoped would be simpler, since it seemed like we were using JavaScript to check for exceptions already and sites would need to continue to do so. Many exceptions that a user configures (or that a user agent infers) may not be pre-determined when making the first request to a publisher. As I've mentioned before, I'm uncertain about the polling concern since this isn't necessarily incurring network traffic, it would just be use of JavaScript on the client.

> Iím hopeful either companies that build web browser or publishers can provide their view points on this issue as weíre the entities impacted by the outcome here.

Yes, absolutely! I was drawing inferences from other conversations I've had with browser vendors that suggested that fewer values and requirements here would ease adoption, but I'm not intending to speak for them, just to list an alternate proposal.

Received on Wednesday, 22 February 2012 06:05:35 UTC

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