Upcoming issues with `SharedArrayBuffer`

[Jaifroid]

It is worth noting that Chrome will disable SharedArrayBuffer by default from Chrome 113 unless a site is cross origin isolated, which means that it serves these headers:

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

See https://developer.chrome.com/blog/enabling-shared-array-buffer/

It is relevant for this Repo, as the type of File Reader that we enable when compiling the WASM uses SharedArrayBuffer to pass a multi-gigabyte File to the WASM Worker without copying or loading in memory. This is why the WASM doesn't work on Chrome Mobile, where there is no support for SharedArrayBuffer except behind a flag, and it seems no support at all for it with POSIX threading enabled in source binaries.

For the PWA versions, we should be able to serve those headers. Other versions that don't use https: may struggle. We may need to look into alternative file systems for the WASM.

[Jaifroid]

So, I tried adding these security headers to Kiwix JS PWA docker instance:

add_header Cross-Origin-Embedder-Policy require-corp;
add_header Cross-Origin-Opener-Policy same-origin;

Unfortunately, the effect is to block any programmatic access to the iframe. Need to investigate if there is a way to loosen this. I find it very strange that an iframe that is clearly serving content from the same origin should be blocked by these headers. It isn't serving (and cannot serve) content from other locations.

[Jaifroid]

Further info here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Embedder-Policy. Note this text:

You can only access certain features like SharedArrayBuffer objects or Performance.now() with unthrottled timers, if your document has a COEP header with the value require-corp value set.

Suggested solution is to add crossorigin to any resources that need to be loaded, like <img src="https://thirdparty.com/img.png" crossorigin />. I can try adding this to the iframe document, I guess, but it would be impractical to add it to every resource requested from a ZIM. My initial puzzlement still stands: these resources are not cross origin...

[Jaifroid]

See also this convoluted solution: https://stackoverflow.com/a/71817085.

[Jaifroid]

Another guide: https://web.dev/cross-origin-isolation-guide/#mitigate-the-impact-of-cross-origin-isolation.

[Jaifroid]

On reflection, it's not clear to me whether sharedArrayBuffer is the real issue here, or in fact the lack of support for Atomics in some browsers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.