`createPolicy`'s permitted policy names are inconsistent with CSP's permitted policy names

[ghost]

https://w3c.github.io/trusted-types/dist/spec/#dom-trustedtypepolicyfactory-createpolicy has no restrictions on the policy name, https://w3c.github.io/trusted-types/dist/spec/#trusted-types-csp-directive has.

E.g. trustedTypes.createPolicy("$") is supported and trusted-types $ not.

https://github.com/w3c/trusted-types/issues/466 is a special case of this.

[ghost]

In today's meeting with @koto, @lukewarlow and some Mozillians it was agreed to adapt https://w3c.github.io/trusted-types/dist/spec/#dom-trustedtypepolicyfactory-createpolicy to match the policy names permitted by https://w3c.github.io/trusted-types/dist/spec/#trusted-types-csp-directive.

@otherdaniel: could you please add a use counter for the now undesired policy names of createPolicy?

[annevk]

There are meetings outside the purview of WebAppSec? Shouldn't those be announced at least? Or if they are completely private I don't think they can be used to make decisions and probably shouldn't be discussed here.

Please see https://www.w3.org/2023/Process-20231103/#GeneralMeetings.

cc @mikewest @dveditz

[lukewarlow]

Shouldn't those be announced at least?

The meeting in question is an Igalia project update meeting so is "private" in that sense. it just also happens to have lots of people involved in the spec and implementation so is useful to get people's thoughts on issues that we come across with the spec. I'm unaware of anything that we've discussed there that hasn't otherwise been raised as an issue previously.

I think to reword it "it was agreed that it seemed a reasonable idea" and it's good to get use counters in early if we do end up making this sort of change.

[ghost]

There are meetings outside the purview of WebAppSec? Shouldn't those be announced at least? Or if they are completely private I don't think they can be used to make decisions and probably shouldn't be discussed here.

Please see https://www.w3.org/2023/Process-20231103/#GeneralMeetings.

cc @mikewest @dveditz

@annevk: thanks for bringing this up. The agreement above was just a collective suggestion, so please feel free to object to it. It's not a decision. I understand one has to be careful here.

[mikewest]

This might be a good indication that a broader update on Trusted Types might be helpful for the WebAppSec community more broadly. Would y'all be interested in talking about it in the meeting on May 15th?

[koto]

Getting back to the technical issue. I suspect that unlike as in #466 there will be back compat issues, but we need a use counter first to have more information. @otherdaniel, can you add one?

[fred-wang]

What's the status of this?

I tried adding some tests for invalid CSP names there https://github.com/web-platform-tests/wpt/pull/50872/files#diff-675a0a46e4fbc7fce1b72d1f48cdf824e55fa0a123f8105df01b3c53f3946161 but probably it's not possible until we clarify this.

[fred-wang]

The tests I added for invalid/valid policy names were for use in the CSP trusted-types directive. We still need to check valid/invalid policy names passed to (I can't really find existing tests for these, even for the empty string case mentioned in https://github.com/w3c/trusted-types/issues/466).

[fred-wang]

I opened a PR with a tentative test and none of the browsers are rejecting policy names that are not CSP tt-policy-name: https://github.com/web-platform-tests/wpt/pull/51718

[fred-wang]

In today's meeting with @koto, @lukewarlow and some Mozillians it was agreed to adapt https://w3c.github.io/trusted-types/dist/spec/#dom-trustedtypepolicyfactory-createpolicy to match the policy names permitted by https://w3c.github.io/trusted-types/dist/spec/#trusted-types-csp-directive.

I was not part of these past discussions, but my understanding is as follows:

• If we restrict to tt-policy-name, then it's no longer possible to create policy names with non-ASCII letters for example, which might not be desired for developers using non-English languages (whereas JavaScript does allow non-ASCII variables). Also, there may be a backward compatibility issue with Chromium, and maybe WebKit-based browsers that already ship TrustedType support (if any).

• If we allow arbitrary values, then it's inconsistent with CSP which only allows ASCII token per https://w3c.github.io/webappsec-csp/#parse-serialized-policy ; and with tt-policy-name which allows a more restricted set. In particular, the only way to create policies with non-tt-policy-name is to use wildcard or no trusted-types directive, defeating the purpose of this trusted-types directive.

I wonder what's current position from folks at Google, Apple and Mozilla?

[annevk]

Changing CSP syntax seems like a non-starter. HTTP headers are best kept simple. (It would be good to test some non-ASCII bytes here.)

I don't care too strongly whether or not the API supports a superset of that. (Tests would be good, of course.) If all implementations already allow that it seems simplest to just stick with that, even if it creates some inelegant edge cases?

[fred-wang]

Changing CSP syntax seems like a non-starter. HTTP headers are best kept simple. (It would be good to test some non-ASCII bytes here.)

As I said I was not part of these discussions but I understand nobody suggested that, the idea was the other way around: restrict createPolicy's permitted policy to match tt-policy-name. About tests with non-ASCII bytes, I'm adding one at https://github.com/web-platform-tests/wpt/pull/51718

I don't care too strongly whether or not the API supports a superset of that. (Tests would be good, of course.) If all implementations already allow that it seems simplest to just stick with that, even if it creates some inelegant edge cases?

I'm fine with that. I updated my test at https://github.com/web-platform-tests/wpt/pull/51718 to instead test this is a superset.