RE: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)

Before we resurrect this topic, can we please address the fact that it would only work in a very minimal set of use cases and make sure it is worth our time.

This API only has value if we allow partial exceptions (to some but not all 3rd parties on a site).  As I have stated in other threads, there are many many problems with allowing partial exceptions.  There are also real privacy and business incentives to do so, and so it may be worth trying to work through some of the problems.  However, there is a single core problem that would need to be solved prior to considering any of the additional work which is:  How do you request exceptions for a potentially ever changing, dynamic, unknown list of 3rd parties which make up common advertising chains.

The cnn example below simply does not work.  It is worthless to grant doubleclick (more accurately DFP) an exception because doubleclick usually does not serve the ads.  The publisher's ad server's responsibility is to find the ads which will yield the highest CPM for the publisher.  The process of doing so may involve several different services and redirects, and these services may change per user, per page or even per time of day.  Granting doubleclick the ability to track does not grant them the ability to perform their task unless the other steps in the chain also have an exception.

I am sure there are simple scenarios in which the 1st party will know all 3rd parties and may be willing to offer variable content based on which 3rd parties have exceptions.  I think before we talk about changing the functionality we should list some of these scenarios and determine whether it is worth our time or the browser's time to implement the API.

On a side note - if we can satisfactorily answer the above questions and feel that we do want to move forward with it, I agree with Jonathon that we can do so in a way which does not carry strong fingerprinting risks.  I think Jonathon's proposal would work.

-kevin

-----Original Message-----
From: Jonathan Mayer [mailto:jmayer@stanford.edu] 
Sent: Wednesday, March 14, 2012 11:42 AM
To: Tracking Protection Working Group WG
Subject: A First-Party List API for Site-Specific Exceptions (ISSUE-59, ISSUE-109, ISSUE-111, ISSUE-113, ISSUE-114)

There have been renewed expressions of interest in a first-party API that lists which third parties have an exception.  Rationales include making it easy and fast for a first party to learn about exceptions (relative to alternatives that use existing web technology) and facilitating non-blanket exceptions and possibly third-party blacklisting by users.

The proposed siteSpecificTrackingExceptions API did just this; it was removed out of concern for third-party fingerprinting.  I'd like to bring back the proposal, but limit access to script running in the context of a top-level (first-party) origin.  Browsers already have the necessary building blocks; they know the top-level origin and the context origin associated with script execution.

Here's a concrete example: A CNN visitor has granted a web-wide exception to Google ("*", "doubleclick.net"), but nobody else.  When a cnn.com script calls navigator.siteSpecificTrackingExceptions, it gets back ["doubleclick.net"].  If a yahoo.com script calls navigator.siteSpecificTrackingExceptions, it gets no return value, and an error is thrown.

I don't see much marginal privacy risk to including this API.  Third parties already have countless stateful and stateless ways of tracking a browser, including with scripts running in the context of both their own and first-party origins.  This is just another API for compliance monitors to keep tabs on.

As for a first party handing a fingerprintable exception list to a third party, the same reasoning applies.  A first party could just as easily pass a unique identifier (e.g. a first-party ID cookie).  We should be clear in the document that the usual limits on first parties handing data to third parties apply.

Received on Wednesday, 14 March 2012 18:38:51 UTC