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.

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

Question on Auction, Bidding and Reporting Worklets #1072

Open
myonlinematters opened this issue Mar 4, 2024 · 5 comments
Open

Question on Auction, Bidding and Reporting Worklets #1072

myonlinematters opened this issue Mar 4, 2024 · 5 comments

Comments

@myonlinematters
Copy link

Apologies if this is generally known to the group, but I cannot find any documentation on this:

  1. Is it the intention of the spec that auction, bidding and reporting worklets will become standard worklet types in the HTML specification - for example additions to the table on this page on MDN - https://developer.mozilla.org/en-US/docs/Web/API/Worklet
  2. Are these worklets built off the shared storage worklet (which is still experimental and not in the formal HTML spec) and inherit the stricter security limitation of the shared storage worklet? If not, what type of worklet are they built from?

In the documentation I have gotten through (and admittedly I easily could have missed something in the volume of documentation), there is nothing I found that talks about these worklets in detail and their properties. They are "assumed" in the spec - nothing talks about why or how worklets were chosen (although I think it is pretty obvious after studying worklets). I even asked Gemini to go through all the documentation and the github repositories and look for something like this and it couldn't find anything.

I think there is a need to make this core aspect of the tech clearer for those who will be coming to it after FOT1. But in the meantime, can someone provide me some insight?

@JensenPaul
Copy link
Collaborator

I think you'll find the Script Runners section of the Protected Audience (PA) specification describes how the execution environment that PA bidding and scoring scripts run in differs from the Web's Worklet definition.
WRT your "1." question: due to these differences, I think it's unlikely that PA bidding and scoring Script Runners will become standard worklet types.
WRT your "2." question: PA bidding and scoring Script Runners are not built off of the shared storage worklet or any other worklet.

@myonlinematters
Copy link
Author

myonlinematters commented Mar 4, 2024

So would it make sense to actually use the term script runner for worklet. Isn't that more technically accurate since the actual W3 spec says they are different? Here's an example from the FLEDGE explainer where using the worklet term is confusing:

"All the logic of the on-device auctions will execute inside a collection of dedicated worklets. Each worklet is associated with a single domain, and runs code written by either a buyer or a seller.... We will publish a separate explainer on dedicated worklets."

Change to:

All the logic of the on-device auctions will execute inside a collection of dedicated environments similar to worklets called script runners. Each script runner... blah blah... and so on...We will publish a separate explainer on dedicated script runners for the Protected Audiences API"

Script runners has link to "https://wicg.github.io/turtledove/#script-runner"

@sfindeisen
Copy link

Apologies for hijacking this thread, but I think my issue is close enough. I am interested in worklets aka script runner performance and their basic characteristics. For example: what is the worklet warmup time? Do worklets for the same buyer, seller, interest group or origin execute sequentially or in parallel? What are the limits of parallelization? What are the resources available to each worklet? How does worklet re-use work exactly? How is this related to Interest Group's execution mode? I can see there's a big TODO in the spec on the last one.

Thanks!

@JensenPaul
Copy link
Collaborator

@myonlinematters, yes, we should probably avoid the term worklet in the explainer as it can be misinterpretted.

@sfindeisen, some answers to your questions:

what is the worklet warmup time?

I'm not sure exactly what you mean by "warmup time", but I'm guessing you mean something like the time required to initialize a JavaScript execution environment and setup the arguments to functions like generateBid(). The answer varies widely by device type (e.g. powerful desktop versus battery conscious mobile device), but this is an area we've spent a great deal of time optimizing. The group-by-origin and frozen-context execution modes are examples of such optimizations.

Do worklets for the same buyer, seller, interest group or origin execute sequentially or in parallel?

Generally worklets for the same buyer or seller origin execute sequentially though we are experimenting with making this parallel. The Implementation Overview may be a good reference here.

What are the limits of parallelization?

This greatly depends on hardware resources (e.g. number of CPU cores), but the browser has some limits to ensure reasonable performance. Again the Implementation Overview may be a good reference here.

What are the resources available to each worklet?

I'm not sure which resources you're referring to here. Each worklet executes on one thread, but how those are shared amongst processes is operating system and device specific.

How does worklet re-use work exactly?

I'm not sure which resource you're talking about reusing here. The Implementation Overview may be a good reference here.

How is this related to Interest Group's execution mode?

The Interest Group's execution mode controls whether the browser can reuse a JavaScript execution environment for a particular worklet.

@dmdabbs
Copy link
Contributor

dmdabbs commented Jun 20, 2024

@sfindeisen, while not specific to worklets, you may be interested in the overall auction performance measurements that the good folks at RTB House posted the other day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants