Privacy as protocol
The difference between a promise the operator can break and a property the operator cannot violate.
There are two ways to offer privacy. The conventional model treats it as a policy — a promise layered on top of an architecture that is fully capable of surveillance. ArxCode treats it as a protocol — a property of the architecture itself.
Privacy as policy
Under the policy model, the provider keeps the capability to watch and simply promises not to use it. That promise fails in three independent ways:
| Failure | What happens |
|---|---|
| Subpoena | A third party compels disclosure of data the provider was able to retain. |
| Breach | An attacker extracts logs the provider chose to keep. |
| Drift | A future change in terms, ownership, or incentives quietly repurposes data you assumed was private. |
In every case, the data existed in a place someone could reach. The promise was never the protection.
Privacy as protocol
The protocol model removes the capability instead of restraining it:
- If the architecture exposes no readable session, there is nothing to subpoena.
- If no logs are written, there is nothing to breach.
- If submissions are never retained, no future policy can repurpose them.
| Privacy as policy | Privacy as protocol | |
|---|---|---|
| Capability | Exists; provider promises restraint | Removed; surveillance is impossible |
| Fails to | Subpoena · breach · drift | Nothing to take |
The distinction is the difference between a promise and a property. ArxCode is built on the latter.
Next
- See exactly what is and isn't defended in the Threat model.