Dossira

Current End-to-End Encryption Scope

Optional E2EE in the current private preview

Dossira has an optional workspace E2EE path for supported file-content operations. The current implementation should be understood as file-payload E2EE, not yet as complete room E2EE.

What is protected

In the store-first file path, an enrolled workspace member can use E2EE for:

  • file upload;
  • file preview;
  • file download.

The file payload is encrypted and decrypted through a host-provided workspace E2EE adapter.

What is not protected by this boundary

The current E2EE boundary does not cover:

  • filenames;
  • folder names and folder metadata;
  • all operational resource metadata;
  • the mirror-backed file path;
  • external guest-sharing flows with equivalent E2EE behavior.

This means the service must not be described as unable to read filenames or all workspace metadata.

Members and external recipients

The supported E2EE path is tied to enrolled workspace members and their workspace encryption capability.

A member login passkey and an E2EE personal/workspace key are distinct concerns. Successful account sign-in does not by itself prove that the required encrypted-workspace key can be unlocked on that device.

External recipients currently use confirmed-email PIN verification or an explicitly created public share link. Guest mode does not yet have the same encrypted-content parity as the owner/member flow. A confidential workflow should therefore not be marketed as end-to-end encrypted for external guests until that path is implemented and tested.

Operational trade-offs

E2EE introduces real operational constraints:

  • a user may need to unlock encrypted file actions with a passkey;
  • membership and encryption-key enrollment must be complete before encrypted operations work;
  • recovery behavior must be tested for the deployed configuration;
  • cross-device key access must be tested rather than inferred from passkey sign-in;
  • integrations that need readable file content cannot operate across an E2EE boundary without changing that security model.

Product-status statement

Optional file-content E2EE is a real foundation in the current application. Complete confidential-room behavior—including encrypted filenames, equivalent external-recipient support, verified recovery, activity history, and sealing—remains incomplete.

Public copy must preserve that distinction.

Frequently asked questions

Is every Dossira workspace end-to-end encrypted?
No. E2EE is an optional workspace capability for supported file-content operations; it is not the default behavior of every workspace.
What is encrypted end to end?
In the supported store-first flow, file payload upload, preview, and download can use workspace E2EE for enrolled members.
Are filenames and folder metadata encrypted end to end?
No. Filenames and folder metadata currently remain outside the file-content E2EE boundary.
Do external guest shares have the same E2EE support?
No. External guest-sharing flows do not yet provide equivalent owner/member E2EE behavior.
Can Dossira recover an encrypted file if all authorised keys are lost?
The recovery behavior depends on the configured workspace key and membership flow. It must be tested for a deployment before relying on it; the website does not promise universal provider recovery.