Tell me what you have, or pick a starter below. I will point you to the right CSINT page and the next safe step.
Pro Workspace
Pro security model
What we protect, what the server sees, what we do not protect against.
This page is not marketing copy. It states, in plain language, the limits a paying team needs to know. There is no "unbreakable" claim; it says what each layer covers and what it does not.
1. What we protect
Message bodies (end-to-end encrypted)
Packet messages in the team thread are encrypted in the browser with AES-256-GCM; a separate key per key version is derived with HKDF-SHA-256. The server stores ciphertext only. The team key is never sent to the server and never rests there. When a member is removed, the key version is bumped; new messages use a key the removed member never held.
Shared file bytes (encrypted upload)
Files marked for team sharing are encrypted in the browser; only encrypted bytes, an integrity digest (SHA-256) and size/type metadata reach the server. Filenames are never transmitted. Downloads are verified against the digest before display.
Session
Sign-in uses an email code; the session lives in an HttpOnly cookie, so page JavaScript cannot read it. An optional Authenticator/TOTP second step can be enabled. Rate limits, role checks and a body-free audit log sit on top of these layers.
2. What the server can see (record metadata)
End-to-end encryption covers content only. The following stays readable on the server and would be visible in a data request or a breach:
- Who sent a message (account identity and display name)
- When it was sent (timestamps)
- Which packet it belongs to and the message count per packet
- The key version (only the version number, never content)
- Workspace members, their roles and action types (audit log)
Review queue comments are NOT end-to-end encrypted.
They are part of the approve/reject workflow, are readable by the server, and pass safety and personal-data checks before storage. Do not put sensitive source details into review comments; use the encrypted team thread instead.
3. What we do not protect against
A compromised device or browser
Malware or a malicious browser extension on a device can read plaintext and the in-memory key. End-to-end encryption is not a substitute for device security.
A member who still holds an old team key
Member removal protects forward only. Old messages are not re-encrypted; a former member who kept an old key or copied ciphertext can still read the pre-removal history.
Weak key sharing inside the team
If the key, or a handoff bundle and its passphrase, travel over the same channel (for example the same email thread), anyone who can read that channel gets the key. Bundle and passphrase must always travel separately; that discipline is the team's responsibility.
4. OSINT ethics boundaries
- No doxxing: the desk may not be used to publish private contacts, home addresses or identity data.
- No stalking: locating individuals, hunting profiles or marking targets is out of scope.
- No unauthorized access: it is not a tool for account cracking, credential collection or spreading leaked data.
- Lawful open sources only: report boundary violations to the packet owner and the workspace owner.
One stated trade-off: the server cannot scan encrypted thread content. Enforcing these boundaries is therefore a team responsibility, not a technical filter.
5. Data retention and wipe
Pilot records live in D1. Messages do not auto-expire; they persist until their packet or workspace data is deleted. Two separate wipe tools exist, and they do different things:
Wipe this device (every member)
Removes local files, drafts, cached keys and the session from this device. It makes no API call. It does not recall copies already shared with the team; it only cleans this browser.
Workspace destroy (owner only)
Requires a two-step confirmation (open the danger zone, type the workspace name or the confirmation phrase). Deletes encrypted messages, shared files and workspace records on the server and reports deletion counts. The only durable trace is a content-free operation record: who, when, which workspace, how many rows.
6. Channel comparison
| Feature | Free local desk | Pro encrypted thread | Review comments |
|---|---|---|---|
| Where content lives | Only on this device (browser storage) | On the server, as ciphertext | On the server, as readable text |
| Who can read it | Only the person using this device | Team members holding the team key | Workspace members and the server |
| Encryption | Never leaves the device | End-to-end AES-256-GCM | Transport layer only (TLS) |
| Abuse scanning | No server involved | The server cannot scan content | Server-side checks (safety + personal data) |
| Best for | Solo draft work | Sensitive OSINT notes | Editorial approve/reject notes |
| Deletion | Device wipe | Packet delete or workspace destroy | Removed with workspace destroy |
Related pages
Technical details (schema names, key derivation, audit fields) are documented in the open-source repository. If this page changes, the model has changed; there are no silent updates.