-Version 1

Security and Data Handling

Security and Data Handling

Last updated: 2026-05-02

This page explains, at a high level, how Cloudless approaches security, backup integrity, and data handling.

1. Product Model

Cloudless is backup software that helps users back up data to storage providers they control. Cloudless is designed to prioritize encryption, recovery, and user control.

2. Encryption Approach

Cloudless performs all encryption on the user's device before any backup data leaves the device. The Cloudless server never receives the user's passphrase or any key that can decrypt file content.

2.1 Key Derivation and Custody

  • The user's passphrase is processed locally with Argon2id to derive a key-encryption key (KEK).
  • The KEK is used to encrypt a per-user data-encryption key (DEK) with AES-256-GCM.
  • The Cloudless server stores only the encrypted DEK ciphertext, the associated nonce, and the Argon2 salt. It never stores or sees the passphrase, the KEK, or the plaintext DEK.
  • A separate metadata key is derived from the DEK via HKDF-SHA256 for encrypting filename and path metadata, providing cryptographic domain separation between content and metadata encryption.

2.2 What Is Encrypted Before Upload

Before any data is uploaded, the following are encrypted on the user's device with AES-256-GCM:

  • file contents (split into fixed 4 MiB chunks, compressed, then encrypted)
  • file names and folder paths
  • backup source directory paths

2.3 What the Server Can See

To operate the service, the Cloudless server stores the following metadata in plaintext. Users should understand this when evaluating their threat model:

  • account email and display name
  • device identifiers and platform information
  • file sizes (in bytes), file modification timestamps, and version counts
  • SHA-256 hashes of plaintext chunks, used for per-user content-addressable deduplication. Because hashes are computed on plaintext, the server could in principle detect that a user has backed up a chunk matching a known hash. Hashes are scoped per user.
  • a deterministic HMAC ("blind index") of filenames, used to look up encrypted filename records by exact match without revealing the name
  • backup, restore, and billing operational state
  • service and security logs

2.4 What the Server Cannot See

The server does not have access to:

  • the user's passphrase
  • the data-encryption key or any key derived from it
  • the plaintext contents of any file or chunk
  • plaintext filenames or folder paths

2.5 Object Storage

Encrypted chunks are written to the user's chosen object storage provider (for example AWS S3 or Backblaze B2). Object storage receives only compressed-and-encrypted chunk ciphertext keyed by content hash. No plaintext metadata is written to object storage.

2.6 Recovery Implications

Because encryption keys are derived from the user's passphrase and never leave the device in plaintext, Cloudless cannot recover backup data for a user who loses their passphrase and recovery material. This is a deliberate property of the design, not a limitation we can work around on a per-user basis.

3. Storage Model

Cloudless generally relies on third-party storage selected by the user, such as AWS S3, Backblaze B2, Google Drive, or other supported providers.

Cloudless does not market itself as a primary raw storage provider. The user is responsible for:

  • selecting and maintaining the storage provider account
  • paying provider storage costs where applicable
  • ensuring sufficient capacity and access

4. Access Controls

Cloudless uses reasonable administrative, technical, and organizational measures to protect account information and service infrastructure, including:

  • authenticated access controls
  • encrypted transport (TLS) for all client-server communication
  • restricted infrastructure access
  • operational logging and monitoring

4a. Incident Notification

In the event of a confirmed security incident affecting account information or service infrastructure, Cloudless will notify affected account holders without undue delay after the incident is identified and understood, consistent with applicable law. Where required by applicable law (for example GDPR Article 33), Cloudless will also notify the relevant supervisory authority within the legally required time frame.

Because file contents and filenames are encrypted on the user's device with keys Cloudless does not hold, a compromise of Cloudless server infrastructure alone does not give an attacker access to plaintext backup content.

5. Backup Integrity

Cloudless is intended to help users create recoverable backups and support restore workflows. As with any backup system, users should periodically test restore procedures to confirm the service works for their environment and risk tolerance.

6. Shared Responsibility

Cloudless security depends in part on user behavior. Users are responsible for:

  • securing their devices
  • securing their accounts
  • protecting encryption passphrases or recovery material
  • testing restores
  • maintaining access to the chosen storage provider

7. Limitations

Cloudless may not protect against every failure mode. Risks can still arise from:

  • compromised user devices
  • malware with access to unlocked files
  • credential theft
  • loss of recovery material
  • failures or policy actions by third-party storage providers

8. Security Reporting

To report a suspected security issue, contact:

  • support@trycloudless.io

Please do not include sensitive personal data or secrets in an initial report unless necessary.

Back to Home