Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Restrictions on interest group JS processing power/memory usages #132

Closed
BasileLeparmentier opened this issue Mar 3, 2021 · 1 comment
Closed

Restrictions on interest group JS processing power/memory usages #132

BasileLeparmentier opened this issue Mar 3, 2021 · 1 comment

Comments

@BasileLeparmentier
Copy link

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?)?
@p-j-l p-j-l mentioned this issue Mar 24, 2021
Open
@michaelkleber michaelkleber mentioned this issue Apr 12, 2021
Open
@JensenPaul
Copy link
Collaborator

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@JensenPaul @BasileLeparmentier