ChronoSeal Privacy Policy
ChronoSeal is a privacy-oriented browser attestation system. It is designed to validate short-lived session continuity without creating persistent user profiles.
This document describes what ChronoSeal itself collects and stores. Applications that integrate ChronoSeal may collect additional data under their own policies.
Data ChronoSeal Processes
ChronoSeal processes only the minimum protocol parameters needed to validate a live browser session. We collect no personal data, identifiers, or tracking tokens.
| Data Parameter | Core Purpose |
|---|---|
session_id |
Opaque session lookup key. Generated randomly, unrelated to user identity. |
| Public Key | Required to verify signed heartbeats for the specific session. |
salt |
Rotated material used for secure hash-chain progression. |
initial_hash / prev_hash |
Provides replay-resistant cryptographic continuity. |
| Timestamp | Enforces drift bounds and liveness thresholds. |
| Mouse Event Samples | Lightweight validation of input activity plausibility. |
| VM Stack State | Verifies correct execution of the randomized math program. |
| Fingerprint Fields | Sanity validation (Screen aspect ratio, device pixel ratio, concurrency CPU count). |
| Gene Commitment | Verifies client execution of server-issued synthetic gene mutations. |
| Expiration Time | Manages session lifecycle and garbage-collection checks. |
Data ChronoSeal Does Not Collect
ChronoSeal is built on the principle of data minimization. It does not collect, process, or build databases of:
- Personal information (names, emails, logins, accounts).
- Browser history or page navigation tracks.
- IP address history or device fingerprints across multiple sessions.
- Location history or geological coordinate lookups.
- Cross-site tracking identifiers or cookie graphs.
Session Lifetime & Expiration
Sessions are short-lived. By default, they expire after 30 minutes (configurable via expiration_minutes). Expired sessions are continuously purged from memory and storage by background cleanup workers. If the daemon runs in-memory, all session history is immediately lost when the process exits.
Storage Modes & Persistence
Storage is fully configured by the operator and supports the following modes:
- sqlite-in-memory: Default mode. Process memory only, completely ephemeral.
- sqlite-in-disk: Persisted to local SQLite file for recovery across restarts.
- valkey: Distributed storage, persisted according to Valkey deployment settings.
Client-Side Cryptographic Key Custody
The browser WASM runtime generates an Ed25519 keypair locally when the session starts.
- The public key is transmitted to the server during the
/inithandshake. - The private key is retained in browser WASM memory and is never transmitted over the network.
- Heartbeat payloads are signed locally in the browser before submission.
This provides strong session continuity without creating long-term tracking identifiers.
{"status":"ok"} for accepted and rejected heartbeat requests, omitting next-state fields on rejection.