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

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?

Thank you,
- Shane

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Tuesday, March 06, 2012 5:53 PM
To: Shane Wiley
Cc: Matthias Schunter; public-tracking@w3.org
Subject: Re: ACTION-98: Bring input on ISSUE-111 to the group; otherwise it's closed

I do not believe it is feasible for the first-party to be informed that
there are exceptions on some of its third-party dependencies before the
client knows what subrequests are going to be made for the page, since
the client does not know that until long after it gets the response to
the request in which it was supposed to send DNT:2.

At best, the server could be informed that the client has decided to block
some third-party sites, sometimes, and I don't think that is useful.
Furthermore, I think that user agents would lie about that setting on
the basis of their configuration being private, so it could not be relied
upon by sites regardless.

Hence, I think the only solution to this issue is via a javascript API
that can be checked by the first-party page after it has been received.
Such javascript if fully capable of adjusting the site after-the-fact
to sufficiently monetize the content, either through dynamic adjustment
of the DOM or by simply redirecting the user to a site hierarchy that
is designed for non-tracking users.

....Roy

Received on Wednesday, 7 March 2012 04:17:38 UTC