Putting guards at primitives instead of sinks

[annevk]

I discussed this briefly with @koto and thought I'd file it to not lose track of the idea. What if instead of sinks we add the guards at the various primitives. E.g., not <a>, <form>, etc. but "navigate". Not fetch(), <img>, etc. but "fetch". Not appendChild() et al but "prepare a script" (or some such). Not innerHTML and friends but "HTML fragment parsing algorithm".

This would put the actual protections right at the dangerous points. We'd still have to change sinks to allow for typed objects to reach the dangerous points, but there's no longer the issue of overlooking a sink or overlooking trusted types when adding a new sink. Or the issue of it not being clear how to update all the various sinks as with Location as we could opt not to add trusted types for all of them.

[koto]

That's a really good idea! It's mostly just an exercise in finding the right primitives matching the current sinks. For example, for now fetch() is not guarded. I assume the default policy (or a callback function) would run not at a sink setter level, but at the lower-lever primitive (like a spec algorithm).

Two potential downsides I see is that a) it might make the integration with other spec more verbose, so more challenging and b) maybe not everything is polyfillable.

I'll take a look at where we could hook the current TT sink setters, and whether that causes some change of behavior (it will for individual Location properties, so for <a href> as well, but that's actually what we want - #64).

[koto]

One problem with the Fetch integration is that this would happen too late. To avoid having to taint track nodes, TT are guarded at node attribute setters, even if the node is not connected to the document.

For example, for scripts fetch would only be triggered when the script is prepared, but we'd rather require the type earlier, in this case when setting the src.

We could definitely benefit from Fetch integration e.g. by referring to (script-like Request destination)[https://fetch.spec.whatwg.org/#request-destination-script-like] and requiring the URL attributes being TrustedURL or TrustedScriptURL based on whether the Fetch destination later on would be script-like or not. However this seems hard to specify normatively ("require this type if it's possible for a different algorithm to set this value to Request" is quite vague). Perhaps it's better off adding a non-normative note instead? This already seems like what is happening elsewhere, e.g. "audioworklet" Request destination is not specified in Web Audio, Worklets nor HTML, and its value is only linked to audioWorklet.addModule() in a table in non-normative node in Fetch.

[annevk]

You can certainly put requirements on entry points. The main thing about having the actual guard at the primitive is to avoid missing entry points.

Not sure about the note thing, "audioworklet" not being defined in a normative matter is a bug.

[koto]

That's fine, I was just trying to figure out where the Request destinations are defined and audioworklet was the first thing I tried. The same bug exists for paintworklet that I can't find a reference of outside of Fetch, but I assume other values are better in that regard.

I still see some difficulty for speccing this, but it's likely I just misunderstood what you mean. Do you mean to add additional guards in e.g. fetch (the most likely algorithm that would relate to URL TTs), such that it rejects non-compliant values?

E.g.

If request initiator is "non-parser-inserted" , and request window's documents' TrustedTypeConfiguration's string at sink disposition is "reject" and a request URL is not a getTypeForDestination(request destination), reject with some error.

That would require preserving the type of the URL in Fetch as well. So far we're not doing this yet in the JS fetch() call, because we looked into non-script URLs mostly to address a problem with javascript: or other powerful schemes in URLs, and not to prevent requests from happening.

If we'd want to keep JS fetch(string) to work regardless of TT enforcement, we need a way to track the requests initiated by DOM / other sinks from ones using XHR / Fetch - should we use initiator for that?

[annevk]

Yeah, worklets are not defined well and have quite a few open issues against them... Perhaps you can ping some colleagues?

Initiator might be useful if there's nothing else that gives it away. Note also that at a specification level URL is not a string, e.g., to make blob URLs work. So there's infrastructure already to attach additional data to URLs.

[koto]

I was able to tackle the javascript: URLs in a more developer-friendly matter.

Previously, all navigational sinks required a TrustedURL. The only issue with those sinks was that they could potentially navigate to javascript:, but most usages of them were benign. We found that it's unneccessarily difficult for the authors to cover these sinks with TrustedURLs (this is by far the most common violation source), so instead I propose a simple hook that will make sure that a navigation to a javascript: URL will go through a default policy:

https://github.com/WICG/trusted-types/pull/204/files

This places the burden on the authors who still use javascript: URLs, and makes sure that, in "TT mode" the javascript: URLs don't work by default.

[koto]

@annevk I've found a couple of algorithms that form the set of primitives that are a good target for guards. The issue is that as these primitives accept strings, or byte streams and are called a few levels deeper than the TT logic, and I don't know how to express in the spec that these should take TT into account, without clumsily passing an additional argumentall the way through the stack.

I see something similar when HTML fragment parsing algorithms is called out as a special case e.g. here

Would something like the following work for TrustedHTML for example? If this is acceptable, I can extend that approach to other types and primitive algos.

[Pull request] [Spec preview]