Trust

What is verified, and what is not.

Written for a procurement or security review. Every claim here is checkable in the SDK’s published documentation or in this console’s source. Where the answer is “not yet,” the page says so.

Security posture

Maturity: 1.0.x. Public APIs and persisted formats follow semantic versioning.
What the SDK is: An independent implementation of the public Signal Protocol specifications, with each specification pinned by revision. It is not wire-compatible with Signal Messenger or libsignal, and it is not affiliated with Signal Messenger.
Audit status: Reviewed continuously by adversarial AI agents; not audited by any independent firm. Every change passes an adversarial AI review before it merges, and recurring whole-codebase AI audit passes run against the engineering repository. What that covers — and what it does not — is stated in the assurance summary. No independent firm has audited the SDK, and none is engaged.
FIPS 140: No validation, and this is structural. The cryptography is pure JavaScript, which cannot carry module validation in this form. If your rules require a validated module, stop the evaluation here.
Automated checks: Run in the private engineering repository on every change; a public export is cut only from a revision where they pass. Coverage and the most recent full run are stated in the assurance summary.
Public continuous integration: On every push and pull request to the public repository: npm ci against the committed lockfile, npm run build, npm run typecheck, and npm audit --omit=dev at moderate severity against the six production dependencies. The run logs are linked from the repository README.
Timing and memory: No constant-time guarantee. JavaScript engines provide no machine-level constant-time contract, so the code applies best-effort source-level patterns on selected paths and does not represent them as proofs.
What a relay receives: The relay never needs message plaintext or device private keys. It is not blind. It sees the outside of the envelope, and the outside of an envelope is real information.
Licensing: AGPLv3, or a commercial license. The security review checklist and the security and protocol policy carry the long form of everything above.

Vulnerability disclosure

Report privately: use Report a vulnerability on the SDK repository’s Security tab, or write to security@open-e2ee.dev. Do not open a public issue. Send a reproduction against a test identity, not message plaintext, private keys, or customer data.

Acknowledgment: Within 72 hours of the report.
Initial assessment: Within 7 days.
Resolution target: By severity: critical 24–72 hours, high 1–2 weeks, medium 2–4 weeks, low in the next release cycle.
Supported versions: 1.0.x
Safe harbor: Good-faith research on this codebase draws no legal action and no law-enforcement referral. The conditions are stated in SECURITY.md. Testing a deployed application that uses the SDK is governed by that application’s own policy.

What this console and Relay hold

The console has no database. It authenticates an account and reads the current entitlement from Stripe when a page or record is generated. OpenE2EE Relay stores only the encrypted delivery and operating state that its managed service requires.

Account identity: Held by WorkOS AuthKit: user id, email address, name, and the provider avatar URL. The console reads them from the session on each request.
Commercial records: Held by Stripe: customer, subscription, licensee, covered products, license profile, licensed components, fulfillment mode, term, status, and the accepted terms version and URL.
Managed Relay records: Cloudflare holds encrypted envelopes, encrypted attachments, public prekey material, scoped sender certificates, device push tokens, opaque account and project identifiers, routing timestamps and sizes, exact usage, lifecycle state, and security-journal fences. Relay uses these records for delivery, authorization, quota, recovery, and deletion.
Never held: OpenE2EE does not receive message plaintext, device private keys, ratchet state, attachment keys, or decrypted attachment content. Those values remain under the SDK's device-side storage contract.
In your browser: Integration checklist progress is stored in that browser only. The session cookie is host-only to console.open-e2ee.dev: it is not set for the parent domain and is not readable by the documentation or the website.
Documentation: The documentation reads nothing from the console. Every documentation page renders the same bytes for every reader, signed in or not.
License records: A license record is a versioned JSON summary of the Stripe entitlement, downloaded as an Ed25519-signed envelope that verifies offline against the published public key. The signature proves the record was issued here, not what the grant is; the executed commercial agreement controls the grant.

Subprocessors

Vercel

Application hosting

Console and documentation requests for console.open-e2ee.dev and docs.open-e2ee.dev

WorkOS

Authentication (AuthKit)

Account identity: user id, email address, name, and provider avatar URL

Stripe

Payments and subscriptions

Billing details, subscriptions, invoices, and the opaque Relay billing-project mapping

Cloudflare

Relay, website, DNS, and security infrastructure

Encrypted Relay payloads, public key material, opaque routing state, exact usage, and service request metadata

Expo, Apple, Google, and browser push services

Data-only push wakes

Device push tokens, delivery status, and a content-free wake signal

Better Stack

Availability monitoring and public status

Public endpoint health, incident state, and operator alert delivery

6 of 6 rows

This list covers the hosted website, documentation, console, and OpenE2EE Relay. A self-hosted SDK adapter uses infrastructure that the customer selects and operates instead. The two paths have separate trust roots, credentials, storage, and product scopes.

Legal documents

Commercial terms: Commercial terms startup-2026-07-23accepted at checkout and recorded on each license record
Open-source license: AGPL-3.0-or-laterthe alternative to a commercial license, with source obligations
Privacy notice: open-e2ee.dev/legal/privacy
On request: Data processing agreement, master services agreement, and W-9. Write to licensing@open-e2ee.dev.
Negotiated scope: Growth and Enterprise / OEM licenses are provisioned after a quote and a signed order form or MSA. Startup is the only self-service plan.

A security review, a questionnaire, or an enterprise evaluation starts on the contact page.