What the server stores and logs
An exhaustive and concrete overview for security teams, DPOs and auditors: what is stored on the server in encrypted form and what as a public key or operational metadata, how long it is retained, who has access to what — and conversely what we don't track at all. No vague "we minimize metadata"; where the server sees an IP address, a timestamp or a transfer size, we say so.
In brief
The server is a dumb intermediary: it holds public keys and temporary encrypted packages, has no private key, and stores neither plaintext nor any contact details for the sender.
1. Principle: a dumb intermediary
The GrataQ server is deliberately designed as a passive carrier. Its only job is to accept an already-encrypted package from the sender, hold it for the duration of its validity and hand it over to the recipient — and beyond that, to publish public keys and signed one-time pre-keys so the sender knows what to encrypt with. The server has no private key: it holds neither the private identity key nor the private pre-key keys, and therefore cannot decrypt anything itself.
Both encryption and decryption happen exclusively on the end devices. File contents are encrypted already at the sender's end in the browser, and only the recipient can decrypt them in their app. Even if the server were compromised, an attacker would obtain only unreadable blobs and public keys — not the file contents — and could not slip in a forged key either, because the pre-key signature would not match against the recipient's verified domain.
2. What the server STORES
The data model on the server consists of four core entities — Account, PreKey, Blob and Session — supplemented by an optional recipient contact email and billing details on paid plans. The table below distinguishes whether a given item is stored encrypted (the server cannot see the contents), as a public key, or as metadata in readable form.
| Item | Form | Purpose | Retention period |
|---|---|---|---|
| Account identifier (ID) | public — derived from the public key (SHA-256 fingerprint of the public ML-DSA key) | addressing the recipient | for the lifetime of the account |
| Recipient's public ML-DSA key | public key | signature verification and identity | for the lifetime of the account |
| Branding (name, logo, verified domain) | metadata — non-editable data entered by the recipient | display to the sender on the upload page | for the lifetime of the account |
| Pre-keys (public ML-KEM key + ML-DSA signature) | public | key exchange for an individual file | until consumed — one-time use |
| Encrypted blob (the encrypted file) | encrypted — the server cannot see the contents | delivery of the file to the recipient | per the plan's retention / until collected |
| Session token | short-lived token | authentication of the recipient's session | short validity |
| Contact email for notifications | metadata — stored (only if the recipient enables it; paid plans) | notification of a new file | until the feature is disabled / the account is closed |
| Billing details | metadata — stored (paid plans) | issuing a tax invoice | per accounting and tax regulations |
3. What the server DOES NOT STORE
Just as important as what is on the server is what is never on it:
- No private key — neither the recipient's private identity key nor the private pre-key keys. Private keys never leave the recipient's device. Without them, nothing can be decrypted.
- No unencrypted data or file plaintext — the server sees only unreadable encrypted blobs.
- No sender email or phone number — the sender does not register, and the server keeps no contact details about them.
- No password — identity is a cryptographic key, not a password. The server therefore stores no password and no password hash.
Any sender details voluntarily filled in (e.g. a name or note, if the recipient requests them) are part of the encrypted package — the server sees them only in unreadable form, and they are read only by the recipient in their app.
4. What the server LOGS (operational records)
For secure and stable operation, the server keeps technical operational records. To be concrete, these typically include:
- the IP address of the request,
- the request timestamp,
- the size of the encrypted package (the number of bytes of the transferred blob),
- the type of operation (e.g. upload, collection, pre-key request, authentication),
- rate-limiting counters (limiting the frequency of requests).
The purpose of these records is security and protection against abuse (e.g. against DoS attacks and automated flooding). The records are retained only for as long as strictly necessary for these purposes.
Honestly about metadata
The IP address and the transfer time are visible to the server — they are metadata. In principle the server therefore sees who (from which IP), when and how large a package passed through, even though it cannot see the contents of the package. An attacker with access to the server would obtain communication metadata, but never the file contents.
5. Encryption at rest and in transit
Contents are encrypted already at the sender's end, before they ever leave the device: the payload is encrypted with AES-256-GCM using a key derived via ML-KEM (post-quantum key exchange) from the recipient's public pre-key. The server merely receives and stores the blob in this encrypted form — it has no key to decrypt it.
Transfer between client and server is additionally protected by TLS 1.3. Blobs reside in storage in the European Union only as unreadable data; content encryption is independent of TLS, so the contents remain protected even at rest in storage.
6. Who has access
- To the public keys (ID, public ML-DSA key, signed pre-keys, branding) — anyone. They are public by their very nature; they exist so that people can securely send files to you.
- To the encrypted blobs — effectively only the recipient. They alone hold the private key needed for decryption. No one else, not even the operator, can decrypt the contents.
- Operations staff — see only encrypted data and operational metadata (see section 4), never the file contents.
7. Retention and deletion
How long an encrypted blob remains on the server depends on the recipient's plan:
| Plan | Maximum blob retention |
|---|---|
| Free | 7 days |
| Professional | 30 days |
| Institution | 90 days |
| Enterprise | up to 180 days |
After collection, a blob can be deleted manually right away, or it is removed by automatic cleanup once its retention elapses; deletion is irreversible. Incomplete (interrupted) uploads are likewise cleaned up so that no orphaned fragments remain in storage. Details on the limits are in the pricing; for the legal framework of retention, see the privacy policy.
8. What we DON'T track at all
No user tracking
Neither the app nor this website runs any analytics, any third-party tracking cookies or any profiling. We do not build profiles of users or visitors, and we do not track their behavior.
9. Where the data resides (region)
All data — public keys, encrypted blobs and operational records — is stored on servers in the European Union.
Related documents: the detailed protocol and architecture in the whitepaper, the attacker assumptions and protection boundaries in the threat model, the key lifecycle in the key lifecycle document, and the legal framework for processing in the privacy policy.