Managing owner vs domain in Fledge

[vincent-grosbois]

Hello !
While having a look at the recently merged source code for Chromium, we had a deeper look at how Interest Groups were implemented.
Specifically in this method, we see a lot of checks that compare the "origin" of the Interest Group and for instance the domain of different fields of the interest group (for instance bidding_url). The call to JoinInterestGroup() will fail if both domains are different.

Is our reading of this source code correct ? If so, we are not really understanding how a 3rd party company can manage interest group on behalf of a buyer.
Specifically, the "common" pattern to handle 3rd party adtech company would be that a party that wants to do advertising (let's call it shoeseller.com) will host on its website the javascript code to add visitors to its interest groups. However the "owner" of the interest group would be another company doing advertiser on behalf of the partner (let's call it adtechprovider.com) and host the different bidding function url / update url on its own domain.
In that situation we would have :

• "origin" variable: shoeseller.com
• domain of the bidding function: adtechprovider.com
  And so the call to JoinInterestGroup() would fail

This use-case is very common and is totally something that's supposed to be supported in the Fledge spec.

Can you please clarify if my understanding of the chromium code is correct and would behave like I described ? Did we misunderstand some things?

PS : I'm assuming that this github is the correct place to discuss these issues, please redirect me if it's not the case ;)

[rowan-m]

Hey @vincent-grosbois! I'll dig into this in a bit more detail, but to validate, I think you're referring to this section of the FLEDGE proposal:

The group's owner can indicate permission by joinAdInterestGroup() running in a page or iframe in the owner's domain, and can delegate that permission to any other domains via a list at a .well-known URL.

I will check up on how far along the implementation is. As the origin trial isn't up yet, I wouldn't necessarily expect code to be ready yet either.

[vincent-grosbois]

Indeed I'm referring to this section in the spec.
Basically I wanted to make sure that the checks I mentionned in the code are only "temporary" and that in the future the system of delegating permission to a 3rd party will be implemented.
This system is mandatory for the origin trial, otherwise it means that each website wanting to do advertising will have to host their own bidding logic etc, and that they won't be able to use an Ad Tech Provider 3rd to do this for them.
edit : I think this is the system of "Feature-Policy" HTTP header that needs to be implemented in order to add this function

[samdutton]

Hi Vincent

You've probably seen this already, from the FLEDGE explainer:

The site can allow or deny permission to any or all third parties via a Feature-Policy, where the default policy is to allow all in the top-level page and to deny all in cross-domain iframes. The group's owner can indicate permission by joinAdInterestGroup() running in a page or iframe in the owner's domain, and can delegate that permission to any other domains via a list at a .well-known URL.

The Feature-Policy (Permissions-Policy) and .well-known pieces are not yet implemented (as per your reply).

The "running in a page or iframe in the owner's domain" requirement is currently implemented (as you describe).

So, given the current implementation, the origin joining the interest group must be the same as the origin making the bid. Supporting delegation will extend this as the delegation prescribes.

[vincent-grosbois]

Hello @samdutton , thanks for the reply ! noted, it's not yet implemented.
Let me once mention that for the origin trial of Fledge, all adtech providers will require that the Feature-Policy feature is implemented, otherwise they can't participate

[samdutton]

Thanks Vincent — noted.

[samdutton]

Hi Vincent — just to clarify, are you saying that even with the ability to call joinAdInterestGroup() inside an iframe, the overall proposal is unusable, because you won't be making the call from an iframe?

[vincent-grosbois]

Hi Vincent — just to clarify, are you saying that even with the ability to call joinAdInterestGroup() inside an iframe, the overall proposal is unusable, because you won't be making the call from an iframe?

Hello
I will have to check if we make the call from an iframe or from the domain of the seller directly.
But in any case, I don't think that forcing all adtech providers to adapt their integration so they are forced to use an iframe is going to be feasible.e

[vincent-grosbois]

Hello
I'm coming back to this topic :)
Are we even sure that call joinAdInterestGroup() inside an iframe will even work with the current implementation ? I dont think so.
I mean for instance:

• site shoeseller.com has an iframe whose source is remarketer.com/addFledge.js
• remarketer.com/addFledge.js makes a call to joinAdInterestGroup with an interest group that contains remarketer.com as owner, and all other urls hosted on remarketer.com

Is this supposed to be working with the current permission system ?
edit : seems like it is working with the Canary version !

[vincent-grosbois]

Hello!
Another possibility for Feature-policy would be that instead of requiring the HTTP headers to be equal to some value, that Fledge relies on the content of some file hosted on the advertiser website. Much like .well-known url mechanism described in the proposal. (actually I'm not sure why one permission mechanism is implemented via new header, and the other one via a file on server, seems like both are equivalent functionally)
The reason I'm saying this is that it may be easier for advertiser websites to just add a plain-text file at a given url, than changing the HTTP headers for their whole site to some custom value