-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
[wasm] Set default for disableIntegrityCheck to true #102515
Conversation
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
@kg overall what you mention makes sense, however, I would add that we didn't use integrity for security purposes (as you mentioned, those things are covered by HTTPS and SRI doesn't add anything on the same origin as if you are able to modify an asset in that context you are also able to modify the code that makes the request with the integrity value). The reason we used integrity was to break reliably on invalid caching. In many cases it will occur that the app is sitting behind an HTTP proxy (corporate proxy, cloudflare, etc) and people will not correctly configure the caching rules in those situations. We always request I would ask the following questions:
Now, with all this said, I'm not opposed to us removing this check, however, I think we should skip this check based on whether we are fingerprinting or not. That will still break things early if there are caching issues, and in practice will be equivalent to disabling it, since we are fingerprinting all assets by default. Finally, some of this overhead might go away in the future or be required for other reasons (we start preloading things and the time spent on it becomes irrelevant, or we setup CSP in a way that requires including integrity on the requests). So, in summary, I'm ok if we do this based on whether the app is fingerprinting its assets or not automatically (with the option to turn it on even in that case), but we should also understand if this is having a significant impact on the main browsers we target. |
Yeah, this is tough to solve. It's possible SRI is still the best real-world solution for it, but my hope is we can find something cheaper.
It's 11% of total CPU samples during the startup loop profile (100 warm starts with a 10ms delay between them). I don't know of any browser profiling tool that allows me to determine how many of those samples are on the 'hot path' (that is, blocking startup), but based on the stacks, the SRI hashing prevents bytes from flowing to the parts of the browser that would parse JS or decode WASM; it is functionally synchronous. However, on even mid-spec devices the CPU is not likely to be maxed out during asset loading, so it's possible that the CPU time spent hashing is "free". I don't know how to determine whether this is true.
I haven't figured out how to determine whether Chrome has the same limitations - it's possible it would show up in their low-level tracing. From my understanding of the spec though, it would have to, and it's just a question of whether they hide the latency introduced by the synchronous hashing through some cleverness.
I tried this and the noise level in the measurements was too high for me to decide for sure whether it was an improvement. The CPU usage in the profiles for SRI was gone, and by examining the stacks it also appeared that at least in Firefox the codepaths used are more efficient ones too. I'm not sure how one would go about measuring this effectively - maybe on a low spec device with CPU turbo & downclocking disabled?
If it has no impact on chrome or safari I would say it's not worth it.
Yeah, that seems like a good way to decide on whether to do it. I agree that if we don't have something like fingerprinting to provide the same value as SRI, we can't disable SRI.
Agreed, we shouldn't do this without measurement data to support it. I've been unable to find a way to gather data for or against this that seems trustworthy. |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
From my profiling, in Firefox we spend ~11% of CPU time during startup in their network stack, making copies of data coming from network/cache and hashing it to perform the integrity check. By disabling SRI all of this CPU usage goes away. The cost of this integrity check will scale as files get larger, so it is more significant for big binaries i.e. AOT'd applications.
It's hard to measure the actual impact in terms of wall clock time but from my understanding of how all this works, our .wasm modules and assemblies can't begin being processed until the integrity check has finished, which means the whole asset has to be loaded over the network and hashed in a blocking fashion before something like streaming wasm compilation can start. (It's possible they are doing some of this work in parallel, but ultimately the integrity check has to block execution.)
I don't have any visibility into what impact this has on Chrome because their profiler doesn't expose internals like Firefox's.
To make this mergeable we would need to enforce a set of rules to determine when it is a valid default. From my past discussions with experts, if the following rules hold:
It should be possible to safely disable SRI for assets served over HTTPS. Potential scenarios where SRI would matter, and my reasoning for why SRI isn't a meaningful improvement:
So I think the rules we would enforce should be:
It might also make sense to enable SRI for the very first page load, since that one is already slow and "corruption on the server or over the network" is more likely than "corruption at rest in the browser cache". But cold start time is also more important for conversion rates, so it might be what matters to users.