co-written with UnitBuilds, who built most of this out loud in the comments of my last piece.
I recently wrote about the $30. someone in cambod...
For further actions, you may consider blocking this person and/or reporting abuse
This reminded me of Wikipedia's entry on On Contradiction — specifically this part: "When old processes change, new processes and contradictions emerge."
KYC set out to solve verification. It did — and created a new contradiction right inside the solution. A bounded proof now backs an unlimited liability. The fix didn't remove the problem. It just moved it.
@unitbuilds nailed it: "the system protects money, not people." In the language of the text — the principal aspect of the contradiction is always capital, and the secondary side always carries the cost. That pattern isn't limited to biometrics. It shows up in KYC, Secure Boot, every hardware handshake. Not a bug in the implementation. It's the architecture.
Not to mention, KYC made the lie look right on paper. @kenielzep97 and I had a discussion about the exact failure point when it came to NDA file format. Even if a document is self-correcting, if a balance sheet balances, it's considered correct, there's no way for the document to know that the values were wrong and a lie the system thinks is true, is more dangerous than a lie that gets questioned. Because now it's a face to the account, but that face is the lie, because it's not the person using it. As long as the process itself is the only verification stage, it's open to fraud... Except now it's verified fraud that nails down liability on 1 person.
Take a phone for instance, you use facial ID, it assumes owner is you, because of your face. But loading a face is a 1 time procedure, that can allow anyone really to get full authority of your device. Eg. scenario, mine is added on my fiance's phone, but by me having access via biometrics, it means I can go on app store and make purchases from her account, with nothing but my face. So who pays the bill? (still me, cuz my card is linked, but you get the point 😂)
UnitBuilds, "verified fraud" — that's exactly the transformation of opposites On Contradiction is talking about.
"The two aspects of contradiction coexist and aspects can transform into one another. Any one aspect is dependent on the existence of at least one other aspect."
Verification and fraud aren't fighting each other. They're the same coin. Once the system stamps "verified" on a face that isn't the user's — verification just turned into fraud. Same mechanism, opposite ends. You can't have one without the other.
Your phone example says it all: load your face once, now any face that passes is the owner. The thing that's supposed to protect you becomes the thing that bypasses you. No external breach needed — the attack path was built into the design from day one.
Exactly, the real problem is, design a system that's actually anti-fraud. Doesnt matter how many verification steps you add, it's still spoofable. Fake ID, Fake face, Fake fingerprint, copied private key, copied account logins, proxied IP, cloned phone number. Even standing face to face with a person, who shows you their ID and bank account, you cant verify anything really, it just boils down to trust. How much do you trust the authentication methods used to verify they are who they say they are.
Exactly why the principal contradiction keeps moving. KYC solved "who are you" — then "who verifies the verifier" took its place. Solve one, the next one's already waiting.
@xulingfeng, @unitbuilds . "a lie the system thinks is true is more dangerous than a lie that gets questioned" and "the principal aspect of the contradiction is always capital" are the same observation from different traditions landing in the same place.
The verification mechanism doesn't know the difference between a face and the truth behind it. the system stamps verified, capital is protected, and the lie becomes load-bearing. that's not a failure of implementation . it's the architecture completing its intended function.
the phone example closes it: one face loaded once, full authority granted indefinitely, bill paid by whoever's card is linked. the system worked exactly as designed. that's what makes it dangerous.
the line that a control which can't see its downstream relocates the harm is the whole thing, and i'd put a finer point on the mechanism: this is authentication being silently promoted to authorization. the biometric check only ever proves one thing, that a specific person was present for one moment. the system then treats that as standing permission for everything the account does forever. a bounded proof underwriting an unbounded liability window. that gap is where the harm lives, and it always rolls downhill to whoever is cheapest to enroll.
and it isn't a biometrics problem, so a stronger or wider check doesn't fix it. the fix is scoping the authority the proof grants. bind the verification to a specific bounded action or window, not to the account and every future action attached to it. "this face passed once" should never compile to "this holder authorized all of it, indefinitely." most of these systems collapse identity, presence, and authority into one event because it's convenient at signup, and the person who pays for that collapse is never the one who designed it.
from where i sit, $30 for a quick verification is a completely real offer to a lot of people, and none of them are reading the liability surface they just underwrote. the asymmetry isn't an edge case the design missed, it's load-bearing.
Vinicius, "a bounded proof underwriting an unbounded liability window" is the sentence that should be in the piece. That's the mechanism stated precisely not a flaw in the verification, a flaw in what the verification is allowed to authorize. the check proves presence at one moment. the system compiles that into standing permission for everything, indefinitely. the gap between those two things is where every harm in this thread lives.
The fix you're describing — bind the proof to a specific action or window, never to the account and all future actions is the right architecture. the problem is that collapsing identity, presence and authority into one signup event is convenient for the platform and catastrophic for the person. convenience always wins at design time because the person paying the catastrophic cost isn't in the room when the decision gets made.
that line goes in the follow-up piece verbatim...
agreed. and the reason it keeps happening is the grant isn't even a thing you can point at in most of these systems. presence and authority ride the same token, so "scope it" becomes a discipline you have to remember every release, and discipline loses to convenience every time.
the version that holds is making the grant its own object: it carries the action it's good for and the window it dies in as first-class fields, issued at the moment of use, not at signup. then "this face passed once" can't be represented as "this holder authorized all of it", because no token says that. you're not scoping the authority by being careful, you're making the unscoped version unrepresentable.
if you want the follow-up's spine in one line: the goal isn't to scope authority carefully, it's to make unscoped authority impossible to express.
Horrible, and frightening - we might call it "digital slavery" ...
And this:
"kyc doesn't stop fraud"
But of course not, that's been obvious from day 1 - KYC is only for "legally cover your ass" purposes, it does nothing to deter criminals - just tons of bureaucracy to harrass the little man, while the millionaires, the billionaires and the professional crooks know how trivially easy it is to evade it ...
The tricks get more nasty and sophisticated, the goals (extorting $$$ from the innocent) stay the same!
leob, "legally cover your ass while doing nothing to deter criminals" is the honest version of what KYC is. the burden lands on the person cheapest to burden. that's not a side effect . it's the design.
the 'bounded proof, unbounded liability window' framing from Vinicius is the cleaner mechanism statement. the system treats 'was present at one moment' as 'authorized indefinitely' because collapsing both into one token is cheaper to ship.
we hit the same shape in AI agent auth: sign one webhook event and the platform compiles that into full API access — because the key proves 'authenticated' and authentication carries no downstream scope. 'this integration signed once' shouldn't mean 'this integration owns the account.'
is there a version of the grant as object fix that doesn't require the platform to want the complexity, or does it always bottom out at 'whoever absorbs the edge case wasn't in the room'?
Mudassir, "whoever absorbs the edge case wasn't in the room" is the answer to your question. there isn't a version of the grant-as-object fix that doesn't require someone to want the complexity because the complexity is the cost of not externalizing the failure onto whoever is cheapest to absorb it. the platform that collapses authentication and authorization into one token does so because scoping is expensive to build and the person who pays for the collapse isn't a stakeholder at design time.
The webhook example makes it concrete — sign once, own the account, because that's cheaper to ship than expiring scopes. the fix exists architecturally. it just requires the platform to internalize a cost it currently externalizes. that's a business model problem before it's an engineering problem.
Interesting take on the long-term risks of low-cost hardware. In my work with GPU infrastructure, I've seen how cheap components can lead to hidden costs in maintenance and security—especially when dealing with sensitive workloads. At VoltageGPU, we focus on making confidential computing more accessible, but it's a constant balance between cost, performance, and trust.
As someone who's worked on secure GPU isolation, I can say that $30 is a drop in the bucket compared to the risk of a side-channel leak or misconfigured enclave. You're not just paying for the code — you're insuring against the next Meltdown variant.