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

Roy,

Please follow this flow of logic and please help me understand where I'm breaking down technically:

First - it's important to distinguish between a user that allows all tracking (DNT:0) as opposed to a user that generally disallows all tracking but has provided an exception to your site (DNT:2).

With this "rule" in place, here is the flow:

-   If DNT:1, publisher will redirect user to site-specific exception request process (can make this page redirect on the fly based on the initial page request - does not need to be stateful).  If user says "NO" - then publisher will need to determine how to proceed (based on the sample list I provided in another email).
-  If DNT:0, publisher does nothing

Exception Use Case:
-  If DNT:2, publisher will know they were provided a previous site-specific exception for some or all of their 3rd parties (in this use case, this publisher always requests exceptions for ALL of its current 3rd parties)
-  Taking on the risk of the user possibly manually editing their site-specific exceptions for said publisher, the publisher can now proceed with treating the user the same as DNT:0 but may decide to also poll for the site-specific exceptions again to confirm any "new" 3rd parties they support have been added to the exceptions list.
-  Like most publishers, we don't add 3rd parties very often (a few per quarter at most, and we're removing just as many typically at the same time) so the decision to re-poll will be rare and would be beneficial to occur from the server side (understood that this causes a slight delay in serving the page but will again be rare so hopefully not as noticeable to a user)
-  If after polling it becomes clear a number of 3rd parties require site-specific exceptions, the user can be redirected (server-side) to the site-specific exceptions experience 

This could also be accomplished on the client-side (user agent API call in header - delay loading rest of page until user DNT status and exceptions determined - client-side redirect if necessary) but this becomes a much more expensive solution as I need to add this code to every single page of the website versus have a single server-side process.

If the only issue you see is that server-side polling may slow down the user experience, I believe the rarity of that polling covers the concern and allows for an easier implementation.

Thoughts?

Thank you,
Shane

-----Original Message-----
From: Roy T. Fielding [mailto:fielding@gbiv.com] 
Sent: Wednesday, March 07, 2012 3:40 AM
To: Shane Wiley
Cc: Tracking Protection Working Group WG
Subject: 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 12:41:31 UTC