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

Proposal for WASM helpers for bidding functions #250

Merged
merged 3 commits into from
Jan 20, 2022

Conversation

morlovich
Copy link
Collaborator

Not sure how to best pass in the module..

@yoavweiss
Copy link
Collaborator

@morlovich - can you join the WICG and link your GH account with your W3C one?

FLEDGE.md Outdated
@@ -201,7 +204,8 @@ The function gets called once for each candidate ad in the auction. The argumen
'adComponents': ['https://cdn.com/ad_component_of_bid',
'https://cdn.com/next_ad_component_of_bid',
...],
'biddingDurationMsec': 12
'biddingDurationMsec': 12,
'wasmHelper': ... /* a WebAssembly.Module object based on interest group's biddingWasmHelperUrl */
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe wasmHelper was mainly intended to help with computing a bid – and if so, should it be passed to generateBid() function?

Copy link
Collaborator Author

@morlovich morlovich Dec 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@yoavweiss: What exactly does joining the WICG mean?

@sbelov: Yes. Thank you. (I totally bookmarked the right position in my editor, and then edited the wrong one. Probably should not operate any heavy machinery today)

(I imagine we may want something like this for scoreAd as well, but one thing at a time).

@@ -109,7 +109,7 @@ The browser will remain in an interest group for only a limited amount of time.

The `userBiddingSignals` is for storage of additional metadata that the owner can use during on-device bidding, and the `trustedBiddingSignals*` attributes provide another mechanism for making real-time data available for use at bidding time.

The `biddingWasmHelperUrl` field is optional, and lets the bidder provide computationally-expensive subroutines in WebAssembly, rather than JavaScript, to be driven from the JavaScript function provided by `biddingLogicUrl`. If provided, it must point to a WebAssembly binary, delivered with a `application/wasm` mimetype. The corresponding `WebAssembly.Module` will be made available by the browser to the `scoreAd` function.
The `biddingWasmHelperUrl` field is optional, and lets the bidder provide computationally-expensive subroutines in WebAssembly, rather than JavaScript, to be driven from the JavaScript function provided by `biddingLogicUrl`. If provided, it must point to a WebAssembly binary, delivered with a `application/wasm` mimetype. The corresponding `WebAssembly.Module` will be made available by the browser to the `generateBid` function.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely convinced that browserSignals is the right place to attach the WASM as the WASM isn't exactly a signal coming from the browser like the other browserSignals members, almost seems better suited to an additional generateBid argument, but at the same time it seems awkward or wasteful to make every generateBid() method change their prototype to include an extra WASM parameter if some/many of them aren't using WASM. Anyhow, I don't have a better solution in mind.

My comment here is: should we add a blurb here mentioning how it's made available to generateBid? e.g. "...as a wasmHelper member of browserSignals"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely convinced that browserSignals is the right place to attach the WASM as the WASM isn't exactly a signal coming from the browser like the other browserSignals members

Me neither, which is why I wanted feedback.

almost seems better suited to an additional generateBid argument, but at the same time it seems awkward or wasteful to make every generateBid() method change their prototype to include an extra WASM parameter if some/many of them aren't using WASM.

If we add it to the end, they don't have to change it their signature --- extra arguments are ignored. Of course, there is only so often you can pull that trick.

Anyhow, I don't have a better solution in mind.

A global is another option, but it feels awkward.

My comment here is: should we add a blurb here mentioning how it's made available to generateBid? e.g. "...as a wasmHelper member of browserSignals"

Seems redundant?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this is an indication that these functions should be taking an options bag, and not positional arguments?

@morlovich morlovich changed the title Crude first cut at WASM stuff Proposal for WASM helpers for bidding functions Jan 6, 2022
@michaelkleber michaelkleber merged commit 42a21df into WICG:main Jan 20, 2022
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

Successfully merging this pull request may close these issues.

6 participants