Our current architecture keys worklets on all URLs and everything that goes into the trusted signals query param that can't be merged (e.g., slot size, experiment ID). So we currently can't load a worklet without knowing the signals URL, without some architecture rework.

Our caching KVv2 TEE-based implementation could pretty easily work around that, but as long as we're still supporting KVv1, this would require more significant architectural changes to do.

I think it's also worth noting that allowing arbitrary seller signals URLs is a significant leak, even when we're talking to a TEE, since we reveal a lot of timing information, which a unique URL allows to be associated with a specific auction. I would not be surprised if we find we need to lock down the ability to configure these URLs significantly, and instead allow additional data to be passed directly to the TEE.

A bit broader: there is a cost to making things promises, so it's not just a question of whether it can be made one, but whether someone out there actually needs the functionality.

Our current architecture keys worklets on all URLs and everything that goes into the trusted signals query param that can't be merged (e.g., slot size, experiment ID).

I'm going to cross-post re: experiment IDs on #1298 to avoid tangents here regarding other signals.

So we currently can't load a worklet without knowing the signals URL, without some architecture rework.

Can you elaborate how the signals URLs is actually used by the script runners before the actual TSS call to seller is generated?

As I said, it's used as a key. Worklet objects do not have a layer to figure out which requests to the signals URL can be merged, and which cannot, and to track multiple batches of pending signals requests based on that. That's handled by creating multiple worklets instead.

Stepping back, the need to key worklets in the first place is a result of reusing worklets - between interest groups that share parameters, within different components auctions in the same auction, between auctions on the same page. If we don't know the keys that must match in order to reuse the worklet, we can't create the worklet either, since we don't know where to put it in the map, among other things.

As I said, it's used as a key. Worklet objects do not have a layer to figure out which requests to the signals URL can be merged, and which cannot, and to track multiple batches of pending signals requests based on that. That's handled by creating multiple worklets instead.

Ah, so the logic is on the "outside" of the worklets, so to speak.

Stepping back, the need to key worklets in the first place is a result of reusing worklets - between interest groups that share parameters, within different components auctions in the same auction, between auctions on the same page.

For the seller worklets, only the re-use of auctions on the same page comes into play.

If we don't know the keys that must match in order to reuse the worklet, we can't create the worklet either, since we don't know where to put it in the map, among other things.

That makes sense -- I was trying to better understand how "else" a seller worklet could handle the KV call to the trusted scoring signals URL if that wasn't managed "from the outside".

Ah, so the logic is on the "outside" of the worklets, so to speak.

Correct. This is the layer to manage worklet creation, lifetime, and reuse.

Stepping back, the need to key worklets in the first place is a result of reusing worklets - between interest groups that share parameters, within different components auctions in the same auction, between auctions on the same page.

For the seller worklets, only the re-use of auctions on the same page comes into play.

Most likely, yes, though you theoretically could reuse a seller for multiple components within an auction, or for the top-level auction and a component auction.

We could also eventually extend reuse to across pages on the same top-level origin as well, though unclear if that would be worth the investment.