Make interestGroup Ownership Clear and Enforceable

[alextcone]

I recently realized interestGroup ownership effectively defaults to ad tech providers, at least in FLEDGE API parlance. This is unfortunate. I say "effectively defaults" because in order for the first party to be the owner of an interestGroup for FLEDGE API they would have to build ad tech. I say "this is unfortunate" because a first party shouldn't have to build its own ad tech to avoid appearing to have assigned interestGroup ownership to a third party. While some first parties might not mind the assignment of ownership (or appearance thereof), others may not like that assignment technically means the assignee can use data collected on the first party's site (or app for the Android version) on behalf of other first parties. To be clear, I'm talking about cases where it's the intention of advertiserA.com working with Ad Tech 123 to build an interestGroup to use only for campaigns on advertiserA.com's behalf. advertiserA.com would not be ok with Ad Tech 123 turning around and using what it collected on advertiserA.com to facilitate a campaign for advertiserB.com.

Some might say this circumstance mirrors how things work today with ad tech SDKs, so why bother with semantics. There are a few reasons.

First, by having a required field for interestGroup called owner, whose only possible values are the first party for that context or an ad tech provider, FLEDGE API makes it appear the first party is assigning ownership to the ad tech when the ad tech's domain is configured as owner. Anyone will be able to read FLEDGE configurations on the client. This could send the wrong message, even if the first party and the ad tech know they have a contract in place saying otherwise. This is a degradation in the already messy way things work today.

Second, we should not miss an opportunity for clarity or privacy. The clarity opportunity is self-evident. The privacy opportunity is to make it less common for ad tech providers to use data collected in the context of one first party for the benefit of another (and themselves). It would become less common because of commercial incentives not to leak data. That would make a difference for privacy because user data from one context would not be reusable by other advertisers or their ad tech providers. There's a reason policy makers are making distinctions between controllers and processors, third parties and service providers.

What to do?

Semantically, there is a straight forward option. Provide a new, optional interestGroup property called delegate. This gives the site (or app in the Android equivalent) a choice whether the ad tech provider is the owner of the interest group or a delegate who can only use the interestGroup on the site's behalf.

Technically, things get a bit more difficult because the browser (or OS) does not validate ad creatives registered with a certain interestGroup to be for a given advertiser. I see a couple options, but I'm sure others could think of more.

1. If delegate field is set with an ad tech provider domain, the browser checks for existing interest groups with that name and that delegate. If > 0 then the configuration would not add a user to that interestGroup on joinInterestGroup and Dev Tools throws an error.
2. @michaelkleber had an interesting idea here I think could be developed more. It's after the fact, but could create incentives to not mislead. Here's the idea for reference:

For example, what would you think of aggregate reporting as a condition of audience-building delegation? That is, give Advertiser A a way to say "Ad Network N can build audiences on my site as long as the resulting interest group sends this URL aggregate reports of what ads it shows."
(And then IGs would need a new "send aggregate reports of which ads you show to the following URL" capability, which we could validate at IG joining time. Hmm, and that URL would need to not be removable via the daily update process, and we need to make sure there's no new privacy leak here, and probably other stuff. So maybe there is enough stuff to think about here that tryptophan-coma-time isn't the ideal design the feature. But the point is, this definitely seems like an entirely reasonable reporting pathway that would make clear the kind of abuse you're worried about, right?)

I would love to hear other ideas. There's an opportunity to make first party data activation with no data value leakage a baked in reality of the web platform and do so in a way that is better for user privacy. Yes, I realize there's no granular user leakage either way...it's value leakage I'm talking about. What say you?

[michaelkleber]

First of all, let me apologize for my choice of the name owner. That word choice predates FLEDGE, or TURTLEDOVE, or even Privacy Sandbox. We've learned a lot since then, and you're quite right that the name has not changed to keep up. I'm supportive of renaming owner, and of adding another field to keep track of another party if needed.

But names aside, I want to make sure we are very clear on what jobs those different parties do. In the current FLEDGE design, the job is "Provide the list of ad creatives and the bidding logic". The bidding logic does seem very much like a job for an ad tech provider. The choice and approval of ad creatives is the place where my suggestion (that you quoted) considered splitting something new out.

What other job do you want the non-ad-tech party to do?

I don't understand your "If > 0" criterion above, so if that is an answer to my question, then please go into some more detail here.

[alextcone]

@michaelkleber writes:

First of all, let me apologize for my choice of the name owner. That word choice predates FLEDGE, or TURTLEDOVE, or even Privacy Sandbox. We've learned a lot since then, and you're quite right that the name has not changed to keep up. I'm supportive of renaming owner, and of adding another field to keep track of another party if needed.

I believe it. I didn't think you did this on purpose. There might be a more elegant way to indicate a first-party's intentions than what I've suggested. I do think, however, a flag could be a key to unlock browser level enforcement over whether an IG can be shared across the ad tech's clients.

@michaelkleber writes:

But names aside, I want to make sure we are very clear on what jobs those different parties do. In the current FLEDGE design, the job is "Provide the list of ad creatives and the bidding logic". The bidding logic does seem very much like a job for an ad tech provider.

Saying who is providing the bidding logic and the creatives is one thing. Saying whether an IG can be shared across sites an assigned owner also represents is another. But I do agree that it needs to be defined who will bring the bidding logic and creatives to FLEDGE auctions.

@michaelkleber writes:

The choice and approval of ad creatives is the place where my suggestion (that you quoted) considered splitting something new out.

As I recall you suggested elsewhere, ad creative approval should not fall on the browser and I completely agree. It's a mess, prone to error and thus requires human support. Perhaps I'm just misunderstanding what I quoted. I understood your idea to be about how the reporting API could show one first party which other first parties were supported by IGs created in part on their site. That's interesting, because if you've asked your ad tech to only use the IG created on your site for your campaigns you could verify if that was the case via post-hoc creative review. There are existing tools today that could pull this in.

@michaelkleber writes:

What other job do you want the non-ad-tech party to do?

It's not about a new job I want the first party to have. It's about the ability for the first party to delegate responsibility of IG creation, bidding, etc... to an ad tech without having to give that ad tech technical carte blanche to reuse the IG for other site's campaigns/bids. I'm not saying FLEDGE should completely disallow this. I'm saying that FLEDGE should, if at all possible, provide flexibility for the first party where the IG is created to keep the IG to themselves even while employing an ad tech provider to bid, etc...

@michaelkleber writes:

I don't understand your "If > 0" criterion above, so if that is an answer to my question, then please go into some more detail here.

Here's what I'm thinking. If there were some way for the browser to check whether the ad tech party has permission to run joinInterestGroup for the same IG across sites you could head off single cross-site IGs at the pass when that was the clear configuration. The desired technical outcome is the browser could determine whether an ad tech has permission to call joinInterestGroup for the same IG across sites or not.

[michaelkleber]

Thanks Alex for the follow-up, I think I understand much better now.

It seems like the basic concept you're reaching for is a limitation on "whether an ad tech can use joinInterestGroup for the same IG across sites". I have a bad feeling that such a limit would not really get at the problem you're trying to solve. It seems to me that if ScummyAdTech can build IGs on both PubA and PubB, then you want it to be clear whether any particular audience is an AdvA-audience, an AdvB-audience, or a cross-advertiser audience. But ScummyAdTech that wanted to hide the fact that they are building one cross-advertiser audience could just as easily build two audiences, one on AdvA and one on AdvB, and then have those two audiences act the same at bidding/rendering time.

That is, it seems like the essence of the problem is when an audience is built on AdvA and then used to run ads for AdvB, without AdvA being involved/aware/willing. (And in particular I don't feel like building the group partly on AdvB does anything to mitigate the badness.)

Solving this problem is absolutely in line with the Privacy Sandbox goals: user privacy should be preserved, and website owners should have transparency and control over what third-parties on their pages can do.

But from my thinking about this issue so far, my instinct is that addressing it needs to focus on how audiences are used, rather than how they are built.

[alextcone]

I haven't formulated a reply yet, but I just saw this pop up on another issue and it reminded me why "owner" terminology and subsequent functionality is going to be important to get right. (Emphasis added)

I mean the IG owner. I don't think we can expose IGs to 3P scripts without buy-in from the IG owner. Using ads generated by the IG owner is the way FLEDGE currently accomplishes that.

source: #319 (comment)

[patmmccann]

In some senses, this appears to be a duplicate of #338

As a setter of IG and a large provider of content, we're also very concerned about having to choose between figuring out how to be a buyer in fledge auctions or delegating that to a party that might use that information on behalf of "advertiserB" in the OP scenario, or unauthorized / unbilled beneficiaries. It would seem one way to solve this is: if Cafemedia, or say Walmart as in #338, sets interest groups but for each interest group it had a file published that was easily revokable that said which advertisers were allowed to advertise to that IG and which dsps were allowed to execute against it, and that could change frequently/.

[alextcone]

@patmmccann, that's interesting. The concern I have is that it would be difficult to keep up to date. That would probably lead to it being delegated from advertiser (or pub in your extension use case) to someone else who perhaps had less concern about advertiser (or pub) 1p data value leakage, or a good story to tell themselves about why it's in everyone's interests to use the IG for others. I do like seeing new ideas for control here though. It's such a key value proposition in my opinion. I'm also happy to be told I'm wrong re: difficulty to keep up to date.

@michaelkleber, this reminds me I never got back to you. Here are a few thoughts:

it seems like the essence of the problem is when an audience is built on AdvA and then used to run ads for AdvB, without AdvA being involved/aware/willing.

I agree this is the problem to be addressed. And it's good to see you feel that problem is inline with Privacy Sandbox goals. That's been my feeling too.

But from my thinking about this issue so far, my instinct is that addressing it needs to focus on how audiences are used, rather than how they are built.

I agree that's what we're solving for. My idea above though is that it may be easiest to address programmatically at the time IGs are built. Addressing it programmatically seems much more desirable than manually and after the fact.

[patmmccann]

@alextcone @michaelkleber We're curious if there is any recent movement on your proposal:

@michaelkleber #399 (comment) I think could be developed more. It's after the fact, but could create incentives to not mislead. Here's the idea for reference:
For example, what would you think of aggregate reporting as a condition of audience-building delegation? That is, give Advertiser A a way to say "Ad Network N can build audiences on my site as long as the resulting interest group sends this URL aggregate reports of what ads it shows."
(And then IGs would need a new "send aggregate reports of which ads you show to the following URL" capability,

We are currently actively considering allowing (or rather continuing to allow...) DSPs to call JAIG from our content to deliver media to a specific advertiser we have a relationship with for this interest group and either revenue sharing or charging them a fee. The report you propose would make us MUCH more comfortable with this decision, as we could validate the impressions delivered by the DSP on the interest group matched what the advertiser saw and we were being paid accurately.

To lay out the use case with something concrete: we have an article about which refrigerator to buy. We call dsp x with instructions to call JAIG for this site. We have a contract with DSP X they either pay us a fixed fee or a percent of media sold on these users. DSP X also has a relationship with refrigerator brand Y. We want to make sure they don't also sell the audience to refrigerator brand Z. We, in collaboration with Brand Y, who we have a contract with, compare the report you propose to the report DSP X provides to Brand Y. If there is more impressions delivered than Brand Y received, we'd know DSP X also sold the interest group to another party.