For Blazor WebAssembly (hosted), consider enabling cross-origin isolation by default

[SteveSandersonMS]

Some of the runtime's new/proposed functionality - native crypto, and multithreading - rely on SharedArrayBuffer. However, as per https://developer.chrome.com/blog/enabling-shared-array-buffer/, Chromium is soon going to start limiting this feature to be available only for cross-origin isolated sites. This will take effect as of Chromium v106.

That is, the site would need to be served with these headers:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

We can't do anything to enable this by default for standalone Blazor WebAssembly, as that's just a set of static files, and the HTTP headers are controlled by whatever is serving those files. This might lead to some functional problems for people hosting on GitHub pages or other places where the headers can't be controlled.

For hosted-on-ASP.NET Core sites, is there a way we could enable these headers by default? And would it be safe and reasonable to do so?

[SteveSandersonMS]

@eerhardt also pointed out that once such headers are enabled, "any 3rd party stuff - like ads, payment, auth, etc - stops working".

[eerhardt]

Some of the runtime's new/proposed functionality - native crypto

For more information on this functionality - see dotnet/runtime#40074. If SharedArrayBuffer is not available, the Crypto APIs will fallback to C# implementations. From the blazor-wasm-crypto design doc:

The implementations of our in-box managed algorithms will be faithful to the appropriate standards. However, we will not pursue FIPS 140-2 or any other certification for them. Our in-box managed algorithm implementations are not intended to be free of side channels.

Organizations which require FIPS 140-2 compliant implementations or implementations which make stronger side channel guarantees must ensure that their Blazor client code executes only in browsers which support SharedArrayBuffer and which carry FIPS 140-2 compliant primitives via SubtleCrypto.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

@SteveSandersonMS took a quick look at this yesterday. My findings are as follows:

• There is a property we can use to check window.crossOriginIsolated to determine if the policies are in place.
• On environments where you don't control the host, this can be achieved in a somewhat "hacky" way by using a service worker to add the headers. Obviously, this doesn't work on the first visit, but you can "refresh" the page to have the SW take over and add the headers to the response.
• Enabling CORP means that the resource can only be loaded if it explicitly opts-in to it. In our case, it needs to match scheme+host+port.
  • If someone tries to force the document to render, the browser will not return the response.
• Enabling CORP and COEP essentially mean that the page can't load a cross-origin subresources that are not explicitly marked as consumable cross-origin (these are things like script, img, etc that by default are no-cors)
  • This should be fine for most cases unless you are building a site that indexes content from elsewhere.

[eerhardt]

Is this still planned on making it for 7.0-rc1?

[SteveSandersonMS]

@eerhardt This issue was to track "figuring out a plan" (i.e., consider) rather than a confirmed intention to enable this by default.

We've had a bunch of discussions and considered the pros/cons of different approaches. The key points are:

• Long term (.NET 8),
  • For ASP.NET Core-hosted Blazor WebAssembly apps, we hope to enable this by default. However we are aware that these headers cause surprising and hard-to-understand restrictions on what client-side code can do, so we do need to collect evidence of what level of disruption it introduces by putting this early in the .NET 8 preview cycle.
  • For standalone Blazor WebAssembly apps, we want to have some way of enabling this (e.g., via the service worker hack) but it's more disruptive still, so we're not certain about whether it would be on by default
• For .NET 7, it's clearly far too late to introduce something so breaking and hard-to-understand by default.
  • The kinds of breakage people would see is inability to reference images, scripts, etc. from other origins which would normally work, breakage of popup-based OAuth flows, and the developer experience becomes akin to CORS which we have long experience of being tough for people to understand and get right.
  • However, we do want to make it straightforward for people to enable it if they want. We plan to address this by a combination of docs (e.g., covering "why you might want to do this", "why you might not want to do this", and "what features this affects") and linking to them directly from the project template to maximize discoverability. This is tracked as Update Blazor WebAssembly template to include comment linking to doc about enabling cross-origin isolation #43194

[SteveSandersonMS]

Closing as the "considering" is done and we have a new issue tracking the work item