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

I agree with Kevin that we should identify precisely the set of use
cases we're looking to address by resurrecting this idea.

But I still have fingerprinting concerns with the proposal (please help
me understand if I'm wrong).  Even if it's limited to
first-party-context scripts, there's still the ability for first-party
sites to fingerprint using this list-based thing.

The adversaries in my fingerprinting concern are not the sites trying to
do the right thing with the suite of tools we're developing here, but
rather *other* sites that have no intention of being friendly.  I know
our work here is not intended to address "bad actors", but we should not
develop new technologies that make it easier for bad actors to act badly.

I'm worried about shadyfirstpartysite.com re-identifying me based on
things like my browsing history between visits to their site.  I'm
concerned that a first-party list-based API will provide
shadyfirstpartysite.com with more bits of entropy that make it easier to
re-identify me across multiple visits to their site.

I'm sure you will argue that it's already trivial to fingerprint users
if you're a "bad actor", and I concede that point, but if we're going to
make it easier (or a more statistically-strong confidence), we better
have some really good use cases that we cannot get from other, similar
features that don't carry the same fingerprinting "enhancement".

-Sid

On 3/14/12 11:38 AM, Kevin Smith wrote:
> 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:50:26 UTC