There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors. This old joke highlights that naming stuff is notoriously tricky — and not just for programmers who can’t count.
What I actually mean is: names are not just labels. They’re interfaces. They carry assumptions. They leak context. And sometimes, they carry authority.
Names are not just labels. They’re interfaces.
This post is the setup for that idea: why names are messy in human life, why cultures have treated names as power, and why a concept in computer security called object capabilities treats “a name” like a literal key.
Names Are Weird: Falsehoods Programmers Believe
Computers are extremely logical, but human names? Not so much. If you’ve ever designed a system that deals with people’s names, you may have stepped on one of the many landmines hidden in our assumptions about naming.
There’s a famous list by Patrick McKenzie titled “Falsehoods Programmers Believe About Names”, which is basically a hall of fame for many naïve assumptions that will break your code. A few highlights:
“People have exactly one canonical full name.”
“People’s names fit within a certain defined amount of space.”
“People’s names are written in ASCII.”
“People’s names are globally unique.”
“People have names.”
The list is funny because it’s true, and it’s true because… we are messy. Names change. People change. Cultures disagree about what counts as a name, which part “goes first,” whether you have a last name, whether the thing you’re writing down is a legal name or a social one, and whether your name even fits into the dropdown the website designer made on a Tuesday afternoon.
The takeaway: names are an identity mirage — we think they’re straightforward strings, but they hide a world of complexity and culture.
Names are often relational, not absolute
As a reminder that “name” can be a relationship rather than a noun: Vietnamese pronouns commonly use kinship terms (e.g., anh/chị/em, cô/chú/dì, etc.) that depend on who is speaking and how you’re related.
And in many families, people are also referred to by birth-order numbers (often discussed in the broader context of Vietnamese names): “the second child,” “the third child,” and so on. In practice these labels are often cemented by first introduction in a family/community context — they’re not private “petnames” in the technical sense, but shared relational handles that make perfect sense to humans and terrible sense to a first_name column.
A “name” like anh (older brother) isn’t identifying you the way a passport does. It’s telling you how I’m positioned relative to you. It’s meaning, not just reference.
Software tends to want the opposite: a stable identifier, globally unique, consistent, and preferably lowercase. Humans respond: “Cute.”
The lesson here? Be careful when you ask for or use someone’s “name” in a system. You might be assuming falsehood #41 without realizing it.
True Names: Ancient Magic and Power Labels
Long before identity thieves and database designers struggled with names, our ancestors were telling tales about the magical power of knowing a name. The idea appears across many cultures: if you know a being’s true name, you can control it.
In myth and folklore, a name isn’t just a label — it’s like having the root password to that person or thing’s soul.
In myth and folklore, a name isn’t just a label — it’s like having the root password to that person or thing’s soul.
For a modern tour of “true name” lore across cultures (with delightful examples), see Tammy Salyer’s “The Magic of True Names”.
You see the pattern everywhere:
In some Egyptian stories, Isis gains power over Ra by forcing him to reveal his hidden True Name.
Folk tales like Rumpelstiltskin turn “guess my name” into a life-or-death security challenge.
Fantasy like Earthsea treats names as the underlying API for reality.
These stories all share the same claim: knowing the right name is a form of access.
What’s interesting is that this is not just poetic. It’s a clean mental model: knowledge of a secret token grants ability to do a thing. That’s basically security.
And then computer science, being computer science, reinvented it with better fonts.
Object Capabilities: When Names Become Keys
Most modern security systems are identity-first. They ask “Who are you?” and then consult an access control list: “Okay, you’re Jas, you may read this file, but not that one.” It’s bouncers and wristbands.
Object capabilities (ocaps for short) flip the question:
Not who are you? but what do you have?
The mantra of capability-based security, coined by Norm Hardy, is: “Don’t separate designation from authority.” Translation: if you can name (designate) a thing in a meaningful, usable way, that naming mechanism often is the authority boundary. So embrace it. Make it explicit.
A capability is an unforgeable reference — a handle — that grants you the ability to interact with some object/resource. If you have the handle, you can use it. If you don’t, you can’t. No global permissions table required.
In the capability model, knowing the name of something is the power to use it.
Car keys (aka best successful capability demo)
A car key doesn’t ask you who you are. It doesn’t care if you’re the owner, the owner’s cousin, or a raccoon with ambitions. It checks one thing:
Do you have the key?
If yes: engine starts. If no: enjoy your walk.
That’s a capability.
This is also why “name” is not the right everyday word in security discussions. Because we hear “name” and think “label.” Capabilities are closer to “handles that unlock something.”
Secret URLs and “names that grant access”
Now take the web’s most popular accidental capability system: the share link.
You create a secret, unguessable URL to a document. Anyone who has the link can view it. Maybe edit it. That URL is a handle that carries authority by possession.
In capability terms, those are often called capability URLs.
A more old-school capability implementation happens to be a YURL: a URL that is intentionally hard to guess and whose possession is what grants you access. It’s “security by unguessability,” except said in a way that doesn’t make your security friends faint.
There are caveats (I am over simplifying a lot of things here!) but the core idea is powerful and surprisingly practical: delegation becomes trivial. Want someone to access the thing? Give them the handle.
Two secret URLs to the same thing can mean different …things
Here’s a subtle part that ties back to relational human names.
Two different secret URLs can point at the same underlying document and still mean different things.
They might encode different permissions (view vs edit), different lifetimes, different audiences (“this link is for my team” vs “this link is for my accountant”), or simply different sharing paths that you want to keep separable for auditing and later revocation.
Even if two links grant identical access today, they can still be distinct handles with distinct meaning.
That’s the web version of calling the same person “Mom,” “Dr. Nguyen,” or “Hey you”: same referent, different relationship, different implied power. Multiple names for one thing isn’t a bug; it’s how humans (and good security designs) express context.
The name you give something is not the name of the thing — it’s how you came to know the thing.
Zooko’s Triangle
If naming still feels slippery, here’s a classic distributed-systems trilemma: Zooko’s Triangle.
Global naming systems want three properties, but (in general) you only get two at once:
Human-meaningful (memorable: jas.example)
Decentralized (no single naming authority you must trust)
Secure (hard to spoof; the name reliably binds to the right thing)
DNS is human-meaningful, but its security depends on a stack of governance and trust. Cryptographic identifiers can be secure and decentralized, but they’re not human-meaningful unless you’re the kind of person who memorizes SHA-256 hashes for fun. (No judgment. Slight judgment.)
Capability systems are oddly content living in the secure + decentralized corner: the handle is deliberately hard to guess/forge, and authority flows by explicit delegation.
The human-friendly part usually lives one layer up: you keep a local alias book — a “petname” system — mapping your memorable names to those unguessable handles. Marc Stiegler’s intro to petname systems is a great place to start if you haven’t seen that framing.
This is another way names become relational: a petname is meaningful to you, in your context, rather than pretending to be universal truth.
Closing
Names are weird in people-land, powerful in myth-land, and in capability-land they’re part of the security boundary. That’s the through-line: the moment a “name” becomes a handle you can pass around, it stops being mere labeling and starts shaping what’s possible.
In the capability model, knowing the name of something is the power to use it.
And maybe that’s the most useful mental shift: treat names like interfaces, not décor. Ask what assumptions they embed. Ask what they grant. Ask what they mean — to humans, to systems, and to whoever is holding the handle.
Names are weird, wonderful, and occasionally a little overdramatic — like they’re auditioning for a YA fantasy novel and a schema migration at the same time.
Names Are Handles was originally published in Recursive Rhymes on Reason on Medium, where people are continuing the conversation by highlighting and responding to this story.