Re: [w3ctag/design-reviews] Trusted Types (#198)

Thanks, Anne!

> As was a problem with CSP, I'm worried with trying to address this problem based on callsites, rather than the more fundamental algorithms that are responsible for performing a certain action that we want to avoid exposing to non-privileged code.
> 
> That is, I think a more principled model would modify "navigate" to take a "trusted" value and based on some policy error on non-"trusted" values, and then adapt callsites as appropriate to be able to pass it "trusted" values. 

We're not opposed to adding additional assertions at navigation time (or when a script is prepared), but what we feel really strongly about throwing the errors at assignment time. For one - this can be polyfilled, but more importantly - this allows for statically (as much as it's possible with JS) identifying places in the code where sinks are used in a non-compliant way.

I'll identify which alorithms would be a good target for the additional checks and update the spec with the proposed alterations.

> I'm also a little worried that the current approach leaves certain attack vectors unexplored. Are malicious `target` values problematic? Is changing `<form method>` not problematic? I.e., should all parameters to "navigate" effectively be "trusted" values? Why only the URLs?

We are targetting DOM XSS, content exfiltration or confinement is explicitly [not in scope](https://wicg.github.io/trusted-types/dist/spec/#non-goals) (mostly because this feels like a much more difficult to achieve with the sink-based approach only due to the existence of various other side-channels for the data). 

> (Also, `window.location` is protected, but MathML links are not? With a system that protects navigation (and similar such algorithms) at source, you don't really have to worry about this, at least not until someone wants to use MathML links with it.)

All link based vectors stop being risky once we simply disable `javascript:` URLs (and optionally reenable them selectively at navigation time via efault polocy). This is what we're [proposing](https://github.com/WICG/trusted-types/pull/204) in the update to the API (we'll likely discuss this at lentgh at TPAC). After those updates, the only URLs that are relevant are URLs of scripts and object/embeds.



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/198#issuecomment-526148507