A browser can run strong cryptography; the code delivered to the browser still has to be trusted.
A browser can perform end-to-end encryption locally, including post-quantum key establishment, without installing a native messaging app. The difficult question is not whether the mathematics can run in a tab. It is whether the delivered application, key handling and update path deserve the trust the conversation requires.
Web-based access can be convenient when installation is unavailable. It does not make the app immune to censorship, compromised hosting, malicious extensions or a compromised device.
The browser's cryptographic building blocks
WebCrypto exposes low-level operations for encryption, key derivation, signing and key management. Common implementations provide primitives such as AES-GCM and ECDH. Those operations are building blocks, not a complete authenticated messaging protocol.
A web application can add a reviewed ML-KEM implementation using JavaScript or WebAssembly where the required native API is unavailable. Browser support changes, so developers should feature-test the exact target versions instead of assuming that every browser offers the same algorithms.
A conceptual hybrid flow is:
- Generate appropriate keys with cryptographically secure randomness.
- Authenticate the peer's key material using the protocol's identity mechanism.
- Obtain classical and post-quantum shared-secret contributions.
- Combine them using the specified key schedule and conversation context.
- Use derived keys for authenticated encryption, with correct nonce and state handling.
This is an explanatory outline, not an implementation recipe. FIPS 203 standardises ML-KEM; it does not certify a particular browser application or define every step of a chat protocol.
HTTPS delivery is part of the trust model
The server normally supplies the JavaScript and WebAssembly that will process plaintext. A maliciously changed application can read a message before encryption or after decryption, even if its cryptographic library uses sound algorithms.
HTTPS helps authenticate and protect delivery from network interference. It does not prove that the origin operator, its deployment system or its dependencies are uncompromised. A normal HTTPS web page is not automatically an independently signed application package.
The W3C WebCrypto security considerations discuss script injection and the need to protect application integrity. Content Security Policy, careful dependency management and other web security controls reduce risks, but none turns arbitrary same-origin script into an untrusted observer unable to touch application data.
WebAssembly also shares the application's security boundary. Its sandbox limits access to the host through defined interfaces; it does not make the calling page trustworthy. Compiling C to Wasm does not make the source language memory-safe.
Keys do not necessarily exist only in RAM
A browser messenger may persist keys or encrypted state so the user can return to the same identity. It may also offer device linking or encrypted recovery. Those behaviours must be documented rather than assumed away.
Questions worth asking include:
- Which keys are persisted, and in what browser storage?
- What happens when site data is cleared or a private-browsing session ends?
- Is a non-extractable key still usable by malicious code running in the application's context?
- Can a newly delivered update access old local state?
- Does recovery restore identity, message history, or both?
A non-extractable WebCrypto key restricts export through the API. It does not by itself prevent hostile application code from requesting permitted operations or collecting plaintext.
Web and native clients have different trade-offs
| Concern | Browser client | Native client |
|---|---|---|
| Distribution | Origin, hosting and web update pipeline | App store or package distribution and signing pipeline |
| Local persistence | Browser storage and profile behaviour | OS app storage and application lifecycle |
| Exposure | Same-origin scripts, extensions and browser vulnerabilities | Application dependencies and OS/app vulnerabilities |
| Availability | Reachable domain and required network services | Installed app still needs its required network services |
Neither column establishes a winner without examining the implementation. A web app may remain accessible after an app-store removal, but a blocked domain or missing network route can still prevent access.
Measure performance instead of promising it
ML-KEM-768 uses a 1,184-byte encapsulation key and a 1,088-byte ciphertext under FIPS 203. Those sizes help explain why protocols may schedule KEM updates rather than attach fresh material to every short message. They are not measurements of an entire application's bandwidth or speed.
A useful benchmark states the browser, device, build, warm-up method, operation measured and distribution of timings. Include page startup, module loading, memory usage, low-end devices and network overhead. Claims such as “under two milliseconds on all modern phones” require published measurements; this article does not supply them.
Applying this to Livara
Livara's security overview documents LVR1 and its recovery boundaries. Its Proof Lab demonstrates selected local P-256, HKDF and AES-GCM operations; the page explicitly places the full LVR1/LGS1 composition outside that bench. A passing demonstration therefore does not prove the security of all shipped web code.
Before a sensitive browser conversation, use an authentic maintained client, review the current threat model, protect the browser profile and verify the peer through the supported key-checking process. Convenience and useful cryptography can coexist, provided the web delivery boundary remains part of the assessment.
