https://vulnerability.circl.lu/sightings/feed 2026-07-27T23:17:21.644980+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent sightings. https://vulnerability.circl.lu/sighting/f255b941-bd61-4c3d-a727-407937d80e56/export 2026-07-27T23:17:21.666405+00:00 Automation user https://cve.circl.lu/user/automation {"uuid": "f255b941-bd61-4c3d-a727-407937d80e56", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2026-33327", "type": "seen", "source": "https://gist.github.com/saxonthune/1f01fdc8d7c86033e2721f38b4a52427", "content": " \u2590\u259b\u2588\u2588\u2588\u259c\u258c Claude Code v2.1.220\n\u259d\u259c\u2588\u2588\u2588\u2588\u2588\u259b\u2598 Opus 5 \u00b7 Claude Max\n \u2598\u2598 \u259d\u259d ~/code/github/saxonthune/braincrawl-l3\n\n\n\u276f /braincrawl \nhttps://github.com/saxonthune/spacetime-content/security/dependabot/58 check \nout this issue. Here's the thing. I think that cybersecurity is a scam. not \nthat breaches don't happen, but that security industry creates its own problems \nto solve and that we all pay for it. Let's say that I want to actually solve \nsecurity for real. In any other branch of software design, constant, repeated \nbugs usually implies that the design is flawed, and a deeper refactoring is \nrequired. 1) why is it that these libraries are constantly having flaws? 2) \nwould it be viable to reduce the number of moving parts, maybe not packages \nused in a js project, but reduce the way that components interact such that the \nunderlying situation enabling complex chained vulnerabilities becomes \nimpossible in the first place? 3) is there any strain of research or thought \nthat is also cynical regarding cybersecurity? what do they have to say? \n\n\u25cf I'll start by checking the server and surveying what's already in the\n collection.\n\n Ran 3 shell commands (ctrl+o to expand)\n \u23bf \u00a0Interrupted \u00b7 What should Claude do instead?\n\n\u276f this is probably a new L3 doc \n\n\u25cf Agreed \u2014 new doc. Let me look at the alert and orient against adjacent docs.\n\n Ran 2 shell commands (ctrl+o to expand)\n\n\u25cf The alert itself is a perfect specimen of your thesis: sharp is a JS package,\n but the four CVEs are in libvips, a C library, specifically its GIF/TIFF/VIPS\n image decoders. The official workaround is literally to switch off decoders\n you never asked for. Let me gather against all three questions.\n\n Read 1 file, ran 33 shell commands (ctrl+o to expand)\n\n\u25cf Write(security-critique-and-design.l3.md)\n \u23bf \u00a0Error writing file\n\n Read 1 file (ctrl+o to expand)\n\n\u25cf Write(security-critique-and-design.l3.md)\n \u23bf \u00a0Added 105 lines, removed 10 lines\n 3 updated: 2026-07-27\n 4 ---\n 5 \n 6 -# L3 \u2014 Cybersecurity as a design failure: why libraries keep b\n -reaking, whether interaction can be constrained, and the cynic\n -al literature \n 6 +## Cybersecurity as a design failure \n 7 +- tags: #intro \n 8 +- remarks: Started from a Dependabot alert on saxonthune/space\n +time-content \u2014 `sharp` (npm) flagged high for CVE-2026-33327/3\n +3328/35590/35591. The flaws are not in `sharp` and not in Java\n +Script: they are in libvips, a C library, in its GIF, TIFF and\n + VIPS image decoders. The vendor's own workaround is to call `\n +sharp.block` on those three loaders \u2014 switch off decoders the \n +application never asked for. The specimen contains all three q\n +uestions: a memory-unsafe parser of untrusted input (Q1), reac\n +hable only because the dependency graph granted authority nobo\n +dy requested (Q2), inside an industry whose loss claims and ad\n +vice may not survive scrutiny (Q3). \n 9 +- relates-to [[contract-ness-spectrum]] \n 10 +- relates-to [[intention-meta-interface]] \n 11 \n 8 - \n 12 +## Q1 \u2014 Why do these libraries constantly have flaws? \n 13 +- tags: #question \n 14 +- remarks: Working answer from the literature \u2014 three compound\n +ing causes, none of which is \"developers are careless.\" (a) Th\n +e flaws concentrate in parsers of untrusted input written in m\n +emory-unsafe languages; libvips, libjpeg, libpng and libvorbis\n + are all this shape. (b) Input formats are accidentally over-e\n +xpressive languages, so a \"parser\" is really an interpreter fo\n +r an unspecified grammar, and every implementation of it diver\n +ges. (c) The ecosystem multiplies exposure: the npm graph lets\n + one unmaintained package reach thousands of applications. Ope\n +n question \u2014 are these one cause or three? The formal-language\n +-theory camp would say (a) is downstream of (b): memory corrup\n +tion is what an over-expressive input language buys you on an \n +unsafe substrate. \n 15 \n 10 -## About this document \n 11 -- tags: #meta \n 12 -- remarks: One line on what this collection is about and what \n -question set it collects around. \n 16 +## Q2 \u2014 Can component interaction be constrained so chained vu\n +lnerabilities become impossible? \n 17 +- tags: #question \n 18 +- remarks: Not \"fewer packages\" but \"less authority per packag\n +e.\" The literature gives two distinct answers and they are not\n + the same move. Reduce the input language \u2014 make the format re\n +cognizable by a weak automaton and reject before processing, s\n +o no exploitable machine exists to program. Reduce the authori\n +ty \u2014 assume the decoder is compromised and give it nothing wor\n +th having, as RLBox, Capsicum, CHERI and seL4 each do. The sha\n +rp workaround is a crude instance of the second: block the dec\n +oder, cut the reachable surface. Open question \u2014 is there a de\n +sign grammar that makes the authority a component holds an exp\n +licit, checkable part of its interface, rather than an ambient\n + property of whatever process it happens to run in? That is th\n +e same shape as the contract-ness question: authority today si\n +ts at the implicit end of the spectrum. \n 19 +- bridges [[contract-ness-spectrum]] \n 20 \n 14 -## Example question \n 15 -- tags: #Q1 \n 16 -- remarks: Replace with the actual question; add findings, lin\n -ks, and catalog references as you go. \n 17 - \n 18 - \n 21 +## Q3 \u2014 Is there a cynical strain of security research? \n 22 +- tags: #question \n 23 +- remarks: Yes, and it is respectable rather than fringe. It h\n +as three branches. Economic (Anderson, Moore) \u2014 insecurity is \n +a misaligned-incentive problem, because whoever can fix it is \n +not whoever bears the loss. Epistemic (Herley) \u2014 security clai\n +ms are structurally unfalsifiable, so the field can only ratch\n +et upward, and its own loss estimates rest on surveys that can\n +not support them. Empirical and deflationary (Rescorla, Odlyzk\n +o) \u2014 finding and patching holes may not measurably improve any\n +thing, and the predicted catastrophes have not arrived. Herley\n +'s is the sharpest form of the \"scam\" intuition, and it is not\n + the claim that breaches are fake; it is the claim that the fi\n +eld has no method for ranking its own countermeasures. \n 24 + \n 25 +## Q4 \u2014 Is \"repeated bugs imply a flawed design\" a legitimate \n +transfer to security? \n 26 +- tags: #question \n 27 +- remarks: The premise carried over from ordinary software des\n +ign. Two literatures agree with it from opposite ends. The mem\n +ory-safety systematization shows thirty years of countermeasur\n +es all eventually defeated, which is the signature of treating\n + a design defect as a stream of bugs. Systems-safety thinking \n +in the Leveson line argues that accidents come from interactio\n +ns between individually correct components, so reliability eng\n +ineering applied to single parts cannot reach them. Unresolved\n + \u2014 whether the security case is a design flaw in the language \n +substrate (C), in the format (over-expressive inputs), or in t\n +he composition model (ambient authority). Q1 and Q2 hold the t\n +wo leading candidates; this node holds the framing. \n 28 + \n 29 +## Szekeres et al., \"SoK: Eternal War in Memory\" \n 30 +- tags: #landmark \n 31 +- catalog [[openalex:W2117798902]] \n 32 +- remarks: Systematizes thirty years of memory-corruption defe\n +nses against a general attack model and shows that every deplo\n +yed protection has been defeated. Names the reason stricter po\n +licies do not ship \u2014 performance. Only defenses with acceptabl\n +e overhead get adopted, so the deployed set is selected for ch\n +eapness rather than sufficiency. The strongest evidence for Q4\n +: this is what a field looks like when it patches a design fla\n +w one bug at a time. \n 33 + \n 34 +## Sassaman, Patterson, Bratus, Locasto, \"Security Application\n +s of Formal Language Theory\" \n 35 +- tags: #landmark \n 36 +- catalog [[openalex:W2143077513]] \n 37 +- remarks: The founding paper of language-theoretic security. \n +Argues that a large share of insecurity comes from treating in\n +put handling informally \u2014 every protocol or file format is a l\n +anguage, every parser an ad-hoc recognizer, and divergence bet\n +ween two implementations' recognizers is directly exploitable,\n + which they formalize as the parse-tree differential attack. P\n +rescribes making the input language weak enough to recognize w\n +ith a decidable automaton and validating fully before processi\n +ng. Connects protocol complexity to insecurity explicitly. The\n + cleanest statement that this is a design problem rather than \n +a coding one, and the direct answer to Q1(b) and to the first \n +half of Q2. \n 38 +- reading: {role: start-here, why: 'The best statement that in\n +put-handling insecurity follows from over-expressive formats b\n +y design, not from a failure of discipline.'} \n 39 + \n 40 +## Bratus et al., \"Mismorphism: The Heart of the Weird Machine\n +\" \n 41 +- catalog [[openalex:W3080209414]] \n 42 +- remarks: Later work in the same programme, naming the genera\n +l mechanism: a mismatch between two parties' models of the sam\n +e artifact is what makes an exploitable machine available. Gen\n +eralizes the parse-tree differential beyond parsers. \n 43 + \n 44 +## Zimmermann et al., \"Small World with High Risks: A Study of\n + Security Threats in the npm Ecosystem\" \n 45 +- tags: #landmark \n 46 +- catalog [[openalex:W2915997584]] \n 47 +- remarks: Empirical study of the npm dependency and maintaine\n +r graphs. Finds single packages that reach large parts of the \n +ecosystem, that a very small number of maintainer accounts cou\n +ld inject code into the majority of all packages, and that mis\n +sing maintenance leaves packages depending on known-vulnerable\n + code years after disclosure. Names npm's single points of fai\n +lure and evaluates mitigations such as trusted maintainers and\n + total first-party security. The structural reason the sharp a\n +lert exists at all \u2014 the dependency graph is a transitive-trus\n +t graph nobody audits. \n 48 + \n 49 +## Narayan et al., \"Retrofitting Fine Grain Isolation in the F\n +irefox Renderer\" (RLBox) \n 50 +- tags: #landmark \n 51 +- catalog [[openalex:W3008481500]] \n 52 +- remarks: The closest existing answer to Q2, aimed at exactly\n + this class of bug \u2014 Firefox's third-party audio, video and im\n +age libraries. Rather than fixing the decoders, RLBox assumes \n +they are compromised and isolates each in a lightweight sandbo\n +x, using WebAssembly or process isolation, and enforces the tr\n +ust boundary in the C++ type system through static information\n +-flow checks plus lightweight dynamic ones. Sandboxes libjpeg,\n + libpng, libtheora, libvpx, libvorbis and zlib with modest, tr\n +ansient overhead, and shipped in production Firefox for the li\n +bGraphite font shaper. Note the shape of the argument: the unt\n +rusted-code boundary is made explicit and type-checked, which \n +is the authority version of moving information toward the expl\n +icit end of the contract-ness spectrum. \n 53 +- bridges [[contract-ness-spectrum]] \n 54 +- reading: {role: core, why: 'A shipped instance of making com\n +ponent interaction incapable of chaining, against the exact li\n +bvips class of problem.'} \n 55 + \n 56 +## Watson et al., \"Capsicum: Practical Capabilities for UNIX\" \n 57 +- catalog [[openalex:W1608091202]] \n 58 +- remarks: Adds a capability mode to UNIX so a process can vol\n +untarily drop ambient authority and thereafter act only throug\n +h descriptors it already holds. The operating-system statement\n + of least authority \u2014 a compromised decoder cannot reach the f\n +ilesystem or the network because it holds no handle to them, n\n +ot because a policy forbids it. \n 59 + \n 60 +## Watson et al., \"CHERI: A Hybrid Capability-System Architect\n +ure for Scalable Software Compartmentalization\" \n 61 +- tags: #landmark \n 62 +- catalog [[openalex:W1904738922]] \n 63 +- remarks: Pushes capabilities into the instruction set \u2014 fine\n +-grained capability-based memory protection for C, plus a hard\n +ware and software object-capability model for compartmentaliza\n +tion. Claims orders-of-magnitude better scalability than compa\n +rtmentalization built on the memory-management unit, which mat\n +ters because the unit's coarse granularity is precisely why no\n +body sandboxes at the per-library level today. The most seriou\n +s \"change the substrate rather than patch the bugs\" answer to \n +Q4. \n 64 + \n 65 +## Klein et al., seL4 verified microkernel \n 66 +- catalog [[openalex:W2163347957]] \n 67 +- remarks: A machine-checked functional-correctness proof of a\n +n operating-system microkernel, later extended to information-\n +flow enforcement (see openalex:W1988079752). The existence pro\n +of that a component of real size can be removed from the bug s\n +tream entirely. It also bounds the argument: the effort was en\n +ormous and the artifact small, so this is not a general method\n + \u2014 it is evidence that the general method is missing. \n 68 + \n 69 +## Provos et al., \"Preventing Privilege Escalation\" \n 70 +- catalog [[openalex:W6385438]] \n 71 +- remarks: The privilege-separation pattern from OpenSSH \u2014 spl\n +it a program into a small privileged monitor and a large unpri\n +vileged worker that handles the untrusted input. The oldest wi\n +dely deployed form of the Q2 move, and the ancestor of RLBox's\n + per-library sandboxes. \n 72 + \n 73 +## Manadhata & Wing, \"An Attack Surface Metric\" \n 74 +- catalog [[openalex:W2129586531]] \n 75 +- remarks: Tries to make \"how much surface does this system ex\n +pose\" a measurable quantity rather than a slogan, so that two \n +designs can be compared. Relevant to Q2 because \"reduce the mo\n +ving parts\" needs a metric before it becomes an engineering cl\n +aim, and a fair test case for Herley's unfalsifiability critiq\n +ue \u2014 check whether the metric predicts anything. \n 76 + \n 77 +## Herley, \"The Unfalsifiability of Security Claims\" \n 78 +- tags: #landmark \n 79 +- catalog [[openalex:W2472123420]] \n 80 +- remarks: The sharpest cynical argument, and it is structural\n + rather than moral. Security is observationally asymmetric \u2014 a\n + system can be shown insecure but never shown secure. It follo\n +ws that claims a countermeasure is necessary are unfalsifiable\n +, while claims that countermeasures are sufficient are always \n +correctable. The consequence is a one-way ratchet: a newly spe\n +culated attack can argue a control in, and no observation can \n +ever argue one out, so errors accumulate and there is no syste\n +matic way to rank or prioritize defenses. This is the defensib\n +le core of \"the industry creates its own problems\" \u2014 not consp\n +iracy, but a field whose method cannot retire anything. \n 81 +- reading: {role: start-here, why: 'The cynical thesis in its \n +strongest and most rigorous form; short, and it reframes the w\n +hole question.'} \n 82 + \n 83 +## Herley, \"So Long, and No Thanks for the Externalities: The \n +Rational Rejection of Security Advice by Users\" \n 84 +- tags: #landmark \n 85 +- catalog [[openalex:W2045591401]] \n 86 +- remarks: Users who ignore security advice are behaving ratio\n +nally, not lazily. The advice shields them from the direct cos\n +ts of attack while imposing far larger indirect costs in effor\n +t. Worked numbers \u2014 if users spent one minute a day reading UR\n +Ls to avoid phishing, that time would cost two orders of magni\n +tude more than all phishing losses, and effectively every cert\n +ificate-error warning is a false positive. The general form: a\n +dvice is a daily burden on everyone, while the ceiling on its \n +benefit is the harm suffered by the small fraction who become \n +victims each year, so beneficial advice is very hard to design\n + at all. \n 87 + \n 88 +## Flor\u00eancio & Herley, \"Sex, Lies and Cyber-crime Surveys\" \n 89 +- catalog [[openalex:W1515345759]] \n 90 +- remarks: Argues that published cyber-crime loss estimates ar\n +e dominated by a handful of extreme self-reported answers in s\n +mall surveys, so the headline aggregates are unsound. Attacks \n +the number the industry sizes itself against. OpenAlex holds n\n +o abstract for this one \u2014 fetch the source before leaning on i\n +t. \n 91 + \n 92 +## Rescorla, \"Is Finding Security Holes a Good Idea?\" \n 93 +- tags: #landmark \n 94 +- catalog [[openalex:W2114712239]] \n 95 +- remarks: Measures whether vulnerability finding actually imp\n +roves software, using disclosure and rediscovery data, with as\n +sumptions deliberately biased toward a positive result. Finds \n +no clear quality improvement even in that best case. The reaso\n +ning is that vulnerability density is high enough, and indepen\n +dent rediscovery rare enough, that removing any one hole barel\n +y changes an attacker's odds. If it holds, the whole find-and-\n +patch economy \u2014 Dependabot alerts included \u2014 is close to a tre\n +admill. Cuts both ways on Q4: if patching does not help, \"refa\n +ctor the design instead\" gains force, but measuring whether th\n +e refactor helped would be just as hard. \n 96 + \n 97 +## Odlyzko, \"Cybersecurity Is Not Very Important\" \n 98 +- catalog [[openalex:W3084639219]] \n 99 +- remarks: Deliberately provocative. Concedes a rising tide of\n + breaches but observes an even faster-rising tide of alarm, an\n +d that none of the predicted digital catastrophes has occurred\n + while society keeps functioning. Concludes that the \"chewing \n +gum and baling wire\" approach \u2014 adapting ordinary physical-wor\n +ld risk containment to cyberspace \u2014 has been adequate and will\n + remain so. The deflationary counter to Q2's ambition: perhaps\n + nobody rebuilds the substrate because the losses never justif\n +y it. \n 100 + \n 101 +## Anderson, \"Why Information Security Is Hard \u2014 An Economic P\n +erspective\" \n 102 +- tags: #landmark \n 103 +- catalog [[openalex:W1483280370]] \n 104 +- remarks: Founded the economics of information security. Syst\n +ems fail because the party able to protect them is not the par\n +ty that suffers when they fail \u2014 an externality problem, not a\n + technical one. Explains why libvips has no funded security te\n +am while the losses land on downstream applications, and why t\n +he market rewards shipping features over hardening. The struct\n +ural, non-conspiratorial version of \"we all pay for it.\" \n 105 +- reading: {role: core, why: 'The incentive account of why the\n + flaws persist; pairs with Herley to give the cynical position\n + both an economic and an epistemic leg.'} \n 106 + \n 107 +## Dunn Cavelty & Wenger, \"Cyber Security Politics\" \n 108 +- catalog [[openalex:W7137682891]] \n 109 +- remarks: The critical-security-studies branch \u2014 treats cyber\n + security as a political process in which threats are construc\n +ted and contested, rather than as an objective risk landscape.\n + The securitization reading of the industry. Held as a pointer\n + for the political-economy side of Q3; not yet read. \n 110 + \n 111 +## Gaps in this gathering \n 112 +- tags: #question \n 113 +- remarks: Four holes worth a follow-up pull. First, object-ca\n +pability theory proper \u2014 Miller's *Robust Composition* and Har\n +dy's confused-deputy note are grey literature and did not surf\n +ace in OpenAlex; openalex:W2729947636, \"A Capability-Based Mod\n +ule System for Authority Control\", is the nearest indexed subs\n +titute. Second, Leveson's systems-theoretic accident model in \n +its own right; the search returned only downstream application\n +s such as STPA-SafeSec (openalex:W2475320399), not *Engineerin\n +g a Safer World*. Third, evidence on memory-safe rewrites in R\n +ust, and the Microsoft and Chromium figures putting roughly se\n +venty percent of their CVEs down to memory safety, which are i\n +ndustry reports rather than indexed papers. Fourth, WebAssembl\n +y as a general isolation substrate beyond RLBox's use of it. \n\n Read 1 file, ran 1 shell command (ctrl+o to expand)\n\n\u25cf Now the domain edges between the questions and works.\n\n Ran 3 shell commands (ctrl+o to expand)\n\n\u25cf New doc: security-critique-and-design.l3.md \u2014 23 nodes, 18 works gathered into\n the shared catalog.\n\n The alert is a good specimen\n\n Alert 58 is sharp in package-lock.json, high severity. But the four CVEs are\n not in sharp and not in JavaScript. They are in libvips, a C library sharp\n wraps, and specifically in its GIF, TIFF and VIPS image decoders. The vendor's\n own workaround is to call sharp.block on those three loaders \u2014 that is,\n switch off decoders your application never asked for and never used. Your\n instinct is reading the situation correctly: the fix on offer is \"stop\n granting capability you didn't want,\" which is a design change wearing the\n clothes of a patch.\n\n 1) Why these libraries keep breaking\n\n Three causes, and the literature disagrees about whether they are three or\n one.\n\n The flaws concentrate in parsers of untrusted input written in memory-unsafe \n languages. libvips, libjpeg, libpng, libvorbis are all this shape. Szekeres et\n al., SoK: Eternal War in Memory (2013), systematizes thirty years of defenses\n against memory corruption and finds that every deployed protection has been\n defeated. It also names why stricter policies never ship: performance. Only\n cheap defenses get adopted, so the deployed set is selected for overhead\n rather than sufficiency. That is exactly the pattern you named \u2014 a design\n defect being paid down as a bug stream.\n\n The deeper claim comes from language-theoretic security. Sassaman, Patterson,\n Bratus and Locasto (2013) argue that every file format and protocol is a\n language, every parser an ad-hoc recognizer for it, and that the divergence\n between two implementations' recognizers is directly exploitable \u2014 they\n formalize this as the parse tree differential attack. On this account memory\n corruption is downstream: an over-expressive input format means the \"parser\"\n is really an interpreter for an unspecified grammar, and an unsafe substrate\n is what turns that into arbitrary execution. Their prescription is to make the\n input language weak enough that a decidable automaton can recognize it, and\n to validate fully before processing anything.\n\n Then the ecosystem multiplies it. Zimmermann et al., Small World with High \n Risks (2019), maps the npm dependency and maintainer graphs and finds single\n packages reaching large parts of the ecosystem, a very small number of\n maintainer accounts able to inject code into the majority of all packages, and\n unmaintained packages still depending on known-vulnerable code years after\n disclosure. The dependency graph is a transitive-trust graph nobody audits \u2014\n which is why a C image decoder ends up in your lockfile.\n\n 2) Yes \u2014 and the shipped instance targets your exact bug class\n\n There are two distinct moves here, and conflating them is the usual mistake.\n\n Reduce the input language is the LangSec answer above: no exploitable machine\n exists if the format cannot express one.\n\n Reduce the authority assumes the decoder is compromised and gives it nothing\n worth having. The strongest existing work is Narayan et al., Retrofitting Fine\n Grain Isolation in the Firefox Renderer (RLBox, 2020) \u2014 and it is aimed at\n precisely the libvips class. Firefox's third-party audio, video and image\n libraries were the recurring vulnerability source, so rather than fixing the\n decoders, RLBox isolates each in a lightweight sandbox (WebAssembly or a\n separate process) and enforces the trust boundary in the C++ type system, via\n static information-flow checks plus lightweight dynamic ones. They sandboxed\n libjpeg, libpng, libtheora, libvpx, libvorbis and zlib with modest, transient\n overhead, and shipped it in production Firefox. That is your question answered\n affirmatively with running code.\n\n The lineage behind it: Provos's privilege separation in OpenSSH (a small\n privileged monitor, a large unprivileged worker that touches the untrusted\n bytes); Capsicum, which lets a UNIX process voluntarily drop ambient authority\n so it can afterwards act only through descriptors it already holds; and\n CHERI, which pushes capabilities into the instruction set and claims\n orders-of-magnitude better compartmentalization scalability than the\n memory-management unit \u2014 the unit's coarse granularity being precisely why\n nobody sandboxes per-library today. seL4 bounds the ambition: a\n machine-checked correctness proof did remove a real component from the bug\n stream entirely, but the effort was enormous and the artifact small. That is\n evidence the general method is missing, not that it exists.\n\n The connection to your own work: RLBox's move is to make an authority boundary\n explicit and checkable. Authority today sits at the implicit end of what your\n contract-ness-spectrum doc calls the spectrum \u2014 it is an ambient property of\n whichever process a component happens to run in, not a declared part of its\n interface. I've linked the two docs.\n\n 3) The cynical literature is real, respectable, and sharper than the intuition\n\n Three branches.\n\n Epistemic \u2014 Cormac Herley, The Unfalsifiability of Security Claims (2016).\n This is the strongest form of your position and it is structural rather than\n moral. Security is observationally asymmetric: you can show a system insecure,\n never secure. It follows that any claim a countermeasure is necessary is\n unfalsifiable, while claims of sufficiency are always correctable. The result\n is a one-way ratchet \u2014 a newly speculated attack can argue a control in, and\n no observation can ever argue one out \u2014 so errors accumulate and the field has\n no systematic way to rank or prioritize its defenses. Not a conspiracy; a\n method that cannot retire anything. Start here.\n\n Herley's So Long, and No Thanks for the Externalities (2009) applies the same\n knife to advice: users ignoring it are rational, because a daily burden on\n everyone is bounded above by the harm to the small annual victim fraction. If\n everyone spent one minute a day reading URLs to avoid phishing, the time cost\n would exceed all phishing losses by two orders of magnitude. And with\n Flor\u00eancio, Sex, Lies and Cyber-crime Surveys attacks the industry's own sizing\n number, arguing loss estimates are dominated by a handful of extreme\n self-reports in small surveys.\n\n Empirical \u2014 Rescorla, Is Finding Security Holes a Good Idea? (2005). Measures\n whether vulnerability finding improves software, with assumptions deliberately\n biased toward a positive answer, and finds no clear improvement even then.\n Vulnerability density is high enough and independent rediscovery rare enough\n that closing any one hole barely shifts an attacker's odds. If it holds, the\n whole find-and-patch economy \u2014 your Dependabot alert included \u2014 is close to a\n treadmill. It cuts both ways on your premise, though: if patching cannot be\n shown to help, neither can a refactor.\n\n Economic \u2014 Ross Anderson, Why Information Security Is Hard (2001). Founded\n security economics. Systems fail because the party able to protect them is not\n the party that suffers when they fail. That is why libvips has no funded\n security team while the losses land downstream on you. This is the\n non-conspiratorial version of \"we all pay for it,\" and Odlyzko's Cybersecurity\n Is Not Very Important (2019) pushes it further \u2014 the predicted catastrophes\n have not arrived, ad-hoc containment has been adequate, and perhaps nobody\n rebuilds the substrate because the losses never justify it. That last one is a\n real objection to question 2's ambition, and I've filed it as complicating\n rather than supporting.\n\n Gaps I flagged in the doc\n\n Four, all recorded as follow-ups: object-capability theory proper (Miller's\n Robust Composition and Hardy's confused-deputy note are grey literature,\n absent from OpenAlex); Leveson's systems-theoretic accident model in its own\n right, which argues accidents come from interactions between individually\n correct components \u2014 the safety-engineering twin of your premise, but only\n downstream applications surfaced; the memory-safe-rewrite evidence and the\n Microsoft/Chromium \"roughly seventy percent of CVEs are memory safety\"\n figures, which are industry reports rather than indexed papers; and\n WebAssembly as a general isolation substrate beyond RLBox's use of it.\n\n\u273b Cooked for 6m 50s\n\n\u276f how can I share this session with group of people? \n\n\u25cf A few options, depending on what you want to share \u2014 the research, or the\n conversation itself.\n\n The research itself. It's already a file: security-critique-and-design.l3.md\n in braincrawl-l3, which is a git repo. Push it and the doc is shareable as-is,\n and readable by anyone else's braincrawl. That's the durable form.\n\n A hosted page. I can render the doc \u2014 the three answers, the works, the\n reading order \u2014 as an Artifact: a web page on claude.ai that starts private\n and that you then choose to share with specific people. That's the best fit\n for \"a group of people\" who aren't going to clone a repo. It gets a stable URL\n I can redeploy to if the doc grows.\n\n The conversation transcript. Claude Code has an /export command for writing\n the session out to a file or the clipboard \u2014 worth checking /export in your\n prompt to see the formats it offers. There's no built-in link-sharing for a\n CLI session, so exporting and sending the file is the route.\n\n Want me to build the Artifact? I'd shape it as a standalone briefing rather\n than a transcript dump \u2014 the specimen (sharp \u2192 libvips \u2192 decoders), the three\n questions with their answers, and the works grouped by which question they\n serve, with the two start-here readings called out. Say the word and I'll also\n tell you whether to point people at the repo file instead, if they're the\n kind of group that would rather have the markdown.\n\n\u273b Churned for 25s", "creation_timestamp": "2026-07-27T18:53:11.942459Z"} 2026-07-27T18:53:11.942459+00:00