- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 7 Mar 2012 00:39:56 -0800
- To: Shane Wiley <wileys@yahoo-inc.com>
- Cc: Tracking Protection Working Group WG <public-tracking@w3.org>
On Mar 6, 2012, at 8:15 PM, Shane Wiley wrote: > Roy, > > I disagree as many of the publishers I've spoken with do know the 3rd parties we expect to have present on our websites so knowing some of these are blocking prior to serving a page is very helpful in deciding how to assemble that page - including either adding more ads or only adding page calls for those 3rd parties that have exceptions. > > While this could occur after the initial page load (session start), why would it be difficult to allow this up-front prior to the start of the session? I agree that the publisher needs that information, but the way in which you are proposing to get it simply will not work. You are asking the browser to know that it has exceptions up front, before it makes the first request. The browser would have to know the list of third-parties on that page (or the site's current list of all dependencies) in order to change from DNT:1 to DNT:2 for the page request. Even if the browser has previously requested site-specific exceptions for that first-party and is willing to look them up before each request to a first-party, it still wouldn't know if that list is current or if all of the third-parties on that list are required for a specific page. As Kevin mentioned, it is possible for the set of third parties used by a page to change, dynamically, based on other personalization. For example, our own CMS product (Adobe CQ5) is fully capable of reorganizing the page, including changing the frames that load advertising, based on which part of the browser window the user's pointer happens to reside during page load. The only way that the browser can know the list up front is if they make a special pre-request to the first-party to obtain the list of third-parties for the next page they are about to request and then lookup each of those domains in its exception list. That simply is not going to happen because: 1) in some cases, the first-party doesn't know until the browser context is tested; 2) it adds an extra round of latency; and, 3) doing so provides no benefit to the user (it fails basic Internet economics -- browsers don't implement things that are only good for servers). What we can do instead, when DNT is enabled for the page, is make a javascript call for the exceptions on all third-parties as an array and require a boolean return value if any of those domains do not have an exception. I think this would avoid the fingerprinting risk and still allow the server to know if one or more of its dependencies is blocked from tracking. Note that this still won't work for clients that have javascript disabled or which intentionally fail to return a true value for this call, but I think we can deal with those issues via other means. I am not saying that this is an ideal situation for first-party publishers. It might be easier for them to simply assume that at least one of those dependencies will be blocked and instead serve the ugly version of the page with dynamic overlays that are rendered only after each subrequest succeeds. ....Roy
Received on Wednesday, 7 March 2012 08:40:28 UTC