You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 7, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 7, 2025. It is now read-only.
Relaxing same-origin constraint on Interest Group resources #421
In the current implementation of FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl and trustedBiddingSignalsUrl must have the same origin as the interest group owner.
The Fledge Explainer states that this may not be a long term constraint but does not provide a timeline for when this constraint may be lifted.
Ask
Clarify if and when this requirement will be lifted
Why is this needed
Requiring these Urls to have the same origin as the interest group owner causes some architectural constraints on ad-tech implementations for Fledge. Below are some example use-cases that this requirement is blocking
biddingLogic and biddingWasmHelper urls. The assets served by these endpoints are fairly static and could be served by a CDN to optimize for request latency, but this is not possible with the same-origin requirement.
trustedBiddingSignalsUrl In the trusted server model, a request is made from the client directly to the Trusted Execution Environment. This suggests that the trusted server needs its own origin, separate from the interest group owner’s origin.
These are needed because we're exposing the results from one site to another - we could, of course, just use CORS, though there are questions of what site is the initiator, since there are multiple parties involved (publisher page initiated the auction, the "owner" is the source of all URLs. The results of the requests are being exposed to the bidding logic URL).
I don't think anyone has invested time in figuring out just want sort of "this cross-site request is OK to expose to this third party" signal we need to allow this.
(Aside from the considerations that Matt mentioned,) If these resources can come from a site other than the IG owner's, then there is a risk of someone creating an IG with, say, your bidding script but their KV server — in which case you would bid using corrupted input data created by an attacker.
tylerdev0: Note that issue #813 has a lot of activity, and is about largely the same thing (It's more focused on the specific case of same-site but cross-origin, though solutions would potentially be the same). Probably a good idea to chime in there if you still have opinions on the subject.
Activity
MattMenke2 commentedon Dec 16, 2022
These are needed because we're exposing the results from one site to another - we could, of course, just use CORS, though there are questions of what site is the initiator, since there are multiple parties involved (publisher page initiated the auction, the "owner" is the source of all URLs. The results of the requests are being exposed to the bidding logic URL).
I don't think anyone has invested time in figuring out just want sort of "this cross-site request is OK to expose to this third party" signal we need to allow this.
michaelkleber commentedon Dec 17, 2022
(Aside from the considerations that Matt mentioned,) If these resources can come from a site other than the IG owner's, then there is a risk of someone creating an IG with, say, your bidding script but their KV server — in which case you would bid using corrupted input data created by an attacker.
MattMenke2 commentedon Mar 14, 2024
tylerdev0: Note that issue #813 has a lot of activity, and is about largely the same thing (It's more focused on the specific case of same-site but cross-origin, though solutions would potentially be the same). Probably a good idea to chime in there if you still have opinions on the subject.