Port-back from jspod (jspod#65), where the same crash class was found in the seeded onboarding pages.

Problem

src/idp/views.js:273 — the login page's inline passkey JS calls crypto.randomUUID() directly:

body: JSON.stringify({ visitorId: crypto.randomUUID() })

crypto.randomUUID requires Chromium 92+ and a secure context. On de-Googled Android phones the System WebView is often stale (it updates via the Play Store, which isn't installed), so the API is missing and "Sign in with Passkey" dies with a cryptic crypto.randomUUID is not a function. This blocks the Solid-pod-on-a-de-Googled-phone path (#46 arc, js-pod/android).

Fix (proven downstream)

jspod patched its pages with a ~6-line fallback built on crypto.getRandomValues (broadly supported, not secure-context-gated), applied before first use:

<script>
if (typeof crypto !== 'undefined' && crypto.getRandomValues && !crypto.randomUUID) {
  crypto.randomUUID = function () {
    var b = crypto.getRandomValues(new Uint8Array(16));
    b[6] = (b[6] & 0x0f) | 0x40; b[8] = (b[8] & 0x3f) | 0x80;
    var h = [...b].map(x => x.toString(16).padStart(2, '0')).join('');
    return h.slice(0,8)+'-'+h.slice(8,12)+'-'+h.slice(12,16)+'-'+h.slice(16,20)+'-'+h.slice(20);
  };
}
</script>

Same guard belongs in JSS's loginPage() (and any other view whose inline JS reaches for crypto.randomUUID — grep says views.js:273 is the only site today).

Note: passkeys themselves (WebAuthn) won't work on insecure contexts regardless — but the page must not crash; it should degrade to password/Schnorr login cleanly.

Refs

• jspod#65 — downstream discovery + the page-side patch
• Vision: Solid Pod on Every Phone #46 — Solid Pod on Every Phone