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

JavaScript event for tracking (and blocking) policy creation #270

Open
koto opened this issue Mar 11, 2020 · 3 comments
Open

JavaScript event for tracking (and blocking) policy creation #270

koto opened this issue Mar 11, 2020 · 3 comments
Labels
future In consideration for the future releases of the API proposed-removal Issues concerning potential removal of functionality from the API spec
Milestone

Comments

@koto
Copy link
Member

koto commented Mar 11, 2020

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 koto added the spec label Mar 11, 2020
@koto koto added this to the v2 milestone Mar 11, 2020
@koto
Copy link
Member Author

koto commented Mar 11, 2020

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

@koto koto added the future In consideration for the future releases of the API label Mar 11, 2020
@koto
Copy link
Member Author

koto commented Apr 29, 2020

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

@lukewarlow
Copy link
Member

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.

@koto koto added the proposed-removal Issues concerning potential removal of functionality from the API label Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future In consideration for the future releases of the API proposed-removal Issues concerning potential removal of functionality from the API spec
Projects
None yet
Development

No branches or pull requests

2 participants