cross-site group management iframe tracking vector

[zerth]

In #58 (@appascoe's TERN update PR) there was some discussion of a desire to manage interest groups as part of contextual responses. I.E., when a DSP provides a contextual bid response, it should have the ability to also specify additional desired interest groups for the user to join (perhaps under certain conditions such as winning the final auction, or at random).

The PR originally provided a facility for DSP responses to include group management information (now removed and to be followed up separately); @michaelkleber pointed out that this could lead to interference since no means were specified for the UA to verify authenticity, and suggested that cross-site iframes are already anticipated in TURTLEDOVE as supporting this use case.

As I wrote in this comment, I think this would represent a cross-site tracking vector unless some additional specifications are made.

Here is the scenario I imagine:

• publisher-1.example integrates with ssp.example
• publisher-2.example integrates with ssp.example
• ssp.example conveys to DSPs contextual bid requests, but either claims IP-blindness with respect to DSPs and doesn't pass user IP addresses, or passes only a privacy-masked IP for rough geolocation (in line with practices today)
• dsp.example integrates with ssp.example as a buyer
• dsp.example integrates with advertiser.example

1. User A visits publisher-1.example/10-facts-about-cats. Assuming ssp.example does not pass user IP addresses to DSPs, dsp.example receives a contextual bid request with information about the page, plus any first-party information publisher-1.example decides to provide, but no other definite cross-site information about user A.

   dsp.example now knows the following about user A:

   cross-site id	first party id	page view
   ?	A1234	publisher-1.example/10-facts-about-cats

2. As part of its contextual response, dsp.example instructs ssp.example to create a cross-site iframe with src="dsp.example/add_to_interest_groups?token=<some_token>". some_token is either a unique id associated with the original request or otherwise somehow directly associated with the original page context.

3. At some point the UA will activate that iframe. It will load a DSP-specified resource, which as part of (2) will include information about the original context, and so any fingerprinting surfaces such as IP become directly available to the DSP and linkable to cross-site behavior.

   dsp.example now knows the following (imagine IP+FLoC cohort as a semi-stable mostly-unique ID, though even IP alone may suffice as a noisier 3p cookie substitute):

   cross-site id	first party id	page view
   (1.1.1.1, AX3Y)	A1234	publisher-1.example/10-facts-about-cats

4. User A visits advertiser.example/premium-dog-toys, then visits publisher-2.example/10-facts-about-dogs. The contextual response iframe eventually activates. Extending the above, dsp.example now knows the following:

   cross-site id	first party id	page view
   (1.1.1.1, AX3Y)	A1234	publisher-1.example/10-facts-about-cats
   (1.1.1.1, AX3Y)	C3333	advertiser.example/premium-dog-toys
   (1.1.1.1, AX3Y)	B4321	publisher-2.example/10-facts-about-dogs

   I.E., it is able to build a cross-site profile despite having only been provided with first-party and contextual information.

5. User A later visits publisher-1 again. dsp.example can look up the first-party id A1234 and access the user's cross-site history for all pages which had a cross-site iframe activation (advertisers and publishers), without any collusion between any parties.

One reason to distinguish between an SSP vs a DSP being exposed to fingerprinting surfaces such as IP is that there are far fewer entities to potentially audit for IP-blindness if limited to SSPs.

I see a number of possible resolutions here, but am first curious what you think of this scenario.

[michaelkleber]

Hi Mike, thanks for the clear write-up of the privacy threat you're thinking about.

It looks to me like this has nothing to do with TURTLEDOVE's interest groups specifically, and instead a DSP could carry out this same attack any time it gets to load any resource on the user's device. For example, the inclusion of a "cookie matching pixels" in the winning contextualy-targeted creative, with a URL parameter indicating the event-id of the ad auction, would get us to the same place.

From the Privacy Sandbox point of view, the answer is that we need to prevent device fingerprinting as part of our work on mitigating workarounds. This is true whether the actor in question is a DSP, an SSP, or any other party.

I see a number of possible resolutions here, but am first curious what you think of this scenario.

I'm happy to hear what you have in mind! But this isn't just a targeted threat from DPSs, it's a pervasive part of the privacy protection effort.

[zerth]

@michaelkleber: Thanks; my main concern was nailing down that despite a scenario like the above, you wouldn't change your stance that iframes on the owning origin are the TURTLEDOVE-style solution here. I.E., that cross-site management of interest groups shouldn't be further restricted in some way, and that these and similar attacks will be mitigated elsewhere but not by changing this aspect of (your stance on TERN vs) TURTLEDOVE.

[michaelkleber]

Yup! We're on the same page.