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 17:42:38 UTC