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

Here are a few concrete use cases:

1) A publisher wants to distinguish itself as having good privacy practices.  Instead of requesting a blanket exception, it wants to request exceptions for a small number of well-known third parties.

2) A publisher wants to reflow its layout to exclude widgets and SSO providers that the user has not excepted.  (This was Ian Fette's example.)

3) If certain web-wide exceptions are present, a publisher does not need to ask for new exceptions.

4) A user wants to blacklist a third party in a manner that trumps a site-specific exception.

In all of these scenarios, a first party needs to know the exception status for specific third parties.  There are, broadly, four proposals for how we might facilitate that:

a) polling with existing web technology (e.g. cached JavaScript with a Vary: DNT response header),

b) polling with requestSiteSpecificTrackingException (asks for the exception if not already granted or denied),

c) polling with a dedicated API (e.g. testSiteSpecificTrackingException), and

d) getting a list from a dedicated API (e.g. siteSpecificTrackingExceptions).

Polling approaches, especially (a), will be slower.  A list approach brings greater first-party fingerprinting risk.  (With polling, a first party would have to enumerate domains; that's more difficult, slower, more easily detected, and can be mitigated through frequency capping.)  First-party fingerprinting risk in (c) and (d) could be greatly mitigated by requiring user consent for the API (e.g. "This website would like to learn about your tracking preferences for other websites.  Allow/Deny").

On Mar 14, 2012, at 11:49 AM, Sid Stamm wrote:

> 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 22:15:35 UTC