WPT for CSP header trusted-types 'none' 'none' missing

[mbrodesser-Igalia]

Behavior should equal the one for trusted-types 'none'.

[ziransun]

I'm not sure if it's valid to set the trusted-types 'none' 'none' since 'none' has no effect unless it is the only expression in the directive value.
@lukewarlow @mbrodesser-Igalia

[mbrodesser-Igalia]

@ziransun see https://w3c.github.io/trusted-types/dist/spec/#abstract-opdef-should-trusted-type-policy-creation-be-blocked-by-content-security-policy. It states:

"If directive’s value only contains a tt-keyword which is a match for a value 'none', set createViolation to true.".

Here, the value contains only that keyword (multiple times).

[lukewarlow]

Have you tested Chromiums or safari tech preview's behaviour here?

The spec is ambiguous imo. It says the value only contains a keyword 'none'. Well two duplicate keywords aren't 'a keyword'. I think it depends on if there's any handling for discarding duplicates inside of CSP parsing?

I think it should behave the same as just 1 existing but the spec should be clarified too in that case.

[ziransun]

Yes, I have tried with Chromiums and safari. Apart from having the same result as one "none", it has complains like -
The value of the Content Security Policy directive 'trusted_types' contains an invalid policy: 'none'. It will be ignored. Note that 'none' has no effect unless it is the only expression in the directive value.

[mbrodesser-Igalia]

I think it should behave the same as just 1 existing but the spec should be clarified too in that case.

Agreed.

[lukewarlow]

So after some more thinking I want to clarify the above comment.

trusted-types 'none'; and trusted-types 'none' 'none'; should and DO behave the same both in the spec and in implementation, no policies are allowed. This is because they're both equivalent to trusted-types;

The first triggers step 2.4 and the second will fall through to step 2.6 both creating a violation.

trusted-types 'none' foobar; and trusted-types 'none' 'none' foobar; also both behave the same (policy name foobar is allowed).

Neither of these would trigger step 2.4 or 2.6 and so no violation would be created.

I actually don't think the spec is ambiguous here.