Handbook
Prompt 02A - Cryptography, privacy claims, and trust-boundary gate
Run after Prompt 02 and before publishing marketing claims or expanding the current encryption implementation.
Updated
Mode
Start in Plan mode. Small corrective code changes are allowed only after the architecture decision and test plan are approved.
Required context
- Current subject, admin, import, results, PDP, and export code
- All backend handlers for keys, envelopes, responses, results, metrics, verification, PDP, resealing, and wrap-up
- Logging, tracing, analytics, proxy, worker, and support-access configuration
- Existing privacy/security copy
- Data-classification and anonymity wiki pages
Prompt
Establish the actual Capablio trust model and make code, UI, documentation, and marketing consistent with it.
1. Trace sensitive data end to end
Create a data-flow diagram and table for:
- private and public keys
- sealed envelopes
- individual scores
consented_scores- free-text comments
- importance rankings
- imported PDF plaintext
- result metrics
- PDP answers and goals
- exports and rendered HTML
For every transition record process, storage, transport, encryption state, retention, logging risk, and authorized readers.
2. Audit all private-key handling
Find every request body, URL, worker message, log, trace, analytics event, cache, and support path that can contain a private key or equivalent decryption secret.
Treat a private key in a query string as a release blocker.
Do not accept the label "client-side encryption" as proof of a zero-knowledge service if the private key reaches a server.
3. Reconcile plaintext score handling
Document why multi-rater consented_scores exist, whether they are linkable to a respondent, how they are aggregated, when raw values are deleted, and how minimum-group thresholds are enforced.
Decide whether the product is:
- subject-private with client-side aggregation/decryption
- service-readable under a clearly disclosed model
- tenant-recoverable under approved controls
- a supported combination of explicitly named modes
Do not mix these modes in one vague promise.
4. Select and document the supported architecture
Produce ADRs for:
- key generation and custody
- device storage
- backup/recovery
- additional devices
- leavers
- key rotation and resealing
- server-side aggregation requirements
- import processing
- report generation
- PDP processing
- customer-managed keys if planned
If subject-private mode is selected, private keys must not be transmitted to Capablio services. Move decrypt/derive operations to the approved client or trusted boundary.
5. Correct unsafe interfaces
At minimum:
- remove private secrets from query strings
- remove or redesign APIs that require a subject private key
- add log/trace redaction and tests
- review sessionStorage and XSS implications
- define CSP and trusted script policy
- sandbox or replace server-generated
srcdocreport rendering - sanitize all untrusted people, comment, and imported content
- review key-file provisioning language and custody
6. Correct product claims
Create an approved claim matrix:
| Claim | Evidence | Scope | Exceptions | Approved wording |
|---|---|---|---|---|
Update UI, marketing, documentation, emails, and sales/demo content. Remove unsupported phrases immediately behind a feature/content flag if necessary.
7. Tests and evidence
Add:
- automated search/test preventing private keys in URLs, logs, analytics, and error payloads
- API contract tests for every encryption boundary
- cross-tenant and support-access negative tests
- XSS tests with key material present
- aggregation/anonymity tests
- recovery and device migration tests
- browser and CSP compatibility tests
- an independent security-review checklist
Required outputs
wiki/internal/security/cryptographic-data-flow.md
wiki/internal/security/key-custody-and-recovery.md
wiki/internal/security/plaintext-score-processing.md
wiki/internal/security/threat-model.md
wiki/internal/adr/ADR-crypto-trust-mode.md
wiki/shared/privacy-claim-matrix.md
wiki/internal/product/crypto-migration-plan.md
Exit gate
Do not proceed with a zero-knowledge, keys-never-leave-browser, or server-cannot-read claim until the selected architecture, implementation, tests, and documentation all support it.