# Bruce Schneier *Source: · markdown twin of the entry page.* *An influence on **Dinis Cruz** — one of 25 entries in his register.* - **tier** traced — corpus evidence exists today - **kind** person - **status** full — the seven-block register format - **briefing** none Security as a systems and incentives problem before it is a technical one — and, in the corpus, the person who turns up in two arguments that have nothing to do with each other. ## Block 1 — The anchor Schneier on Security — the public writing, from *Applied Cryptography* onward — Bruce Schneier - anchor: A body of work rather than one book. The specific move being credited is the shift from cryptography to security economics. *Linked, never rehosted.* ## Block 2 — In his own words The thing worth naming is the **shift**, not the writing. Schneier started as a cryptographer and ended up arguing that the interesting question was economic: who pays when this breaks, and does that person get to decide anything? That reframing is now so standard in security that it is easy to forget it had to be made. In this corpus it shows up in two unrelated places, which is the pattern this register treats as evidence. One is the argument about language-model failure modes — approached as a question about what the system is incentivised to do rather than as a list of attacks. The other is [the Semantic Web entry's](../semantic-web/index.html) Solid brief, where Schneier's involvement at Inrupt is noted as part of the case that personal-data-control architectures are a serious position rather than a hobby. Short entry, and it should stay short. This is a *style* of threat modelling rather than a body of implemented patterns. ## Block 3 — The principle **Security failures are usually incentive failures wearing a technical costume — ask who bears the cost of the failure before asking how the failure happens.** ## Block 4 — The trace table **No trace table yet.** A style of thinking leaves fewer fingerprints than a pattern does, and the honest position is that the rows for this entry may never be strong. What could be traced: whether the estate's threat models actually name who bears the cost of each failure, or only what the failure is. That is a checkable question about existing documents and nobody has asked it. [R2](../../admin/comms.html#r2). ## Block 6 — The checklist - Who bears the cost when this fails — and do they have any say in how it is built? - Is the mitigation aligned with someone's incentives, or does it depend on them acting against them? - Is this a technical problem, or an economic one that has been handed to engineers? - What is the *system* doing here, as opposed to what the attacker is doing? ## Block 7 — The wider library - **Schneier on Security (the blog)** — thirty years of the argument being made in public, continuously - **Secrets and Lies (2000)** — the book where the shift from cryptography to systems happens in the open - **Liars and Outliers (2012)** — the furthest version of the incentives argument — security as a problem of societal trust - **Applied Cryptography (1996)** — the earlier work, and useful mostly as the thing the later work moved away from ## The corpus evidence | Path in the corpus | What it carries | |---|---| | `(corpus-wide, ~4 files)` | the language-model failure-modes argument, and Schneier's Inrupt involvement in the Solid brief | | `SGraph-AI__App__Send/team/humans/dinis_cruz/briefs/02/24/v0.6.17__architecture__solid-protocol-integration-complementary-architectures.md` | Schneier at Inrupt, cited in the vaults-versus-pods comparison | --- CC BY 4.0 — Dinis Cruz, with AI co-authorship (Claude, Anthropic). The anchor work belongs to its author and is linked, not licensed here.