-
Notifications
You must be signed in to change notification settings - Fork 227
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
Restrict JavaScript environment for Reusing FLEDGE Worklet Contexts #310
Comments
One clarification related to this option is whether there needs to be a mechanism for buyer bidding and seller scoring scripts to initialize / pre-compute some data structures before running for later reuse, and, consequently, at which point would freeze happen. For example, would something along the lines of…
… be possible outside of In this proposal, would freeze happen after |
We're still investigating this space. We will want to start with the global context frozen, since recursively freezing it is expensive (~3ms on a developer workstation). We expect we can start with a frozen global context before running the script and then drop any state changes to allow us to reuse the context. That would require the script to be run again (computing expensiveObject) each time, though. We are also looking into performing a second freeze after running the script, so we don't have to run the overall script again. This would effectively only compute the expensive object once, regardless of how many times we need to call generateBid. We will likely need to impose additional restrictions on variables - basically we can't allow anything we can't reliably freeze. We're still evaluating what the restrictions would need to be, but we likely won't be able to allow non-const primitives that are not properties of objects, iterators, or generator objects to be reachable when we perform the freeze. We are still very early in this investigation so it is possible that something might come up that prevents us from using this approach. Also, I'm assuming the expensive object does not depend on anything other than the contents of the script. If that is not the case, then it is unlikely we can save it across runs. |
I've recently landed crrev.com/c/3664757 which adds the "frozen-context" execution mode, so it should be showing up in Canary builds of Chrome. In this mode the context is frozen after the top-level script is run. Freezing the context can add up to 10ms of delay, but our metrics suggest this will be beneficial for most bidders that have at least 2 interest groups and are unable to take advantage of the "group-by-origin" execution mode. There are a number of restrictions in this "frozen-context" execution mode, due to either limitations in the current implementation or fundamental limitations of the v8 engine. These restrictions are calculated at the time the context is frozen, which is after the top-level script has run and the custom worklet functions have been added. So any variables in scopes that are no longer reachable shouldn't cause problems. Note that some care should be taken because JavaScript closures capture the scope they are declared in. The restrictions are:
Since there is a lot of complexity and ambiguity of these restrictions I'm putting together a basic worklet testing environment here to make it easier to check if your bidding scripts will be supported in this mode. |
On the Chrome implementation side, we’re looking at other options for reusing the JavaScript context for running worklets. One option we are pursuing and would like some feedback on is freezing the global object (equivalent to calling Object.Freeze recursively on globalThis and its properties) before running any scripts. This, combined with some other changes to script local storage would prevent worklet functions from persisting information between runs, so we can reuse the context for any interest groups that use the same bidding script.
If we freeze the global context, some JavaScript changes will be necessary:
var
and function definitionsfunction generateBid(...) {..}
will not be allowed. Instead use script-level definitions throughlet
orconst
, defining worklet functions like:const generateBid = function(...) {...};
.Instead of these:
var x = …
function generateBid(...) {...}
globalThis.generateBid = function(...) {...}
Use these:
let x = …
orconst x = …
const generateBid = function(...) {...};
Instead of this:
Use this:
The text was updated successfully, but these errors were encountered: