[benoit74]

Summary

Both crypto.randomUUID() and crypto.subtle (SubtleCrypto) are restricted by browsers to secure contexts (HTTPS, or localhost). A ZIM served over plain HTTP on a non-localhost host (LAN server, offline hotspot, a VPN/Tailscale hostname, ...) — an extremely common Kiwix deployment — is not a secure context, so the browser omits both entirely, and any page depending on them fails (randomUUID throws; code awaiting crypto.subtle.digest() tends to fail silently instead).

• crypto.randomUUID(): crypto.getRandomValues() has no such restriction, so it's polyfilled on top of it (standard RFC 4122 v4 construction, via a separately-tested randomUUIDFromBytes helper).
• crypto.subtle.digest(): no lower-level primitive to build it from, so this adds a small, dependency-free pure-JS digest(algorithm, data) supporting SHA-1 and SHA-256 — the two algorithms actually observed in use (our own vendored wombat.js optionally uses SHA-1 for response ETags; archived pages have been seen using SHA-256 to derive a content id) — matching the native SubtleCrypto.digest() → Promise<ArrayBuffer> contract.

Both are installed as a side effect of loading wombatSetup.js, which already runs before any page script (warc2zim's head_insert.html loads it first in <head>).

sha1Bytes/sha256Bytes are cross-validated against Node's own crypto module across many input lengths, including the Merkle-Damgard padding's block-boundary edge cases, rather than relying solely on hand-transcribed test vectors — one of which did turn out to have a dropped character during review; sha1Bytes itself was correct throughout, confirmed via Python's hashlib.

Fixes #391 and #393, found via openzim/warc2zim#327: after fixing #387/#389, a user testing over a Tailscale hostname (plain HTTP, non-localhost) hit Uncaught TypeError: crypto.randomUUID is not a function, aborting the page's JS entirely. After the randomUUID fix, MDN's live-sample iframes were still stuck at src="about:blank" with no visible error — traced to crypto.subtle being undefined, silently breaking the await crypto.subtle.digest("SHA-256", ...) call used to build their content id.

Both reproduced directly (not just inferred): confirmed window.isSecureContext === false and typeof crypto.randomUUID !== "function" / typeof crypto.subtle === "undefined" against a real non-localhost URL, then confirmed both resolved after this patch, with the live-sample demos rendering again end to end.

[benoit74]

I'm a bit hesitant on this one, might have significant security implications IMHO. But at the same time, we definitely need that for these ZIMs to work offline.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (657fe48) to head (394b63e).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #392   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           42        42           
  Lines         2952      2952           
  Branches       452       452           
=========================================
  Hits          2952      2952           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[benoit74]

@rgaudin WDYT about this?

Pretty sure these crypto functions are used in other websites, so adding support for them is pretty important IMHO, and in most cases they are not used for anything which needs them to be "secure". But there will inevitably be one case in few years where we've completely forgot about this and it will bit us.

I feel like the added value is way superior to the risk (especially since it is used on MDN which is an important ZIM to us), but I might be biased.

If we agree this is worth-it, I will open a follow-up issue to identify all "common" functions which might be hidden in our "unsecure" context but useful to JS scripts. This might be only the beginning of something larger. And of course we can imagine we add a flag to add these "polyfills" conditionally, should it add any added value in some context.