Trusted Types

[mikewest]

Hello TAG!

This is earlier than I'd usually ask for y'all's feedback, but since I'm talking about a type system, it seems reasonable to get some sort of directional feedback from y'all before getting to far ahead of things.

• Name: Trusted Types for DOM Manipulation
• Specification URL: None
• Explainer, Requirements Doc, or Example code: https://github.com/WICG/trusted-types
• Tests: Aiming to eventually land the tests in https://chromium-review.googlesource.com/c/chromium/src/+/559061
• Primary contacts: @mikewest

We'd prefer the TAG provide feedback as (please select one):

• open issues in our Github repo for each point of feedback
• open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify @mikewest

Again, there's not much concrete in the explainer, and we're pretty far away from having a spec. So now's a great time to give fundamental feedback on the notion of adding this kind of type system to DOM manipulations. We'd love to hear it. :)

[hadleybeeman]

Hi @mikewest! Thanks for sending this! We picked it up at our face-to-face in Nice.

A few comments and questions:

• Why is trustedURL not a subclass of URL? It would be good if these trusted types should fit meaningfully into the type hierarchy. Example code would help us here.
• Overall, we'd like to encourage you to not do this in IDL but instead do it in example code.
• It would be good to see integration with es6 template strings. So that it's possible to come up with a typed output.
• The name implies trusted. Can we name it something a bit more functional, like maybe something like "unserialised types for DOM manipulation"? (yes, we know naming is hard :-) )
• This may result in escaping everything — too much work (also including potential risks of jumping back and forth between escape and override escapes seem risk to be error prone)
• Issues with multiple concatenation, e.g., "mystring" + TrustedHTML.escape('unsafe') + "otherstring" - results in JS string, not typed object.

[koto]

Hey @hadleybeeman, I'm koto, working with Mike on this.

To answer your questions:

Why is trustedURL not a subclass of URL?

No strong reason, these types originate from Google internal implementation, where that was the case. I'm not opposed to subclassing.

Example code vs IDL

In fact, we have a polyfill implementation now in the repository, it can be built with:
$ npm install $ npm run build
or you could check the sources.

Template strings

Yes! I proposed something like that in w3c/trusted-types#26.

Naming

We have reasons why this is named trusted as opposed to e.g. safe, but at this stage names are not that important, though "unserializedTypeForDOMManipulation" will probably not fly ;)

Escaping

We're hoping to come up with an API with safe builders that may make the migration easier, and offering security benefits. This is just an early draft.

Concatenation

That is actually expected, by concatenating safe HTMLs with raw strings you may come up with an unsafe construction (if the strings are user-controlled). I hope to address that in w3c/trusted-types#26, where interpolating user data gets slightly easier, but in general we hope such literal + TrustedHTML contatenations could be automatically refactored, rather than silently accepted at runtime.

[slightlyoff]

Hey @koto:

Thanks for getting back to us! @cynthia noted that the proposal has changed a bit. Are you looking for more feedback now? If not, feel free to close this issue and re-open when you get closer to shipping.

Regards

[koto]

Hey,

There are active changes being planned, and we'll be undergoing some API changes, so I'll close this now as you advised, and reopen when needed. Thanks!

[koto]

@mikewest, can you close this issue? I don't have the permissions to.

[mikewest]

@torgo / @ylafon: Would you mind reopening this review? @koto, et al. have moved the design forward from where we left it in February, and I think it's ready for a more detailed analysis from the platform perspective.