Question on Auction, Bidding and Reporting Worklets

[myonlinematters]

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]

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]

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]

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]

@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]

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