Skip to content

Commitment to Anonymity and Data Privacy

Overview

UnoLock approaches anonymity as an OPSEC problem, not just a marketing claim. Safe access is built around registered access keys, client-side encryption, end-to-end protected messaging and API payloads, and a payment model designed to stay separated from Safe contents and normal Safe identity. The result is a system that minimizes the amount of information UnoLock needs in order to operate.

How It Works

  • No Conventional Safe Accounts: Safe creation and Safe access do not depend on usernames, email logins, or stored passwords.
  • Access Keys Instead of Passwords: Users authenticate with passkeys, hardware keys, or compatible device authenticators through WebAuthn.
  • Client-Side Encryption: Safe data is encrypted before it leaves the client, so UnoLock does not hold the plaintext needed to read records or files.
  • End-to-End Protected Messaging and API Calls: Messaging payloads and protected API traffic are encrypted in addition to normal transport security.
  • Minimal Client Traces: UnoLock avoids browser storage patterns that are commonly used for tracking or session persistence.
  • Payment Separation: Billing is handled separately from Safe contents so routine payment operations do not need to expose what is inside a Safe.

Security Implications

  • Reduced Identity Coupling: Because Safe access is not built around a normal account/password model, there is less identity linkage to attack or subpoena in ordinary use.
  • Reduced Server Exposure: Client-side encryption and encrypted payloads limit what a server-side compromise can reveal.
  • Lower Tracking Surface: Fewer identifiers and less persistent client storage reduce the amount of correlation data available across sessions.

Use Cases

  • Privacy Advocates: Users can manage sensitive records without adopting a conventional cloud identity model.
  • High-Risk Professions: Journalists, activists, or whistleblowers can reduce identity linkage while protecting sensitive material.
  • Operational Security Workflows: Users who care about payment separation, minimal metadata, and device-bound access keys can keep those properties aligned in one system.

Why It Matters

Privacy in UnoLock is not one feature. It is the combined result of access-key authentication, client-side encryption, end-to-end protected payloads, limited browser traces, and payment separation. That approach gives users a stronger base for anonymity than simply hiding a username behind an encrypted database.

FAQs

Does UnoLock require an email address or password to open a Safe?

No. Safe access is based on registered access keys such as passkeys or hardware keys, not on a conventional email-and-password account model.

Is anonymity only about encryption?

No. Encryption is part of it, but UnoLock also relies on metadata minimization, limited client traces, and separation between billing and Safe contents.

Can UnoLock read what is inside my Safe?

No. Safe data is encrypted client-side before syncing, so UnoLock does not receive the plaintext needed to read the contents.

Compliance & Privacy Regulations

  • Privacy by Design: The architecture supports privacy-focused operation by minimizing plaintext exposure and reducing unnecessary identity coupling.

Integration with Other Features

  • No Browser Local Storage or Cookies Used: Reduces persistent browser traces.
  • Client-Side Encryption Using AES-256 GCM: Keeps Safe contents encrypted before sync.
  • Advanced API Security with AES-256 GCM and ECDHE_ECDSA: Protects sensitive client-server payloads in addition to transport security.