Your conversations.
Encrypted at the source.

Encryption goes beyond the message.

Each message uses a fresh encryption key, protected for the conversation’s keyed recipients. Each new file has its own random key. File contents, filename, file type and original size are encrypted before upload. Downloads require authenticated access, and the client decrypts the file locally.

This describes new encrypted uploads. Older web attachments previously uploaded to public storage are not retroactively encrypted.

Content privacy and workspace information.

Content encryption protects message bodies and new files. Account information, team membership, sender and conversation identifiers, timestamps, network requests and ciphertext sizes remain visible to the service so it can route messages and operate your workspace. The service also stores public keys and encrypted private-key backups.

Device security matters too: an unlocked or compromised device can expose the messages and keys available on it. Use your device’s screen lock and keep its software up to date.

Bring your keys with you.

Encrypted private-key backups support recovery on another device. A previously configured recovery key or an existing unlocked device can also help restore the original key. A password reset restores account access, but cannot recreate a lost encryption key. Keep your recovery method safe: losing every usable key and recovery method can make history permanently unreadable.

Password-based recovery trusts the sign-in service. It uses the same password submitted for authentication, so a compromised authentication server could capture that password and unlock the stored backup. This recovery flow is not zero-knowledge authentication.

How recipient keys are managed.

Lock delivers recipient public keys through the service. Independent fingerprint verification is not currently available, so key distribution is part of the trust model. Browser users also trust the application code delivered by the service.

Recovery support and forward secrecy are different properties. Because messages include RSA recovery capsules, we do not claim strict forward secrecy against later theft of a recipient’s RSA private key.

Voice calls have their own security model.

Updated call clients use WebRTC DTLS-SRTP for encrypted audio with fresh media and signing keys on each call. Chat-key possession checks run automatically, without code comparison. First-use keys are trusted through authenticated server signalling and remembered locally only after mutual possession proofs succeed. Changed remembered keys block calls and are not silently replaced. Without independent comparison, first-use trust depends on the service: a compromised signalling service could substitute an identity on first contact. This is not independently verified peer identity.

Identity pins detect key substitution, not a stolen private key. Call authentication now inherits the chat identity’s password-backed recovery limitation: a compromised authentication server could capture the account password and unlock that identity backup. Pins do not add identity verification to chat messages. The signaling service and TURN relay do not receive media keys through the call protocol, but still see connection metadata. Compromised devices or malicious web-delivered code can defeat client-side protections. Automated WebCrypto/CryptoKit interoperability checks are not an independent security audit; live cross-device verification and deployment review remain separate checks.

Evidence you can check

• Attachment v1 protocol and API notes document the fields, nonces, authentication data, limits and legacy behavior.
• Call authentication protocol and threat model documents the signed handshake, automatic first-use trust, mutual possession proofs, media gate and remaining trust boundaries. This is implementation evidence, not an independent audit.
• Download the public AES-GCM test vector. It contains test-only keys, encrypted data and expected plaintext—not customer data.
• Download the CryptoKit format verifier. Run it with the vector on a Mac. Automated WebCrypto tests check the same vector, round trips, incorrect keys and tampering.
• Algorithm references: W3C WebCrypto AES-GCM and Apple CryptoKit AES.GCM. These document the primitives, not an endorsement of Lock.

These checks demonstrate format compatibility and authenticated-encryption behavior. Deployment review and signed-in web-to-native interoperability testing are separate verification steps.

Independent review: No independent security audit is published here. These implementation checks are not an independent audit or certification.