Clipping of violation’s sample to the 40 first characters

[fred-wang]

See

https://w3c.github.io/webappsec-csp/#framework-violation
https://w3c.github.io/webappsec-csp/#should-block-inline
https://w3c.github.io/webappsec-csp/#can-compile-strings

The spec says "the substring of source containing its first 40 characters".

I understand this means a surrogate pair in the violation sample should be treated as a single character, but maybe that needs to be mentioned explicitly and/or to be covered by specific WPT tests.

Currently, Firefox instead just clips the source as UTF-16 string of length 40 which is somehow a bit easier (but has special code to avoid clipping the last character in the middle of a surrogate pair): https://bugzilla.mozilla.org/show_bug.cgi?id=1935996

I wonder what Chromium or WebKit do?

cc @lukewarlow @koto

(incidentally, probably a separate issue but Firefox may also append an ellipsis character to indicate that the content was really clipped)

[lukewarlow]

WebKit calls StringView::left(40) which calls substring, see https://searchfox.org/wubkat/source/Source/WTF/wtf/text/StringView.h#558

[fred-wang]

WebKit calls StringView::left(40) which calls substring, see https://searchfox.org/wubkat/source/Source/WTF/wtf/text/StringView.h#558

Thanks. So I understand that means treating a surrogate pair as 2 characters?

[fred-wang]

I uploaded some tests for "Should Trusted Type policy creation be blocked by Content Security Policy" at https://phabricator.services.mozilla.com/D243400 (we need similar tests for https://w3c.github.io/trusted-types/dist/spec/#should-block-sink-type-mismatch)

As I see all browsers currently clip the policy name as a UTF-16 of length 40. This means they all fail the tentative test for H${'𝐇'.repeat(clippedSampleLength / 2)} since they will actually cut in the middle of the surrogate pair for the last character U+1D407 𝐇.

In my patch I'm making Firefox aligned with its own more general way of clipping violation samples i.e. it will actually produce a sample of length 41 and pass the test.

[fred-wang]

we need similar tests for https://w3c.github.io/trusted-types/dist/spec/#should-block-sink-type-mismatch

Done in https://phabricator.services.mozilla.com/D243400 and we have similar issues about cutting in the middle of a surrogate pair.

[annevk]

If string operations are not defined in terms of https://infra.spec.whatwg.org and Unicode it's essentially implementation-defined, in my opinion.

It's not clear to me that it's worth caring about surrogates here. Or if it is, why not care about grapheme clusters?

[fred-wang]

If string operations are not defined in terms of https://infra.spec.whatwg.org/ and Unicode it's essentially implementation-defined, in my opinion.

I'm fine with that as I think the exact value of the sample is unlikely to be very important, but I thought it would be worth reporting as a compat issue in case people have different opinions.

It's not clear to me that it's worth caring about surrogates here. Or if it is, why not care about grapheme clusters?

This behavior was implemented 7 years ago in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1473587 ; it seems this was added when the patch landed but I can't find any discussion about it...