Privacy product architecture
Privacy architecture means arranging systems so that no ordinary employee, service, or database can casually assemble a customer’s identity, content, network activity, support history, and payment record.
It is not a claim that a company has no liability or that correlation becomes impossible. It reduces unnecessary linkage and the blast radius of a compromise.
Deliberately incomplete views
A later product suite should separate:
- billing and legal identity
- entitlement issuance
- support case management
- product identity and access
- encrypted content or data plane
- security telemetry and abuse handling
flowchart LR Customer[Customer] Billing[Billing and legal identity] Entitlement[Entitlement issuer] Product[Product identity and access] Content[Encrypted content or data plane] Support[Support case management] Telemetry[Security telemetry] Customer --> Billing Billing -->|service-specific opaque token| Entitlement Entitlement --> Product Customer --> Support Customer --> Content Product --> Content Product --> Telemetry
The missing cross-links are deliberate. Normal operation does not require billing, support, content, and telemetry to share one customer identifier.
The entitlement broker can issue a service-specific opaque token. The relying service should receive the token or a token-derived value, not the customer’s billing account identifier. Unlinked subscription architecture and IVPN Unlinked Access supply the basic pattern.
Standards such as Privacy Pass show how unlinkable authorization tokens can be designed, but they are not a magic anonymity system. The merchant, issuer, network, or service may still have other correlation signals.
Cross-service lookup should be a rare, logged break-glass workflow. It needs a defined reason, narrow scope, and, where practical, two-person approval.
What not to collect
Do not add advertising SDKs, session replay, behavioral analytics, cross-product tracking, or a global customer identifier to a privacy product.
Do not use a phone number for basic product access unless it is genuinely necessary. Do not make a recovery email the only escape hatch. Do not ask support staff to obtain a customer’s secrets.
Every field must answer: “What specific customer value or legal requirement justifies this?” If the answer is vague, do not collect it. Data minimization turns that rule into a reusable design practice, and High-consequence data identifies fields that demand the highest default bar.
Secure-device handover
For a GrapheneOS device offer, use supported hardware, the official installation and release process, and a customer-verifiable handover.
The customer owns the device, passcode, accounts, recovery materials, and security keys. The seller retains no master account, hidden administration channel, or remote-wipe ability.
The customer must be able to factory-reset or reinstall the device after handover. That is not a failure of the service. It is evidence that the customer does not need to trust the reseller forever.
Optional upstream duress controls follow the same ownership rule. The customer may choose whether to configure a GrapheneOS duress PIN, but the seller should retain no credential, remote trigger, or activation record. Duress credentials and coercive extraction explains why supporting the feature is consistent with a privacy product without making individualized evidence destruction a company service.
Encryption and recovery
Do not build custom cryptography. For a future messenger, use mature, audited protocol libraries with device-specific keys, key-change warnings, forward secrecy, and clear group-membership behavior. Signal’s X3DH and Double Ratchet and the MLS standard are useful reference points.
For storage, encrypt content, filenames, paths, and manifests before upload. Use authenticated encryption, per-object keys, key wrapping, rotation, and explicit recovery modes.
Customer-controlled recovery can mean permanent loss when recovery material is lost. Managed recovery creates a high-value recovery authority. Threshold recovery is a later, carefully reviewed option, not a default feature.
Never blur these choices in marketing.
Network privacy
A VPN is a later product, not the whole company. Use a mature protocol such as WireGuard, but recognize that the hardest problems are operational: credential issuance, DNS, logging, abuse handling, app distribution, and legal classification.
A two-party relay can reduce trust concentration only when the parties, staff access, logs, and commercial incentives are truly independent. Two machines under one company’s control do not create two independent views. Obscura trust 2-party relays and QUIC gives an instructive model and VPN service legal risk names the limits.
AI execution boundary
Saved chat encryption does not by itself protect a prompt while a remote model processes it. The product must distinguish:
- local inference and local retrieval
- customer-owned or on-premises self-hosting
- a customer cloud tenant, which still has a provider infrastructure boundary
- attested confidential cloud inference
- contractual no-retention hosting
- ordinary external model APIs
The selector should run locally, with a visible route, model, and egress-policy state, and a fail-closed policy for confidential mode. Private AI trust boundaries, Confidential AI computing, and Private AI routing provide the detailed design.
Assurance before sensitive software
Before operating high-risk software, the company needs:
- a data inventory, retention schedule, and subprocessor list
- least-privilege production access with hardware-backed MFA
- secure builds, signed releases, dependency monitoring, and patch policy
- a public vulnerability-disclosure policy
- external testing before handling sensitive customer data
- independent cryptographic review before proprietary E2EE or storage
- an incident runbook and legal-request policy
- an audit report that identifies scope, version, findings, fixes, and date
An audit is scoped evidence, not a proof of perfection. Privacy trust and governance explains why publishing limits is part of the product.