Developer. Open Source Enthusiast. Life long learner. Loves Lean, Agile, TTD, XP & Doing t̶h̶i̶n̶g̶s̶ ̶„̶r̶i̶g̶h̶t̶“̶ the "right things". Works at @colen_io
The Engineer Atlassian Laid Off Who Responded with a 38-Minute Documentary: What Every Leader Must Learn https://t.co/ege5UI9T3m
Video: https://t.co/9C5lcgZ6A3
I'm genuinely stunned by how many people push back on the #EU#ageVerification issues with "it's a demo, it's not a production app... don't you understand?!"
When the President of the EC publicly states it's "technically ready, reaches the highest standard of privacy and go check the code"... it shouldn't come as a surprise when someone does just that.
There's a growing number of people screaming "it's protected by Android, this is a non-issue".
I don't know about you... but I'd rather have a few layers of substantial security to protect my biometric data than rely on a 3rd-party layer which may fail or have bugs/flaws of its own. This app was supposed to set a standard, not fall back to one.
Let's shift focus and explain why the #EU#AgeVerification concept is fundamentally flawed.
Assume:
1. The production app is released.
2. It's 100% secure, 100% private (fantasy land, but stick with me)
3. It cryptographically challenges every step, including hardware attestation which requires a physical device.
4. Every single other attack vector in the surrounding environment is somehow magically patched.
aka - it's working exactly as intended/designed.
It does not protect against a relay attack.
This is a threat they considered and somewhat addressed here: https://t.co/9sYkz8voCF
With the current design, there's nothing preventing someone running a verification-as-a-service; a remote Android device which returns a valid attestation. Remember, it's not returning "I am over 18", it returns "someone is over 18". Neither the verifier, nor the app has any way to link the session ID to a physical device.
Their own docs state this clearly:
Remote Cross-Device Presentation:
"Note that the Wallet Instance does not see any difference between the cross-device flow and the same-device flow. In both cases, it receives an OpenID4VP-compliant presentation request over the Wallet Instance-platform API described in the previous section."
This is a known & well-understood attack vector in all remote credential presentation models; it's just not mitigated in this one... primarily because they can't. CTAP 2.2 won't work with all app flows, hardware attestation doesn't mitigate relay attacks, on-demand liveness detection would be too intrusive & potentially privacy-invasive & timing calculations don't reveal anything useful... all the available options to resolve this break the core design; completely anonymous age verification.
The Architecture & Reference Framework (ARF) is technically sound in some respects. They considered external threat actors and discussed solutions to mitigate them, including ZKP. However, the EC applied the wrong threat model, thus arriving at the wrong conclusion.
Yes, you need to protect against malicious verifiers, phishing sites, session hijacks, data brokers et al... but that's addressing external threats, it doesn't protect the architecture from the user itself.
In virtually every other scenario, the user and system's interests are aligned; protect my biometric asset at all costs.
Specifically for age verification, most users do not want to present ID simply to access a website, so whilst the system may adequately protect from external threats, if the user wants to bypass the system, they can... and the architecture doesn't consider this.
Every single applied mitigation assumes the user is the protected party, not the threat actor.
To those people claiming "it requires physical access to the device and root, this is BS/hyperbole", you too applied the wrong threat model & completely missed the point. These disclosures demonstrate that you, the user, are the threat actor they haven't considered.
You have your device.
You can root your device.
You can create a chrome extension, just as I did.
Ironically, it's precisely those under 18 who can't pass verification who are motivated to bypass it.
So where does that leave us?
A system which replaces "I am over 18" with "someone is over 18", with absolutely no guarantee that it's true... which is the entire purpose of the app.
If you’re serious about system design this year,
learn these 12 concepts:
1. How JWT Works
↳ https://t.co/Kuv7DAj6B9
2. Idempotency in API Design
↳ https://t.co/2sItwlz1oe
3. ACID vs BASE
↳ https://t.co/a7nOyylUxk
4. How Observability Turns Alerts Into Insight
↳ https://t.co/VjfECfyB9d
5. Rate Limiting Explained
↳ https://t.co/wr0UAh4sJm
6. Message Queues Explained
↳ https://t.co/7Tz5sevNA8
7. Change Data Capture (CDC)
↳ https://t.co/tgwwoTitCA
8. Connection Pooling
↳ https://t.co/39SsEo4kk3
9. How Consistent Hashing Works
↳ https://t.co/8d8o74EsaS
10. SQL vs NoSQL
↳ https://t.co/oDTRpsnQUn
11. Health Checks vs Heartbeats
↳ https://t.co/r5SalP6CCh
12. API Protocols
↳ https://t.co/2CEu4Wnhsv
What other concepts should be on this list?
--
👋 PS: Want my 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝘀𝗶𝗴𝗻 𝗛𝗮𝗻𝗱𝗯𝗼𝗼𝗸 𝗳𝗼𝗿 𝗳𝗿𝗲𝗲?
Want my 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 𝗣𝗹𝗮𝘆𝗯𝗼𝗼𝗸 𝗳𝗼𝗿 𝗳𝗿𝗲𝗲?
Join my newsletter with 26,501+ software engineers: https://t.co/OQtXb4zMoe
--
🔖 Save for later.
♻️ Repost to help others learn system design.
➕ Follow Nikki Siapno + turn on notifications.