Skip to content

Make webcomponents-loader.js compatible with the Trusted Types API #501

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 37 commits into from
Apr 15, 2022

Conversation

bicknellr
Copy link
Collaborator

@bicknellr bicknellr commented Mar 31, 2022

@bicknellr
Copy link
Collaborator Author

bicknellr commented Mar 31, 2022

Local WCT tests passed as expected, since no trusted types policy is being enforced yet:
https://github.com/webcomponents/polyfills/runs/5763342598?check_suite_focus=true#step:7:24

@bicknellr
Copy link
Collaborator Author

Hmm, I was expecting the last commit to start enforcing trusted types and cause the test to fail, but they passed:
https://github.com/webcomponents/polyfills/runs/5763527250?check_suite_focus=true#step:7:24

@bicknellr
Copy link
Collaborator Author

That test is now failing with a timeout, as expected:
https://github.com/webcomponents/polyfills/runs/5763712982?check_suite_focus=true#step:7:24

@bicknellr
Copy link
Collaborator Author

After adding the new policy, the tests pass again:
https://github.com/webcomponents/polyfills/runs/5763782787?check_suite_focus=true#step:7:24

@bicknellr bicknellr force-pushed the loader-trusted-types branch from b867622 to 3e59faf Compare April 6, 2022 23:00
@bicknellr bicknellr force-pushed the loader-trusted-types branch from 3e59faf to 2489843 Compare April 6, 2022 23:04
Comment on lines 183 to 201
var trustedTypesAreEnforced = (() => {
try {
document.createElement('input').setAttribute('oninput', '');
} catch (e) {
return true;
}
return false;
})();

if (
window.trustedTypes &&
trustedTypesAreEnforced &&
!window.trustedTypes.isScriptURL(window.WebComponents.root)
) {
throw new Error('`WebComponents.root` must be a `TrustedScriptURL`.');
}
url = trustedTypesPolicyWrapper.createScriptURL(
window.WebComponents.root + polyfillFile
);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@koto, I'm curious what you think about this w.r.t. w3c/trusted-types#36. The issue here is that WebComponents.root is arbitrary input used to build a string that I'm stamping here as a TrustedScriptURL, so I'd like to enforce that it is also a TrustedScriptURL. However, if I don't check for and enforce only at the same time as the browser, then this error would be thrown even if the browser is only reporting trusted type violations. Is there a better way to propagate enforcement like this?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We think it's an antipattern to change the behavior only if require-trusted-types-for (or any CSP directive, for that matter) is enforced. The issue with that is that report-only can't be safely used to iron out all the violations, and authors risk breaking production apps the moment enforcing CSP replaces the reporting one.

The safe (but breaking) route out of this is, I think, to introduce WebComponents.rootAsTrustedScriptURL (naming TBD) and use only that when window.trustedTypes is available.

The less-safe (but b/w compatible) is to continue using .root, and just documenting that the value should not be user controlled. To my understanding the loader is only used for polyfills anyway, and these would only be loaded for older browsers, which could only get TT via a polyfill, so the practical risk is minimal here.

I would personally just go for the second option, given the constraints.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, yeah, the second option sounds best in this case since I don't think we'd want to make a breaking change to the loader at this point. Thanks for your input!

@bicknellr bicknellr force-pushed the loader-trusted-types branch from d0c4291 to 1eda9d0 Compare April 11, 2022 22:16
@bicknellr bicknellr requested a review from rictic April 11, 2022 22:55
@bicknellr bicknellr marked this pull request as ready for review April 11, 2022 22:55
@bicknellr bicknellr requested a review from aomarks as a code owner April 11, 2022 22:55
Comment on lines 169 to 171
bundle it selects based on feature detection. You should also treat
`WebComponents.root` as if it were required to be set to a `TrustedScriptURL`
when trusted types are being enforced.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
bundle it selects based on feature detection. You should also treat
`WebComponents.root` as if it were required to be set to a `TrustedScriptURL`
when trusted types are being enforced.
bundle it selects based on feature detection. If you set `WebComponents.root`
(which is rare), it should be set to a TrustedScriptURL for Trusted Types
compatibility.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll work on the language more here. I don't think we can actually enforce that this is a TrustedScriptURL without making a breaking change, but I think I could word this so that the idea that it should only be set to values that would be considered as safe as a TrustedScriptURL was more clear. I.e. we can't actually enforce the safety ourselves, so users should know that it needs to be treated this way.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated this slightly, PTAL

Copy link
Contributor

@rictic rictic Apr 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT of this suggestion now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is better - updated.

@bicknellr bicknellr requested a review from rictic April 14, 2022 00:34
@bicknellr
Copy link
Collaborator Author

This is passing locally and in internal test runs so I'm going to merge despite the test infra problems.

@bicknellr bicknellr merged commit 34a104f into master Apr 15, 2022
@bicknellr bicknellr deleted the loader-trusted-types branch April 15, 2022 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants