JavaScript event for tracking (and blocking) policy creation

[koto]

Pulling out from #222 and #235:

If policy name or rules would only be inspected, but not modified by the JS meta policy callback, and (apart from arbitrary side effects) the decision relevant to TT from the meta callback could be simply to stop the policy creation, then using regular events would work. In an imaginary implementation:

trustedTypes.browserInternalCreatePolicyImpl_ = function(name, rules) {
  const details = {"detail": {
    name: name, 
    rules: /* shallow clone to prevent mutation */ Object.assign({}, rules}}};

  Object.freeze(details);

  var event = new CustomEvent("beforecreatepolicy", details);
  
  if (!trustedTypes.dispatchEvent(event)) {
    // policy creation prevented. console.log something.
    return;
  }
  actuallyCreatePolicy_(name, rules);
}

the following code would work:

trustedTypes.addEventListener('beforecreatepolicy', (e) => {
 // inspect e.details.name or e.details.rules
 // throw an Error to inspect the stack
  e.preventDefault(); // don't let this policy be created.
}); 

In this model, multiple event handlers could be setup. Any of them could cancel policy creation, but none could undo that decision. You get inspectability into the body of the policies (so secrets in policy bodies could be revealed), and you could even call the inner policy functions, but that seems fine (inner policy functions return strings, not trusted types)

Any code can already do that by playing with prototypes, so we're not giving capabilities that don't already exist. It also seems to reuse a model familiar to authors, and gives enough control to implement practical limitations without allowing too much surprising and hard to debug behavior (e.g. the policy rules being suddenly replaced for a dependency from the event handler).

Originally posted by @koto in #222 (comment)

[koto]

/cc @xtofian @bakkot @Siegrift @otherdaniel @Sora2455 from previous bugs about this.

[koto]

First comment has a rough sketch of the proposal. Does it look OK on your end? We wanted to start speccing it.

[lukewarlow]

While this would be a v2 feature and so not in the current spec draft it would be good if someone could make a draft PR to add in the beforecreatepolicy event, makes it easier to evaluate.

[fred-wang]

This test looks a bit suspicious to me:

  test(t => {
    event_listener = (e) => {
      assert_unreached();
    };
    trustedTypes.createPolicy("test", {});
    trustedTypes.addEventListener('beforecreatepolicy', event_listener, {once:true});
  }, 'Policy creation called before addEventListener function will not reached the listener.');

probably it should use https://web-platform-tests.org/writing-tests/testharness-api.html#Test.unreached_func instead, if the assert_unreached() in the listener is executed I suspect the testharness will report an uncaught exception, but the test will still pass.

[lukewarlow]

The event listener should also be registered before calling the method.

[annevk]

It seems to try to test that events are not dispatched from a task or microtask, but indeed that would be much better to test by registering the listener early and adding the relevant asserts about when it is invoked relative to other points in time.