Bugzilla

Some more notes for future reference:

Our code currently relies on an optimization that basically caches on a document/CSP list/policy indicating whether they contain any "require-trusted-types-for"  directive.

This allows early returns in "Get Trusted Type Compliant String", even skipping the cost of pointer lookup for the CSP list when the doc's boolean says there is no such directive.

Now, because of there is only one sink group used in our code and accepted by the CSP parser, this is actually equivalent to the result of "Does sink type require trusted types?" so I'm simplifying things in D233505, making that algo O(1) and "Should sink type mismatch violation be blocked by Content Security Policy?"  O(size of CSP list).

In D233506, I'm adding a similar boolean (actually I'm grouping the two booleans in a single enum) for whether there is an *enforced* "require-trusted-types-for" directive, which is really the result of "Should sink type mismatch violation be blocked by Content Security Policy?". Although we still need to browse the full list to decide to determine how many violations to report the result of the algo is obtained in O(1) and independently.

Finally in D233636, I'm exposing these booleans to the worker thread, so that in D233507 we can implement GetTrustedTypesCompliantString for workers (the booleans are read in the worker thread and the violation reports are done on the main thread).

The proposal `trusted-types-eval` at https://github.com/mozilla/standards-positions/issues/1032 relies on https://github.com/w3c/trusted-types/pull/518 which essentially condition whether "Does sink type require trusted types?" return the first or second boolean. That means the work I made to support workers will allow to preserve our optimization for bug 1940493.

Some more notes for future reference:

Our code currently relies on an optimization that basically caches on a document/CSP list/policy a boolean indicating whether they contain any "require-trusted-types-for"  directive.

This allows early returns in "Get Trusted Type Compliant String", even skipping the cost of pointer lookup for the CSP list when the doc's boolean says there is no such directive.

Now, because of there is only one sink group used in our code and accepted by the CSP parser, this is actually equivalent to the result of "Does sink type require trusted types?" so I'm simplifying things in D233505, making that algo O(1) and "Should sink type mismatch violation be blocked by Content Security Policy?"  O(size of CSP list).

In D233506, I'm adding a similar boolean (actually I'm grouping the two booleans in a single enum) for whether there is an *enforced* "require-trusted-types-for" directive, which is really the result of "Should sink type mismatch violation be blocked by Content Security Policy?". Although we still need to browse the full list to decide to determine how many violations to report the result of the algo is obtained in O(1) and independently.

Finally in D233636, I'm exposing these booleans to the worker thread, so that in D233507 we can implement GetTrustedTypesCompliantString for workers (the booleans are read in the worker thread and the violation reports are done on the main thread).

The proposal `trusted-types-eval` at https://github.com/mozilla/standards-positions/issues/1032 relies on https://github.com/w3c/trusted-types/pull/518 which essentially condition whether "Does sink type require trusted types?" return the first or second boolean. That means the work I made to support workers will allow to preserve our optimization for bug 1940493.