Interest Groups and Same Origin: Static File CDN Loading

Overview

One of the constraints with PS is the same-origin requirements, in which many attributes of an Interest Group or an auction must be same origin. It's important to note that same origin testing includes subdomains, so that something like cdn.example.com and www.example.com are not same origin. This is enforced at the time of joining an IG, but also at runtime as redirects are rejected.

Many of the implications of this are benign enough, and ultimately expected/reasonable things to do or iterate on nuances with Chrome. However, one key challenge this brings is that both static file endpoints, like bidding and decision logic JS files, as well as service endpoints like trustedBiddingSignalsURL and updateUrl, must be same origin. This effectively removes, or to be technically precise significantly adds to the cost and risk of, using CDNs for static file hosting:

Since they are same origin they must point to the same servers/load-balancers.
Chrome won't redirect for those files.
The load balancers where the traffic originates could proxy the request through to the CDN rather, however...
Since these are the same LBs that receive the dynamic requests, they very likely are co-located in the same data centers as the more dynamic services that rely on the company specific infra (upateUrl and for now trustedBiddingSignalsURL). Since these are high volume/low latency but dynamic services, the connection time and reliability for these services is critical.
Those same LBs managing connections to an external CDN, even one that has been considered highly reliable and performant for years, adds risk and cost to the LBs that handling the more dynamic rquests.
This is not something a sysops team, at least the ones I've talked to, are OK with doing.

Test

So here we try a few different flavors of different sub-domains for the bidding logic.

You can see the JS executing this here.

Conclusion: the same origin test works as expected.