The Browser Tab Is a Different Trust Zone: Web vs Android End-to-End Encryption

Short answer: the encryption is identical, the trust zone is not. Livara Chat on Android and Livara Chat in a browser both seal direct messages with LVR1 — a hybrid post-quantum double ratchet built from ECDH P-256 and ML-KEM-768 — and both use SRP so your password never crosses the wire. But the Android app runs inside an install whose bytes you can hash and check, while the web client runs inside a browser that may be hosting extensions you did not write, cannot audit, and never think about. That is why "is a web-based encrypted messenger as safe as the Android app?" is a threat-model question before it is a cryptography question — and why any web vs native app encryption comparison has to start with the runtime, not the cipher.

Key takeaways

• Livara's cryptography does not change between web and Android: direct messages use LVR1, private groups use LGS1 sender keys sealed inside pairwise LVR1 envelopes, and both derive every message key from ECDH P-256 and ML-KEM-768 together.
• The browser's weak point is not the cipher, it is the runtime — an extension with page access can read text the page has already decrypted, and it never has to break anything to do it.
• The Android app's advantage is verifiability: Livara publishes SHA-256 checksums for the APK, and the Proof Lab lets you compare them locally and offline.
• A browser has one real advantage of its own: the client code is fetched fresh on every load, so there is no stale build sitting on your device with months-old fixes missing.
• End-to-end encryption protects message contents in transit and on the server; it does not protect a device that is already compromised, and it never protected Livara's public broadcast channels, which are unencrypted on purpose.

Is a web-based encrypted messenger as safe as the Android app?

For message contents, yes — the ciphertext is the same and neither client hands the server a key. For the surrounding attack surface, no: a browser tab is a more crowded room than a native app, and "safe" gives different answers depending on which of those two questions you meant.

Split the word. On the server side, web and Android are indistinguishable. Both encrypt before anything leaves the device, both use AES-256-GCM with a 12-byte nonce and a 16-byte tag, and both derive keys through HKDF-SHA-256. A server operator sees the same thing from either client — ciphertext — plus standard routing metadata: sender, destination, delivery timestamps, kept for real-time device synchronisation. That second layer is covered in what messaging metadata still reveals.

On the client side the two diverge, because "safe" there means "who else can reach the plaintext once it has been decrypted on my machine." That question has a different answer in a tab. Livara's published threat model sets out who sees what at each stage; the rest of this article is about the one boundary that changes when you move from an installed app to a page.

Where does the browser tab become a different trust zone?

A trust zone is the boundary inside which software is allowed to see plaintext. On Android, that boundary is roughly the app's own process. In a browser, it is the page's JavaScript context — and the page is not alone in that context.

Once your message is decrypted for display, it exists twice: in memory and as rendered text in the document object model (DOM), the tree of elements a browser builds for every page. The DOM is not a private scratchpad. It is the surface every script with access to that page can read from. A content script injected by an extension reads the same nodes your messages are drawn from — no exploit required, just the permission the extension already has.

This is also true of a native app in principle. Accessibility services can read screen contents, screen recording can capture them, a rooted or jailbroken device can reach into app memory. The difference is the size and the visibility of the crowd. A phone has a handful of system-level services that might read your app, most of them named and permission-gated. A browser profile can carry dozens of extensions, each one a small program with its own update cycle and its own idea of what it needs to see. For the general shape of what end-to-end encryption does and does not cover, that distinction is the whole point of what end-to-end encryption actually protects.

Do browser extensions see decrypted messages? Third party browser extension privacy risk

Yes, in one specific and common case: an extension that has been granted access to the site can run a content script inside the page and read the same DOM your messages render into. It does not need to break LVR1, because the plaintext is already sitting there.

The limits matter as much as the risk. Extensions only reach pages they have permission for — the Chromium project's extension documentation describes host permissions and content scripts as the mechanism, and an extension without access to that origin cannot read it. A well-behaved password manager, for example, reads the fields it was granted and nothing else. But permission review by a store is not a security guarantee, and an extension that is compromised after installation keeps whatever access it was granted on day one. Nor can you check from inside a page which extensions are currently running against it.

The practical mitigations are boring and effective: use a dedicated browser profile with no extensions for private conversations, keep your everyday browsing in a different profile, or move the sensitive conversation to the native app, where the number of things that can reach into your session is far smaller.

What is the threat model for private messaging in a browser tab?

A threat model is the list of who might try to read your messages and what each of them would need in order to succeed. For a browser tab, that list is longer than most people assume: extensions with host access, script injected by any other page sharing the profile, screen-sharing and remote-support tools, someone with physical access to an unlocked device, and clipboard or autofill features that quietly pick up what you paste.

Notice that none of those attackers need to defeat hybrid post-quantum encryption. They attack the one moment the message is plaintext on your side of the pipe. That is the honest shape of the claim: Livara's published security boundaries are about what the protocol guarantees, and a protocol cannot guarantee anything about a runtime that has already been compromised. Your device is the end in end-to-end encryption, and it is the part Livara does not control.

How does WebCrypto end-to-end encryption work in a browser, and where does it stop?

WebCrypto is the W3C Web Cryptography API, exposed to JavaScript as window.crypto.subtle, and it gives a page vetted implementations of AES-256-GCM, ECDH P-256, HKDF-SHA-256 and ECDSA P-256 without the page shipping its own mathematics. That is meaningfully safer than a hand-rolled cipher written in JavaScript, because the hard part of cryptography is rarely the algorithm and almost always the implementation.

Where it stops is precisely where it matters. WebCrypto protects the primitives, not the page. A key created with extractable set to false cannot be exported — a property described in the Web Cryptography API specification — but the page can still call decrypt with it. Non-extractable keys stop key theft; they do not stop plaintext theft. The attacker who reads the rendered message never touches the key at all.

There is a second, quieter limit. ML-KEM-768, standardised in NIST's FIPS 203, is not part of the WebCrypto algorithm set that browsers are required to expose. In practice a web client brings its own ML-KEM implementation rather than calling window.crypto.subtle for it, which means the post-quantum half of the handshake has a different trust story from the AES-GCM half the browser implements natively. That is a support-matrix question rather than a permanent fact — check current browser support before relying on either path.

Livara Chat verifiable builds: why APK integrity matters for the Android app

Because it turns "trust us" into "check us." Livara publishes SHA-256 checksums for its Android build, and the Proof Lab recomputes that hash in your browser, offline, so you can compare it against the APK you actually downloaded and against the value Livara published. No account, no server round-trip.

Two mechanisms are doing different jobs here. Android's APK Signature Scheme v2 and v3, described in Android's developer documentation, signs the whole file, so a tampered APK fails verification at install time. A published SHA-256 checksum answers a narrower question: is the file I have the file Livara shipped, byte for byte? Both matter, and neither is a proof of correctness.

State the limits in the same breath. A checksum proves the bytes match; it says nothing about whether the code has a bug. And if you obtain the APK and the checksum from the same impostor site, the comparison proves nothing — it is only as good as where you got the reference value. Identity is a separate check, and that is what safety numbers (v3) are for: two people compare key fingerprints out of band, and a changed key becomes visible. The mechanics of how to verify an encrypted chat with safety numbers work the same on web and on Android.

Encrypted messenger web client security: what Livara Chat on web and Android share, and where they differ

They share almost everything that matters cryptographically. Both use ECDH P-256 with ML-KEM-768 for key agreement, HKDF-SHA-256 for derivation, AES-256-GCM for authenticated encryption, and ECDSA P-256 with SHA-256 for signatures. Both authenticate you with SRP — the Secure Remote Password protocol, standardised in IETF RFC 5054 — so your password is proven, never transmitted. Both encrypt every attachment, including photos, videos, files, captions and voice notes, under a fresh random 32-byte content key that travels inside the encrypted envelope. Both protect call media with WebRTC DTLS-SRTP (IETF RFC 5764). Both support safety numbers and encrypted key recovery, which seals your cryptographic identity under a 256-bit recovery key derived from your recovery phrase.

And both are equally clear about the one thing that is not private: channels are public broadcast streams by design, deliberately unencrypted so that reports can be acted on and channels used for abusive material removed. That is true in the app and in the browser, and it is stated in Livara's published security boundaries rather than buried.

Where they differ is the runtime, and it cuts both ways. Android gives you a fixed install you can hash; the browser gives you code that is re-fetched on every load, so a fix reaches you the moment it ships. Android gives you a smaller set of neighbours in your session; the browser gives you convenience and a profile full of extensions. Pick the one whose weaknesses you can live with, and use the other when the situation changes.

Frequently asked questions

Can a browser extension read chat messages in Livara Web?

They can, if the extension has been granted access to the site. Livara decrypts messages in the page and renders them into the DOM, so an extension running a content script there can read the same text you see. It does not break the encryption — the plaintext is already present. An extension without permission for that origin cannot reach it.

Is Livara's encryption weaker in a browser than in the Android app?

No. Both clients use the same primitives and the same LVR1 double ratchet for direct messages, with LGS1 sender keys sealed inside pairwise envelopes for groups. The difference is not strength but exposure: a browser page has more things running alongside it, so the same ciphertext sits inside a busier runtime.

How do I check that my Android app is the real Livara build?

Compute the SHA-256 hash of the APK you downloaded and compare it against Livara's published checksum. The Proof Lab does the hashing in your browser, offline, so the comparison does not depend on Livara's servers being honest at that moment. Get the reference checksum from the official source, not a mirror.

Does end-to-end encryption protect me if my device is already compromised?

No, and no messenger can honestly claim otherwise. End-to-end encryption protects messages in transit and stored on the server. Once a message is decrypted for display, malware, a screen recorder, an accessibility service or a hostile extension on your device can read it. The device is the endpoint the protocol cannot defend.

Are Livara channels end-to-end encrypted?

No, and that is intentional. Channels are public broadcast streams — one author publishing to an unbounded audience — so they are unencrypted, which lets Livara act on reports and remove content. Direct and group conversations are fully encrypted; broadcast channels are readable by design, and Livara says so plainly.