Current Security Architecture

Current architecture of the Dossira private preview

This document describes the behavior we can currently verify in the application source. It is not a list of planned controls.

1. Application scope

Dossira currently builds on an organisation-bound file workspace with:

folder and file browsing;
upload, preview, and download;
common file operations;
internal workspace membership;
owner-created external shares;
optional E2EE for supported file-content operations.

Comments, decisions, a room activity ledger, sealing, audit export, billing, and quota enforcement are not currently part of the private-preview product surface.

2. Authentication and recipient access

Internal members

Registered internal members can choose a passkey on supported devices through the host identity system. The same login selector also provides email-password and magic-link sign-in, so passkeys are preferred rather than mandatory or exclusive.

Passkey availability depends on WebAuthn support and an available authenticator. Dossira does not publish a universal browser, device-sync, or recovery guarantee. Login passkeys are also distinct from the personal and workspace keys used by optional E2EE.

External recipients

External recipients currently use:

confirmed-email sharing with PIN verification; or
an explicitly created public link.

External recipients do not currently receive the same member-passkey flow. Share expiry, revocation, extension, and reissue are implemented.

Revocation stops later access through the Dossira share. It cannot erase files already downloaded or copied outside the service.

3. Transport and infrastructure encryption

The reviewed production web and API endpoints use HTTPS. The reviewed service-mesh configuration uses strict mTLS between mesh services, and the current infrastructure documentation records encrypted disks for application, database, object-storage, failover, and backup servers.

These controls protect data in transit and on the underlying server disks. They are separate from optional client-side file-payload E2EE and do not mean that every stored object uses a customer-controlled application key.

4. Optional E2EE boundary

The application supports optional workspace E2EE in the store-first file path for file payload upload, preview, and download.

Important limits:

E2EE is optional, not the default behavior of every workspace;
it protects supported file payload operations, not all workspace data;
filenames and folder metadata remain outside the E2EE boundary;
guest-sharing flows do not yet provide equivalent E2EE support;
mirror-backed file operations do not use the same E2EE path.

The website therefore does not claim that Dossira is blind to filenames, all metadata, or guest-shared content.

Encrypted-workspace key access and recovery depend on the configured member and workspace-key flow and must be tested for the deployment. Dossira does not publish a universal provider-recovery, provider-blind, or cross-device guarantee.

5. Hosting boundary

Dossira is provided by a Norwegian company. Customer data and user identities are hosted on Hetzner infrastructure in Germany and Finland. Dossira does not use AWS, Microsoft Azure or Google Cloud for this hosting.

For controller/processor roles, service providers, and transfer information, see the Privacy Policy and Data Processing Agreement.

6. Activity records and audit claims

The underlying system retains narrow operational records:

resources and uploaded versions retain creator and timestamp fields;
share tickets retain creation, update, expiry, and revocation details;
confirmed-email challenges retain send, attempt, consumption, and invalidation state.

The current product does not expose a complete customer-facing event ledger or audit export. In particular, this audit did not verify durable customer-visible events for every room entry, failed entry, file preview, file download, membership change, seal/close action, or export.

We therefore do not currently claim that:

every access is recorded in a customer-visible ledger;
every key action is available for audit;
a complete activity record can be exported.

7. Room lifecycle and sealing

A room sealing or close-and-export lifecycle is not implemented. There is no current room-level read-only transition, seal-triggered version lock, closing manifest or export, reopen action, billing rule, or seal actor/timestamp. Read-only external guest access is a share capability, not room sealing.

Current workspaces must not be described as sealed, immutable, tamper-proof, permanent, or legally conclusive.

8. Reporting a vulnerability

If you believe you have found a vulnerability, use the Contact page and identify the report as security-related. Do not include confidential customer content in an initial report.