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

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