WASM headers for online

[juliusknorr]

As asked for by @mmeeks we would need to have wasm-unsafe-eval CSP headers set for WASM experiments currently taking place.

I checked back and we have a partly mechanism available to set those by nextcloud/server#38082 this is however not used yet by Nextcloud Talk, as there the wasm is running in a service worker which doesn't require this.

We should be able to add those headers of course, just some additional questions:

@mmeeks To you have a need to run the online wasm in the main thread? As far as I understood this could have a significant impact on browser responsiveness.

[mmeeks]

Nope - we should run our WASM off the main thread, and do load, rendering etc. in the background; while continuing to render the UI in the main-thread with the same front-end code as now.

[juliusknorr]

In that case the header should not be needed as far as @danxuliu told me

[mmeeks]

Hmm - ok ? it seems that we need the parent frame of our iframe to have this @Ashod can you provide more details; quite possibly I've mistaken what's up here I think. Quite possibly our startup WASM runs in the main thread initially (not sure).

[Ashod]

I believe we need these two headers when serving the parent:

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

Also had to add script-src unsafe-eval to the CSP header of our frame/js/wasm serving, but we will find out if that is required when we load with the above headers as the missing unsafe-eval was mentioned in the error message.

[juliusknorr]

unsafe-eval would be quite an impactful change security wise.

For the others I pushed a quick PR to #3260 which should achieve setting those headers for Nextcloud. However we should of course get more clarify about which headers to add in the end, why and its implications.

[mmeeks]

unsafe-eval sounds bad; but I think we can do that with wasm-eval in future :-) thanks Julius.

[Ashod]

For the others I pushed a quick PR to #3260 which should achieve setting those headers for Nextcloud. However we should of course get more clarify about which headers to add in the end, why and its implications.

@juliushaertl, I'd like to run some tests locally. Any chance to get the draft PR polished so I can build locally and test?
Thank in advance!

[juliusknorr]

@Ashod Pushed and should be testable with that now.

Reference for what it currently set currently set:

[Ashod]

Thanks @juliushaertl. The PR branch being out-of-date shouldn't be an issue?

@caolanm, does #3260 work for you? Are you able to apply it and build?

[caolanm]

I have this patched richdocuments and a local nextcloud install. I can see it has an effect, but right now if I open a document, without wasm, then I just get an error of:

[getWopiUrl] http://localhost/nextcloud/index.php/apps/richdocuments/wopi/files/7_oca1b28l9m0b url.js:42:9
The resource at “http://localhost:9980/browser/70f697e3da/cool.html?WOPISrc=http%3A%2F%2Flocalhost%2Fnextcloud%2Findex.php%2Fapps%2Frichdocuments%2Fwopi%2Ffiles%2F7_oca1b28l9m0b&title=%2FDocuments%2FWelcome%20to%20Nextcloud%20Hub.docx&lang=en&closebutton=1&revisionhistory=1” was blocked due to its Cross-Origin-Resource-Policy header (or lack thereof). See https://developer.mozilla.org/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)# files

[juliusknorr]

Seems this was caused by those two headers: #3258 (comment)

I pushed a fix up to the PR.

[droogi]

It seems that these two headers block maps and memories to load tiles and thumbnails/pictures

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

[MichaIng]

Yeah, isn't it possible to achieve everything via CSP for the very individual pages of the Nextcloud Office app that require it, instead of globally for all Nextcloud?

While it breaks other apps, the only workaround seems to be to set Cross-Origin-Embedder-Policy: credentialless, which seems to imply things we do not want: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy#credentialless
Also credentialless as well as Cross-Origin-Opener-Policy in general seem to not be supported by all browsers:

• https://caniuse.com/?search=Cross-Origin-Opener-Policy
• https://caniuse.com/?search=Cross-Origin-Embedder-Policy%3A%20credentialless

Hmm, only CSP option seems to be wasm-unsafe-eval: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_webassembly_execution

@droogi could you open a new issue here about this? Actually not good to discuss in a closed one.