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

Options for Reusing FLEDGE Worklet Contexts #304

Closed
stguav opened this issue May 19, 2022 · 6 comments
Closed

Options for Reusing FLEDGE Worklet Contexts #304

stguav opened this issue May 19, 2022 · 6 comments

Comments

@stguav
Copy link

stguav commented May 19, 2022

One of the bigger contributions to latency for generateBid arises from requiring a fresh JS context for each invocation. (Some efforts to measure suggest roughly 1ms per call on a modern desktop computer.) #162 discusses the possibility of generateBid being passed multiple interest groups (joined from the same advertiser site) in order to support some single-site cross-IG targeting and bidding options. Note that today advertisers frequently have many distinct remarketing lists, which may translate to many FLEDGE IGs. Users may belong to more than 1000 remarketing lists, but typically have visited no more than tens of distinct advertiser domains.

This issue is to propose that IGs joined from the same origin could reuse the same JS context for individual calls to generateBid as well as individual calls to scoreAd, as a browser optimization. This potentially reduces the number of contexts per runAdAuction call by more than 10-fold, for a significant improvement to runAdAuction latency. This could be implemented without an API change.

This proposal is potentially susceptible to the same cross-site privacy leak described in this comment: even if all of the joinAdInterestGroup events for the IG occur on the same site, there is still potential cross-site information leaking when leaveAdInterestGroup is called from other sites. This issue can be resolved relatively easily by disabling the optimization if leaveAdInterestGroup is called from a different site for any of the joinAdInterestGroup site's interest groups.

Similarly, concerns about #162 could be resolved in a similar way.

@michaelkleber
Copy link
Collaborator

Thank you Steven, this seems like an excellent suggestion.

I agree that the "leaveAdInterestGroup is called from a different site" problem can be readily overcome in a bunch of possible ways. For example, we could call generateBid for the removed IG anyway, and throw away the result.

@JensenPaul
Copy link
Collaborator

I think this optimization has a lot of potential. The time required to set up a new JavaScript context can actually be significantly more than the time required to execute a simple JavaScript function. This optimization makes worklet execution closer to how browser renderer processes execute JavaScript, where one context is used for all code execution, which is probably a good thing as it allows JavaScript engine authors to focus on just one use case. A few comments:

  1. The "leaveAdInterestGroup is called from a different site" problem also extends to calls to joinAdInterestGroup from another site as this overwrites the interest group.
  2. I'm not a big fan of the "disabling the optimization if leaveAdInterestGroup is called from a different site" solution as whether or not the optimization happens is now potentially exerting cross-site influence on the bidding decision.
  3. "we could call generateBid for the removed IG anyway, and throw away the result" solves the potential cross-site influence issue but I think this will complicate the browser's storing of interest groups (because it'll now have to store multiple interest groups with the same name and owner), and it potentially wastes computation time when bids are generated but then thrown away. We'd also have to answer the question of what happens if the user is re-joined to an IG that previously had it's bids thrown away.

What do you think of this proposal:
For interest groups joined on the same site with the same owner and with 'sameSite': true, the global JavaScript context is reused between generateBid() invocations. If one of these interest groups is joined or left from a site different from the one it was originally joined on, the user will first be removed from all interest groups with the same owner and with 'sameSite': true joined on the original site.

If many folks think this should be the default FLEDGE behavior, we can also eschew 'sameSite': true and make this the default behavior.

@brusshamilton
Copy link
Contributor

I have posted another option on for context reuse in issue #310 which proposes to harden the JavaScript environment so Chrome could reuse worklet contexts.

@stguav
Copy link
Author

stguav commented Jun 1, 2022

I think we could work with the suggested API, but issue #310 seems strictly better assuming it is feasible.

@morlovich
Copy link
Collaborator

FYI #339

@JensenPaul
Copy link
Collaborator

I believe this support was added via the group-by-origin option.

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

5 participants