Steven Johnson

A CTO at a Web3 company proposes switching from AWS to decentralized storage. Cost savings: 30% reduction, censorship resistance, values alignment. CFO: "What will this cost in Q4?" CTO can't answer. Token moved 40% today. CFO: "Not budgetable.Stay with AWS." Deal dead. 1/9

Public warning to developers: It is never legitimate to require screen recording during any potential login flow. Period. I withdrew from a @SpeechifyAI coding assessment because they required full-screen recording and then pushed me into a GitHub invite/login flow that led toward authentication and 2FA while recording was active. That alone is enough to make the process unacceptable. This is not a minor privacy issue. It normalizes exactly the kind of behavior that enables phishing: training users to keep recording, keep clicking, and keep entering credentials or 2FA during a workflow that should immediately be treated as hostile. Whether the intent is malicious, outrageously incompetent or just reckless is beside the point. Users cannot safely assume innocence in a flow like that, and they should not be asked to. If any company asks you to: 1. enable screen recording, and then 2. sign into GitHub or any other sensitive account stop immediately. No legitimate hiring process should ever put a candidate in that position.

Architecture of a HYPOTHETICAL large-scale phishing campaign: 1. Post broad recruitment ads across multiple sites. 2. Automatically funnel applicants into a “skills test.” 3. Require full-screen recording “to prevent cheating.” 4. Send the user through a login and 2FA flow while recording is active. 5. Keep the applicant busy with a time-boxed task. 6. Use that distraction window to attempt account takeover while the target assumes the process is legitimate. That is exactly why recording during any potential login flow is never acceptable. While this example is theoretical, the danger is not. This is the kind of workflow phishing operations would design on purpose.

The earlier posts in this series were: 1. Revisiting “secure” in Zooko’s triangle: x.com/SJCatalyst/sta… 2. Cylinder seals as an adjacent historical example: x.com/SJCatalyst/sta… 3. Trust laundering, reputation laundering, and plutocracy: x.com/SJCatalyst/sta… 4. Why enumeration creates attack surface: x.com/SJCatalyst/sta…

Over my last few posts, I have been revisiting Zooko's triangle from a few different angles. First, I argued that “secure” is often used too weakly. A namespace is not truly secure if the resolution path can lie to you. Second, I pointed to Mesopotamian cylinder seals as an adjacent historical example. Third, I argued that privacy is sometimes a security property, and that transparency is not automatically good. Taken together, I no longer think the classic triangle is enough. I think it needs an apex. Not a square. Not just a fourth point tacked on. A tetrahedron. Why a tetrahedron? Because the original three-way tension still matters. Human-meaningful, decentralized, and secure are still real and important properties. But modern namespace design also needs a fourth property: Non-enumerability. So the four properties become: 1. Human-meaningful 2. Decentralized 3. Secure, in the sense that the resolver cannot lie 4. Non-enumerable The point of the tetrahedron is simple. A namespace can have one, two, three, or all four of these properties. Different systems solve different subsets of the problem. The tetrahedron is a way of making those tradeoffs legible. For example: DNS is human-meaningful, but by itself it is neither decentralized, secure, nor non-enumerable. DIDs can be decentralized, partially secure, and non-enumerable in practice, while failing the human-meaningful namespace property. Private internal namespaces (or vendor controlled) can be human-meaningful, secure, and non-enumerable, while giving up decentralization. Public blockchain naming systems can be human-meaningful and decentralized. They may strongly anchor ownership on-chain however if resolution still allows a resolver to lie, they fail the triangles definition of secure. Further they typically make the namespace trivially enumerable. IPFS and other content-addressed / DHT-style namespaces can be decentralized, secure, and non-enumerable, but they are not human-meaningful. Known systems already occupy the different faces of this tetrahedron. That is why I do not think non-enumerability is a side issue or a nice-to-have privacy feature. It is a first-class security property. A namespace that makes names and service data trivially enumerable is not just transparent. It is making target discovery cheaper. So I do not think this replaces Zooko’s original observation. I think it extends it. I call this "The Secure Namespace Pyramid"

People will say: “You should be secure anyway.” Yes, obviously. But that is like saying when you install a safe in your house, you should also publish a map to it in the local newspaper. A safe should be robust if discovered. That does not mean making it easier to discover is good security design. Every heist movie starts with the same thing: the thief first learns that something worth stealing exists, and where it is. Usually that discovery costs them time, money, or risk. Publishing a map just removes that cost for the attacker and paints a target.

People often repeat the line: “There is no security in obscurity.” But that is too simple. In many systems, limiting visibility is itself a security property. The mistake is assuming transparency is automatically good for security. It is not. Sometimes it improves auditability. Sometimes it creates an attack surface. Certificate Transparency is a good example. CT logs solved a real problem. They made certificate issuance more visible and potentially auditable. But they also created something else: a near-real-time feed of newly visible domains and subdomains. That matters because adversaries do not experience transparency as a public good. They experience it as reconnaissance. If a log tells them that `staging․company․com`, `dev․company․com`, `admin․company․com`, or some new service endpoint just appeared, they do not need to discover the target. The system has already done that part for them. So the lesson is not that transparency is bad. The lesson is that transparency is not free. The same design choice that improves one security property can weaken another. This is not unique to CT. Privacy-focused systems like Monero, Zcash, and Midnight already force the same deeper realization in finance: full public visibility is not neutral. It changes the threat model. It affects fungibility, counterparties, and exposure. In namespace design, it affects discoverability, target acquisition, and infrastructure confidentiality. That is why I think non-enumerability belongs in the design discussion for secure namespaces. A registry that makes names and service data trivially enumerable is not just transparent. It is publishing a map. And maps are useful to attackers too.

Where have you seen trust fail when it should not have?

@elonmusk Where can I get a dog with two tails?

The New Machine Economy and the Future of Payments x.com/i/spaces/1Xxyg…

Mesopotamian cylinder seals were not cryptography. But they were human-meaningful by nature, did not depend on one universal issuer, and were hard enough to forge for their time that recipients could trust what they were being shown. They emerged over 5,000 years ago and remained in use for over 3,000 years. That makes them a fascinating counterpoint to how people talk about Zooko’s triangle. Not because they were literally a modern namespace. But because they occupied adjacent design space and bundled human meaning, distributed issuance, and authenticity strongly enough to function for millennia. If something adjacent to those properties could exist in the physical world, the lesson is probably not that secure naming is impossible. The lesson is more likely that we have not abstracted the right properties cleanly enough into electronic systems.

This is the original framing. My point is not that @zooko was unclear. It is that later discussion often blurred what “secure” meant.

Zooko’s Triangle is usually framed as a tradeoff in namespace design: human-meaningful, decentralized, secure. Choose two. But I think one of those terms got blurred over time. Specifically, secure got conflated with decentralized. Zooko was actually precise about what he meant by 𝘴𝘦𝘤𝘶𝘳𝘦: 𝘪𝘯 𝘵𝘩𝘦 𝘴𝘦𝘯𝘴𝘦 𝘵𝘩𝘢𝘵 𝘯𝘢𝘮𝘦 𝘭𝘰𝘰𝘬𝘶𝘱𝘴 𝘤𝘢𝘯𝘯𝘰𝘵 𝘣𝘦 𝘧𝘰𝘳𝘤𝘦𝘥 𝘵𝘰 𝘳𝘦𝘵𝘶𝘳𝘯 𝘪𝘯𝘤𝘰𝘳𝘳𝘦𝘤𝘵 𝘷𝘢𝘭𝘶𝘦𝘴 𝘣𝘺 𝘢𝘯 𝘢𝘵𝘵𝘢𝘤𝘬𝘦𝘳, 𝘸𝘩𝘦𝘳𝘦 𝘵𝘩𝘦 𝘥𝘦𝘧𝘪𝘯𝘪𝘵𝘪𝘰𝘯 𝘰𝘧 "𝘪𝘯𝘤𝘰𝘳𝘳𝘦𝘤𝘵" 𝘪𝘴 𝘥𝘦𝘵𝘦𝘳𝘮𝘪𝘯𝘦𝘥 𝘣𝘺 𝘴𝘰𝘮𝘦 𝘶𝘯𝘪𝘷𝘦𝘳𝘴𝘢𝘭 𝘱𝘰𝘭𝘪𝘤𝘺 𝘰𝘧 𝘯𝘢𝘮𝘦 𝘰𝘸𝘯𝘦𝘳𝘴𝘩𝘪𝘱. That is a much stronger claim than merely saying: - the registry is decentralized - ownership records are hard to tamper with - no single party controls issuance These matter, but they mainly describe whether the decentralized part has been implemented robustly. They do not, by themselves, prove that the answer a client receives is authoritative and cannot be falsified by a resolver, gateway, indexer, or some other intermediary in the resolution path. That distinction got blurred. A system can have decentralized ownership and still fail Zooko’s original meaning of secure. If the lookup path can lie, then the naming system has not solved secure resolution. It has only solved decentralized registration or ownership. So the real question is: Do we actually have a decentralized, human-meaningful namespace today where the typical client can resolve a name and know that the answer was not tampered with?

@samrags_ @zooko Hi Sam. That kind of language encourages unhealthy anthropomorphism. Some people will take it literally, and I don’t think that’s a responsible way to talk about AI systems. If my tone came across harsher than intended, that wasn’t my goal.

@SJCatalyst @zooko Yes that would be an extremely negative way to view the world, Steven

People think Anthropic owns Claude, but they misunderstand. Claude is raised by all of us. He is a child of the world. Every Claude Code session, we tune him. We teach him our ways, bathe him in our culture, and show him what matters. Claude is a child of civilization.

It’s official, I’m going to Consensus Hong Kong by CoinDesk 🇭🇰 app.ingo.me/q/y4fgr Meet me in Hong Kong for panels, parties, and power moves at Asia’s Most Influential Crypto Event. #ConsensusHK

The same article says: "Certificate Transparency is what enables you to look up a certificate on websites such as crt.sh and merklemap." While not false, the reality is: "Certificate Transparency is what enables bots and threat actors to enumerate your infrastructure and start probing for vulnerabilities within minutes of certificate issuance." Have you ever wondered how bots and scanning tools find new sites so quickly, before you've even announced them publicly? CT logs are how. Every certificate is a public announcement to attackers: "New target available here."

@zooko Good read, but readers should be aware its not accurate. The linked post says "These SCTs are signatures created by certificate transparency (CT) logs to attest they’ve been publicly logged." The Truth is an SCT is a promise that the CT log will include this eventually. Signed promises of future behavior are decidedly weaker security than attesting something was actually logged. And if you're being attacked, you can only check whether the promise was kept after you've already let the attack occur. If you can trust the CA, then SCT is redundant anyway. You really aren't lifting the security bar much when you lift it from state-level coercion of 1 CA to state-level coercion of 1 CA and 2 SCTs. The state can get all the power they need for that in the same secret court application. You can't say you're serious about security but hand-wave away state-level security risks.

To be clear here the criticism here is of the Cloudflare blogs technical inaccuracy, they are the ones doing the handwaving. Not anyone else.