BlackMold web beta data flow
Last updated 25 August 2026
This page explains where data travels. The privacy notice explains the controller, purposes, legal bases, retention, and your GDPR rights.
1. Visiting the public pages
Your browser requests static HTML, CSS, fonts, and images from Cloudflare Pages. Cloudflare receives ordinary request and security metadata such as IP address, browser information, requested URL, timestamp, and request ID. The public pages do not load advertising or behavioural analytics.
2. Entering the private workspace
Cloudflare Access checks the invited email address using a one-time code and creates a necessary authentication session. Access records authentication metadata including email, IP address, inferred country, authentication method, application, allow or deny result, timestamp, and request ID. The BlackMold worker verifies the signed Access token and its configured audience before serving /app/* or /api/*; it does not trust an email header by itself.
3. Local encrypted recovery
Your browser serializes the case and encrypts its name and JSON with a non-extractable 256-bit AES-GCM device key. IndexedDB stores the key and encrypted record. The account recovery secret, when remembered, is also encrypted by that device key. Opaque IDs, timestamps, record version, source, and byte count remain outside the ciphertext. LocalStorage stores privacy preferences, first-run acknowledgement, and up to 250 local external-feature audit entries. A portable encrypted export uses a recovery secret.
4. Opening and syncing a personal account case
The worker verifies the signed Cloudflare Access identity and returns only personal cases owned by that normalized email address. D1 stores the owner email, a generic non-sensitive label, case type, opaque identifiers, revision pointers, hashes, encrypted sizes, timestamps, and audit events. The personal case name remains inside the encrypted revision. R2 stores immutable encrypted envelopes.
The creating browser encrypts every personal case with its own random case key and wraps that key using one account recovery secret. The recovery secret and case keys are never uploaded. A new browser downloads an encrypted revision after Access authentication, asks for the account recovery secret once, decrypts locally, and encrypts the remembered secret with its new non-extractable device key.
5. Opening and publishing a shared case
After Access authentication, BlackMold checks per-case membership in D1. The browser downloads an encrypted envelope from R2 and decrypts it locally with the recovery secret. When an owner or editor publishes, the browser encrypts the new revision before upload.
R2 receives the immutable encrypted envelope under a random object key. D1 stores the plaintext non-sensitive collaboration label, case and membership identifiers, member email addresses and roles, object pointers, hashes, byte counts, revision numbers, timestamps, and audit events. The server can therefore see who collaborates, when revisions are published, and their encrypted sizes, but is not designed to receive the decrypted case, recovery secret, or case key.
6. Membership removal and deletion
To remove a member, the owner creates a new case key and encrypted revision in the browser. The server conditionally commits that revision and removes membership as one database transaction. The replacement recovery secret is shown once for distribution outside BlackMold. The removed person cannot fetch later revisions but may keep earlier downloads.
The latest 24 active personal or shared revisions are retained. Archiving immediately blocks access and starts a 30-day restoration period. Scheduled or opportunistic cleanup then removes expired D1 records and R2 objects. Clearing browser data or choosing “Forget this device” removes the device key, remembered account recovery secret, and local recovery library. Personal cases remain encrypted in R2 and can be reopened after Access sign-in by entering the account recovery secret on the new browser.
7. Live shared-case presence
Each visible shared-case tab sends an active heartbeat about every 20 seconds and requests the case presence list about every 12 seconds. A hidden tab sends an away state. D1 temporarily stores the case ID, normalized member email, case-specific nickname, opaque tab-session ID, state, and last-seen timestamp. Multiple tabs or devices are combined into one member entry.
The presence response contains nicknames, roles, working or away state, and a marker for the current user; it never exposes another member's email. Active heartbeats older than 60 seconds are treated as offline and away entries expire after five minutes. Presence is removed when membership ends or the case is archived, and is excluded from diagnostics and audit history. Presence failures do not block case editing or encrypted revision sync.
8. Optional network features
External lookups, cloud AI, and network map tiles are off by default for new web users. When you choose to enable and use one, the workspace identifies the provider and data categories before the request. Depending on the feature, the provider can receive a search term, domain, IP address, URL, identifier, email address, location, map viewport, or the case-derived content needed for the request, together with ordinary network metadata. The provider handles it under its own privacy terms.
9. Diagnostics and support
The private release-diagnostics endpoint returns aggregate case, membership, revision, audit-event, and encrypted-byte counts; it does not return case labels, member emails, object contents, or recovery secrets. Local error screens and local privacy audit entries stay in the browser unless you deliberately copy or send them. Do not place case data in support, feedback, or privacy messages.
Recovery boundary
BlackMold cannot recover a lost recovery secret or decrypt server revisions. Encryption does not revoke a copy that another member already downloaded. Use fictional or properly authorized data during the beta and keep encrypted recovery exports in a safe location.