🌱 Everbloom
Privacy & Security
Last updated September 26, 2026. This page describes how Everbloom actually works today — including the limits. We'd rather tell you precisely what is protected than make broad promises.
Current protections at a glance
- In transit Hybrid post-quantum TLS (X25519 + ML-KEM-768) on modern browsers; HTTPS enforced.
- Passwords Never stored — salted scrypt hashes only.
- Access Random 256-bit invite keys (stored hashed), short-lived signed room tokens, waiting rooms, host admission.
- Server Service runs with all Linux capabilities removed + NoNewPrivileges; scoped secret file; LiveKit management interface not reachable from the internet; firewall + brute-force blocking.
- Integrity SHA-256 hash-chained, append-only audit log; SHA-256 evidence fingerprints; test-restored backups.
- At rest Stored record/photo/document files are not app-layer encrypted on disk — they are hashed in place as tamper-evident evidence, so encrypting the bytes would break that proof. They're protected by the SHA-256 integrity chain, strict access control, and encrypted backups. Disk/DB-field encryption is on the roadmap.
- E2EE (opt-in) Meetings can be made end-to-end encrypted via a secure link (the host's “🔐 E2EE link”). The encryption key lives only in that link's fragment and never reaches the server, so the server relays media it cannot read. E2EE meetings are not recorded. This was recently added — confirm with a test call before relying on it.
- Not yet At-rest encryption of other stored data (photos, journal images, meeting recordings, database fields) — planned, not implemented. Don't rely on that today.
Who runs Everbloom
Everbloom is a private family app run by one household on a server we control. It is not a commercial service, we do not sell or share data for advertising, and new accounts are by invitation only.
Encryption in transit, including post-quantum protection
Every connection to everbloom.driftpoint.us uses TLS 1.2 or newer, and HTTPS is enforced. On current browsers (recent Chrome, Edge, Firefox and Safari), the key exchange is the hybrid post-quantum scheme X25519MLKEM768: it combines classic elliptic-curve X25519 with ML-KEM-768, the NIST-standardized (FIPS 203) post-quantum algorithm. If either one holds, an attacker can't recover the session keys. That protects today's traffic against "record now, decrypt later" attacks by future quantum computers. Older browsers fall back to standard TLS 1.3 key exchange.
| Connection | Protection | Quantum-resistant? |
|---|---|---|
| App pages, records, uploads, account & login | TLS 1.3, hybrid X25519 + ML-KEM-768 key exchange | Yes (modern browsers) |
| Meeting sign-in and signaling (joining, chat, controls) | Same TLS connection as above (secure WebSocket) | Yes (modern browsers) |
| Live meeting audio & video (normal meeting) | WebRTC DTLS-SRTP (AES) — encrypted to our meeting server, which can read/route/record it | Not end-to-end |
| Live meeting audio & video (E2EE “secure link” meeting) | WebRTC DTLS-SRTP plus end-to-end frame encryption; the key is in the link fragment and never reaches the server, so the server cannot read it (and cannot record) | End-to-end |
| Administrator access to the server | SSH with hybrid sntrup761 + X25519 key exchange, with brute-force blocking | Yes |
Live meeting media is encrypted between your browser and our meeting server, but it is not end-to-end encrypted. The meeting server (which we run ourselves) handles the media so it can route it between participants and, only when a meeting is being recorded, save it.
How we handle keys and credentials
- Passwords are never stored. We keep only a salted scrypt hash, a deliberately slow function that resists brute-force guessing.
- Two-factor authentication (optional). You can turn on app-based 2FA (TOTP) at
/mfa.html; once on, sign-in also requires a 6-digit code from your authenticator, so a stolen password alone is not enough. Turning it on requires confirming a code first, so it can't lock you out. - Sign-in sessions use a random 256-bit token in a cookie marked
Secure,HttpOnlyandSameSite, so scripts can't read it and it's only sent over HTTPS. Each sign-in issues a fresh token (no session fixation). Signing out deletes that session on the server, not just the cookie, and “sign out everywhere” revokes every session on your account. - Personal meeting invite links contain a 256-bit random key. We store only its SHA-256 hash, and re-sending an invite replaces the key.
- Meeting access tokens are short-lived and signed by our own server for a single room. Participants never receive the server's signing secret.
- Server secrets live in one restricted file that holds only what Everbloom needs. The Everbloom service runs with every administrative privilege removed, and the meeting server's management interface is not reachable from the internet.
Stored data is not yet encrypted with a post-quantum scheme at the application level; see "Data at rest" below.
Data at rest and integrity
- Records, photos, documents and meeting recordings are stored on our own server. The database runs on that same machine and isn't reachable over the network.
- Tamper evidence: important actions (record changes, meeting joins, recordings, consent) go into an append-only audit log where each entry is chained to the previous one with SHA-256. Changing or deleting a past entry breaks the chain, and the break is detected. Evidence files are fingerprinted with SHA-256 when uploaded.
- Backups are encrypted — they are age-encrypted to a separate recipient key before they leave the server, and verified with a full test restore before they count as good. (An offline/immutable second copy for disaster recovery is still on the roadmap.)
- Encryption at rest: we do not add an application-layer encryption wrapper to stored record, photo and document files. Those files are registered as tamper-evident evidence and hashed in place, so encrypting the bytes would change them and break that integrity proof — which for a custody-records app matters more than file-level encryption. Their at-rest protection is the SHA-256 integrity chain (any change is detected), strict access control, and encrypted backups. Adding disk-level or database-field encryption that preserves the evidence hash is on the roadmap.
Meetings
- Recording is optional and consent-based. Before you join you can choose whether your camera and microphone may be recorded. If you say no, you still join, and your audio and video are excluded from any recording.
- Meetings can use a waiting room; the host decides who is admitted.
- Security logging: to protect participants, every visit to a meeting link and every join attempt is logged. The log holds the visitor's IP address, the network it belongs to (from public internet registries), the browser and device type, time zone, screen size and languages, and the name entered. The meeting host receives these records. They are kept in the tamper-evident audit log and are not shared with other participants.
Outside services that may process data
Some features rely on outside providers. They get only the data needed for that feature — and external AI can be switched off entirely by the operator (a single kill-switch that disables all AI transcription/analysis; when off, meetings simply aren't transcribed rather than sent anywhere):
| Provider | What for | What they receive |
|---|---|---|
| Google (Gemini API) | Transcribing and summarizing recorded meetings | Recorded audio of consenting participants |
| Anthropic (Claude API) | Optional AI assistance on records the account owner chooses to analyze | The text of those records |
| Resend | Sending invitation and alert emails | Recipient address and message content |
| OpenStreetMap / DuckDuckGo | "Nearby" place lookups | Approximate location or search terms (no account details) |
| ARIN (internet registry) | Identifying the network behind a meeting-link visit | The visitor's IP address |
| DigitalOcean | Hosting the server | Stores the server's disks; does not access app data in normal operation |
Retention and your choices
- Records and recordings are kept until the account owner deletes them, because they may serve as evidence. The audit log is kept permanently by design, so the record of what happened stays intact.
- You can ask the account owner for a copy of your data, or ask to have data about you corrected or removed where the law allows.
Planned — not yet implemented
These are designed but not built yet. Do not rely on them today. We list them so the roadmap is transparent.
- End-to-end encryption of live media — recently added (opt-in). Implemented with WebRTC insertable-stream frame encryption: the host's “🔐 E2EE link” carries a random key in the URL fragment (never sent to any server), so participants who open that link encrypt/decrypt media the server only relays. E2EE meetings are not server-recorded. Still to do: a real two-participant confirmation test, automatic key rotation when someone is removed, and (for normal meetings) it remains off so recording keeps working.
- Encryption at rest for stored files — not implemented, by design. Records, photos and documents are hashed in place as tamper-evident evidence, so a transparent file-encryption layer would change the bytes and break that integrity proof. The path forward is disk-level or database-field encryption that preserves the plaintext hash (or an evidence model that hashes plaintext while storing ciphertext) — on the roadmap.
- Multi-factor authentication / passkeys for account sign-in.
- Dedicated non-root service account. Today the service runs with all Linux capabilities removed and NoNewPrivileges, but under the root user id; a separate low-privilege account is planned.
Architecture (text diagram)
Browser ──hybrid PQ TLS──▶ Caddy edge ──▶ Everbloom app (127.0.0.1:3002)
│ ├─ Postgres (loopback only)
│ ├─ append-only audit log (SHA-256 chained)
│ └─ scoped secrets file (caps dropped)
└─WebRTC DTLS-SRTP──▶ LiveKit SFU (127.0.0.1:7880 signaling; media 7881/tcp,7882/udp)
(mgmt API NOT internet-reachable; media is encrypted in transit, NOT end-to-end)
Outside providers (only when a feature needs them): Claude/Gemini (AI on chosen content),
Resend (email), OpenStreetMap/DuckDuckGo (nearby lookups), ARIN (network of a visitor IP).Security incident response
- Login attempts and external access are watched; brute-force and suspicious logins are blocked and logged with evidence.
- If a breach affects your data, the account owner will notify you directly. The tamper-evident audit log is used to establish what happened and when.
- Report a concern to the person who invited you; the operator can revoke sessions and invite keys immediately.
Honest limits
- Post-quantum protection covers connections (in transit). It does not cover stored files or live meeting media on its own.
- Normal meetings are encrypted in transit but not end-to-end — our server can read and record them. End-to-end encryption is available for a meeting via the host's “🔐 E2EE link” (opt-in); E2EE meetings are not recorded. It was recently added — confirm it with a test call before you rely on it.
- Stored files (records, photos, documents) are not app-layer encrypted at rest — they are hashed in place as tamper-evident evidence, and protected instead by that integrity chain, strict access control, and encrypted backups.
- No system is perfectly secure. We patch the server, keep it behind a firewall with intrusion blocking, encrypt backups, and review its security, but we can't promise a breach will never happen. If one affects your data, we will tell you.