Privacy policy.

1. Information the service handles

• Account and authentication: your name, email address, password hash, verification and recovery records, and configured authentication factors or passkeys. Your password is submitted to the authentication service when using password-based registration or sign-in.
• Workspace information: teams, channels, invitations, membership and roles, sender and recipient identifiers, message timestamps, read positions, preferences, typing and online presence.
• Encrypted records: message ciphertext, encrypted attachment objects, public encryption keys, encrypted key backups, key delivery records, and ciphertext sizes. Encryption does not hide who participates, when messages are sent, or their approximate sizes.
• Technical information: connection information such as IP addresses and request details, sessions and API tokens, and errors or logs produced by the deployed infrastructure. Actual log fields and retention depend on deployment and still need to be documented.
• Search and support: web search terms are sent to the service to request encrypted candidate messages; text matching happens after client-side decryption. Information you choose to email to support is handled outside Lock messaging and is not protected by Lock’s message encryption.

2. What encryption protects

The current web and native clients encrypt new message bodies and attachments before upload. New attachment contents and filename metadata are encrypted; authenticated participants’ clients decrypt them. Older, legacy attachments may have been uploaded without this encryption and have not been retroactively encrypted.

This is not a zero-knowledge guarantee. The account password used to protect encrypted private-key backups is also submitted for authentication; a compromised authentication server could capture it and unlock those backups. Recipient public keys come from the service without independent fingerprint verification. Web-delivered code and unlocked devices are also trust boundaries.

Updated voice-call clients use WebRTC media encryption and automatic chat-key possession checks, without independent code comparison. First-use keys are trusted through server signalling; public identity pins remain locally in browser storage or the native Keychain across sign-out, scoped to your account and teammate, and are not synchronized with the server. Later calls prove the same identity automatically; a changed remembered key blocks calls. Call authentication inherits the password-backed chat identity’s recovery risks, and cannot protect a stolen private key or first-contact key substitution by compromised signalling. Ephemeral signing keys and challenges are released at teardown. Call signalling includes participant identifiers, public chat and signing keys, signatures, encrypted identity challenges, authentication proofs, public transcript hashes, and connection negotiation information. Public Google STUN services, configured TURN relay providers, and the other participant can receive network addressing and connection metadata. TURN relays forward encrypted call traffic; calls are not an anonymous networking service. Authentication does not protect a compromised device or malicious web-delivered code.

See the security details for key recovery, forward-secrecy limitations and published encryption evidence. No independent security audit is currently published.

3. Why information is used and disclosed

Account and operational information support authentication, workspace access, message and file delivery, invitations, read indicators, service troubleshooting and responses to support requests. Workspace members and administrators can see information exposed by their permissions, such as membership, roles and participating conversations.

Operating the service involves infrastructure for hosting, storage, email delivery and realtime connections. A confirmed provider list, processing locations, and any international-transfer safeguards must be added before this policy is final. We do not claim that encrypted content eliminates providers’ access to operational metadata.

Information may also need to be disclosed to meet applicable legal obligations or address security incidents. Specific legal grounds and jurisdiction-dependent disclosures require confirmation by the legal operator. Do not send sensitive secrets in a support email.

4. Cookies and local device storage

The web app uses session and request-protection cookies for sign-in and authenticated actions. Browser storage holds encryption material, message keys, cached content and interface preferences. Native apps also keep authentication or key material and local preferences on the device. An unlocked device or browser may therefore contain readable content even though uploads are encrypted.

Signing out is not a remote wipe of another device, a recipient’s downloads or screenshots. Clear local site data and downloaded files when leaving a shared device. Blocking required cookies or clearing key storage may prevent sign-in or access to older encrypted messages.

A final deployment review must identify any optional analytics or third-party cookies and their controls; this draft does not assert an audited absence of tracking.

5. Retention and deletion timing

Pricing currently advertises 30 days of history for Basic and unlimited history for Pro. Plan-based retention is not currently enforced. Do not rely on a message disappearing after 30 days, or on “unlimited” history as a permanent backup guarantee.

Stored message records remain unless removed through an available deletion action or another implemented cleanup process. Unfinished encrypted uploads have a configured staging expiry; expired and orphaned file objects have cleanup commands. Physical removal depends on those jobs running successfully and is not guaranteed to be immediate.

Fixed retention periods for account records, support correspondence, logs and backups are not yet confirmed. Deleting a live record does not establish when every backup copy is removed. Any legally required preservation and backup rotation periods must be documented before launch.

6. Your choices and account deletion

You can update account details in web profile settings. Where available, choose Delete account and confirm your current password. The current deletion action removes the user record and signs out the requesting browser; related database records are removed according to their relationships, including messages authored by that account. This can affect shared conversations.

Account deletion is not the same as securely erasing every file object, backup, log, other device, or recipient copy. File cleanup can be deferred. Workspace deletion and leaving a workspace are separate actions; neither should be assumed to erase every historical record.

If you cannot access your account, or want to request access, correction or deletion of personal information, contact the team. Identity or account-control verification may be necessary. Rights and exceptions depend on applicable law; this draft does not promise a response deadline that has not been established.

Lost encryption keys may make content unrecoverable. Resetting an account password does not by itself recover old encrypted messages.

7. Questions and updates

Use the contact page for privacy questions or requests. Changes to this document will carry an updated date. Material changes and any required notices need an appropriate publication and notification process before the final policy is adopted.

Read the terms of service alongside this policy.