Cryptographic core
Hybrid key agreement, AEAD, ratchets, sender keys, wire formats, and protocol tests.
Technical overview
Architecture and assurance status
Source map, trust boundaries, known limitations, and current verification status. This is not an independent audit.
Source map
Identity and local storage
Identity material, recovery, key sealing, recipient records, and keyserver access.
Application protocol
Send, receive, whitelist, burn, expiry, account switching, and group sender state.
Keyserver and payments
Cloudflare Worker routes, D1 state, Stripe webhook verification, activation claims, crypto invoices, and aggregate reporting.
Desktop boundary
Tauri commands, capabilities, hosted service views, bootstrap, and local trusted UI.
Cryptographic design
OSL combines X25519 with ML KEM 768 for hybrid key establishment. Message protection uses authenticated encryption. Direct messages use recipient specific encrypted slots, sealed per message.
Group scope protection is Planned and is not what the shipping client does. Group chain code with locally held mutable state exists in the source, but the feature is disabled by default in the client and the construction carries no signature identifying the sender, so a receiver cannot bind a group message to the account that sent it. An independent review also found that the live native path does not use the sender keys the documentation previously claimed. Do not rely on group or channel protection until that is implemented, reviewed and re-stated here.
Source inspection shows the Hub identity path seals long-term private identity keys with a persistent TPM or operating-system credential-store sealer and refuses identity creation when neither is available. That device-sealing boundary is not a whole-profile guarantee: peer-map, membership, and other conditional JSON can be plaintext when no main-password storage key is installed; Hub configuration, renderer localStorage, provider-managed profiles, the active-slot marker, and a fixed-label startup trace can also be plaintext; and removing the storage key restores plaintext writes. This is not verification of installed release bytes or a particular user profile.
Public identity material and encrypted control messages may pass through the keyserver. A connected service receives the encrypted carrier and can still observe delivery metadata.
Same account use on multiple machines remains a protocol risk. Independently initialized machines can have different identity keys, and mutable group sender state is not synchronized. Do not treat multi device group use as solved until device certificates and state coordination ship.
Trust boundary
Trusted locally
The OSL process, cryptographic implementation, local key store, trusted controls, and the device running them.
Not trusted with plaintext
Connected social and email services, Cloudflare, Stripe, the crypto watcher, network observers, and hosted service pages.
Visible metadata
Service account identity, recipients, groups, timing, network addresses, encrypted message size, and payment metadata required by the chosen payment rail.
Outside the model
Compromised endpoints, cameras, recipient capture, malicious accessibility software, voice, video, and plaintext sent in normal mode.
Payment and activation path
- The browser generates an RSA OAEP key pair and a random claim capability.
- The backend prepares an activation code before redirecting to Stripe. It stores the code hash, RSA ciphertext, and a hash of the claim capability.
- Stripe signs the live webhook. The Worker rejects events marked as test mode.
- The success page presents the claim capability and decrypts the returned activation code in the original browser tab.
Bitcoin and Monero invoice delivery exists, but purchase checkout is paused with card checkout until one-month redemption and expiry are implemented. The invoice path derives a unique Bitcoin address from a watch only wallet or a unique Monero subaddress from a view only wallet. A local node watcher confirms payment and can deliver an activation code encrypted for the checkout browser. The payment watcher holds no spending keys.
The intended purchase is a single charge for one month of Pro, with no stored payment method, customer profile, recurring mandate or account. No redemption record exists yet: current licence rows have a licence hash and status, but no redemption timestamp. The payment and credit records contain no message text, no conversation names, no carrier text and no recipient identity, and the licence validation endpoint receives no conversation, group, recipient or connected service activity.
The Telegram operator bot exposes aggregate payments, downloads, and activation counts only to approved operator accounts. It does not receive card details, customer email addresses, activation codes, wallet identities, or message data.
Licenses and reporting
The desktop client and backend repository use Apache 2.0. The website repository uses AGPL 3.0. Deployment secrets, payment credentials, release signing keys, and user private keys are not source code and are not published.
OSL is otherwise fully open source. The only exception is the optional AutoScrub module, which will stay closed source purely to make trivial cloning harder. That module does not exist yet, so everything OSL ships today is open. The exception does not extend to cryptography, trust and identity, deletion receipts, data formats, policy contracts, free Scrub, or the default client. The module is not installed by default, a Pro user consents to it after a plain closed-source warning, and a reproducible fully open-source build remains usable without it.
To report a security issue, email OSLPrivacy@gmail.com. Do not include private keys, passwords, activation codes, or account tokens.