Threat Modeling

mental-model

Security is not a product label but a map of access: at every stage, ask which intermediaries, administrators, companies, governments, or attackers can read the data now—or might gain that power later.

A message can become dramatically more private while travelling through the same internet. With HTTP, offices along the network path may see it; with HTTPS, those intermediaries lose visibility but the platform server may still read it; with end-to-end encryption, even that server’s administrators are shut out. “Encrypted” therefore describes a boundary, not a universal condition.

Follow the data, then name the readers

Threat modeling replaces the vague question “Is this secure?” with two concrete ones: where does the data exist, and who has access at each point? Every transfer and storage layer creates a trust boundary. HTTP trusts intermediaries on the route; HTTPS protects that route while shifting trust toward the platform; end-to-end encryption narrows the readable endpoints further. This is why layered-defense matters: different protections exclude different observers rather than supplying one magical shield.

The model also exposes platform-risk. If a company holds readable data or controls the keys, its administrators—and anyone who later acquires their authority—remain inside the threat boundary. The relevant adversary is therefore not only today’s hacker. It is every present or future actor who can inherit, compel, steal, or abuse an existing permission.

Where it shows up

Three protocols, three trust boundaries

Compare the same communication under HTTP, HTTPS, and end-to-end encryption. The content has not changed; the set of possible readers has. That progression makes the threat model visible: random network intermediaries fall away first, then the platform itself. Greater exclusion may introduce a security-convenience-trade-off, because removing privileged access can also make recovery, moderation, or assistance harder.

Privacy is not the only system goal

A threat model identifies who must be trusted; it does not decide how much trust or friction is acceptable. Nor does reducing one access path prove the whole system safe. The right boundary depends on the user, the data, and the consequences—an instance of differential-vulnerability, not a universal ranking of products.

Draw the reader map

Tomorrow, choose one sensitive message or file and trace it from your device to its destination. At each hop, write down who can read the plaintext, who controls the keys, and who can reset access. Then change the single permission that creates the largest unacceptable exposure—perhaps switching the channel, removing a cloud copy, or keeping an independent recovery path outside the platform.

Episodes that teach this

Internet is Not in Clouds, It's in Oceans - Learn it Internet Works 1,439 views
The transcript contrasts HTTP exposure to random ISP offices, HTTPS exposure to platform servers, and end-to-end encryption that even server admins cannot read.