Security & Encryption

Protection levels at a glance

Encryption, hashing, and access control solve different problems. No service is hack-proof, and none of the controls below makes Comr anonymous. These are the current boundaries for the web service and browser service and native candidate.

• Passwords and message PINs — one-way Argon2 hashes. Comr verifies a submitted value without storing a decryptable copy. Rate limits protect the low-entropy six-digit message PIN. A PIN is an access gate; it is not a message-encryption key.
• Production transport — HTTPS/TLS.Browser traffic is HTTPS-only in production. The application's production database connection also requires certificate and hostname verification to resist a network man-in-the-middle.
• One-to-one browser content — end-to-end encrypted. New text, images, GIFs, and supported video are encrypted on enrolled participant browsers for enrolled recipient devices and have no server-readable fallback. Comr stores and relays ciphertext envelopes and opaque attachment objects rather than content.
• Older direct messages — separate legacy data. Older messages are not relabeled or shown as E2EE chat history. They remain server-readable while retained under the legacy retention policy.
• Com chats — access control, not message encryption. Com message bodies are server-readable application-layer plaintext. Membership permissions restrict access, but the bodies do not use the direct-message encryption envelope and are not end-to-end encrypted.
• Native iPhone messaging — separately gated. Native OpenMLS, App Attest, signing, and physical-device authorization stay fail-closed and do not inherit the browser authorization.

How the messaging encryption claim is verified today

Browser messaging has no server-readable fallback: legacy write APIs return unavailable, a database trigger permanently rejects legacy message writes, and the E2EE API accepts bounded per-device ciphertext envelopes. Device keys and decrypted local history stay in encrypted browser storage.

• Automated tests, run by Comr. Unit, browser, database-contract, native, and Rust tests exercise encryption, tamper rejection, replay handling, device changes, bounded inputs, and plaintext-egress controls on every release candidate.
• Reproducible artifact builds. The pinned protocol artifact was built twice independently on the pinned toolchain; both builds produced byte-identical output with aggregate SHA-256 7091a9a4b8a8edb9d32a6c72f010ae66331335b0f6e740349f98e5ac84a0c9d2.
• Independent security review: planned, not yet performed. Everything above is Comr's own engineering evidence, verified internally — not an independent audit. Commissioning an independent security review of the exact release candidate is a committed post-launch milestone, and its outcome will be published on this page. Until an independent reviewer signs off, Comr makes no independent-review claim.

Additional safeguards

• Hardened, HTTP-only session cookies with absolute and idle expiry, authentication-version revocation, and sign-out-all support.
• Same-origin checks for browser mutations, bounded request bodies, actor and network abuse budgets, and generic authorization denials.
• Private object storage, media grants, no-store caching for protected responses, and image decoding and re-encoding that removes metadata.
• A nonce-based Content Security Policy, framing protection, MIME sniffing protection, restricted browser permissions, and no referrer leakage.

Limits you should plan for

Authorized recipients can save, photograph, or republish content. A compromised browser, malicious extension, vulnerable dependency, server compromise, endpoint malware, participant disclosure, or valid legal process may defeat some protections. Encryption also does not hide all metadata, including account identities, conversation membership, timing, device count, and IP-level traffic.

Comr describes only authorized new browser one-to-one text and media as end-to-end encrypted. Com chats, legacy history, metadata, and unsupported file types are not E2EE. Native messaging remains disabled until its separate App Attest, signing, physical-device, notification, and rollback evidence passes. The independent security review is planned and has not yet happened.

Report a vulnerability

Send suspected vulnerabilities privately to contact@provarion.ai. Do not test against another person's account or send passwords, session cookies, private messages, identity documents, or exploit payloads through a public issue.