Work · Case 04
WhisperBox
An encrypted chat application, built to think properly about what the server is allowed to know.
01 — Problem
What was going wrong
Most chat applications are secure in the sense that traffic is encrypted in transit and the operator can still read everything. That is a different property from the one users assume they have. Building the stronger version forces you to decide, explicitly, what the server is permitted to learn.
02 — Approach
The decision that resolved it
Start from the threat model rather than the feature list, and let it decide the data model. If the server should not be able to read message contents, then the design has to make that structurally true rather than a matter of policy — which changes where keys live, what the server stores, and which features are possible at all.
04 — What I shipped
What exists now
- An end-to-end encrypted chat application with the key handling and message flow built around what the server is deliberately not given.
- Feature decisions documented against the threat model, including the ones that were dropped because they would have required the server to read too much.
05 — Result
What changed
- Design driver
- Threat model first
- The data model follows from what the server is allowed to know, not the other way round.
- Trade-off made explicit
- Features vs. server knowledge
- Capabilities that would have required plaintext on the server were cut rather than weakened.
06 — Links