Restrictions on interest group JS processing power/memory usages

[BasileLeparmentier]

The interest group preloaded JavaScript code has many purposes such as:

• Computing the bid, with the help of the trusted server. With the trusted server not receiving any contextual signal expect for the domain, a significant share of these models will have to run on the user devices.
• Handling brand safety, meaning to have an allowlist of every domain it is working with (and potentially subdomains). This list alone might be huge.
• Handling the creative choice, and potentially even the full ad bundle in the long run.
• It also contains user signals, report_win function, etc.

This means that, even with the help of trusted servers, this bundle could very quickly be extremely large, even without accounting for CPU usages.

This seems infeasible, especially as we expect every browser to have multiple interest group (in the order of thousands, maybe more).

What constraints does Chrome envision for these JS bundles? Size? Maximum computing power? Number of JS bundles per owner?

How will they be enforced (first come, first served?)?

[JensenPaul]

What constraints does Chrome envision for these JS bundles? Size? Maximum computing power? Number of JS bundles per owner?

runAdAuction() now supports several controls (e.g. perBuyerGroupLimits) and timeouts (e.g. perBuyerTimeouts and perBuyerCumulativeTimeouts).

How will they be enforced (first come, first served?)?

Buyers can prioritize their interest groups statically (e.g. priority field) or dynamically (e.g. priorityVector field).