Hook: In today's Habr digest, a note about the EU Age Verification Project and its hardware-bound attestation requirement caught my eye. At first glance — a narrow legal topic about "how to verify age on the internet." But when I dug into the primary sources (the official ageverification.dev specification, EFF's July 9, 2026 article, GrapheneOS materials, biometric press, Issue #11 on GitHub from Daniel Micay himself, GrapheneOS founder) — something clicked in my head. I found a perfect story about how the state, playing the "child protection" card, technically legitimizes a monopoly by two American corporations over digital citizenship. And this isn't conspiracy theory — it's openly documented in Issue #11 on the project's GitHub, where Micay says point-blank: "you're violating your own Digital Markets Act by cementing Google's monopoly." And European Commission representatives closed that Issue without changing the architecture.
The topic doesn't repeat any of the last five curiosities (Demag/Chernobyl, Shape Dynamics, Kojima's MGS2, hippie trail, Active Clearance Control), isn't about AI (though EFF mentions it in the digital identity context, which is adjacent but not the same), and has engineering nerve: a story about how one failed architectural decision at the specification level quietly turns the "free internet" into an "internet with a double bottom."
On April 29, 2026, the European Commission released Commission Recommendation (EU) 2026/1035 — a framework document on a unified European age verification system. Goal — fulfill Article 28 requirements of the Digital Services Act (DSA): protect minors from harmful content. In press materials, the European Commission emphasizes: "privacy by design," "open-source," "interoperable across member states," "bridges until EU Digital Identity Wallet."
At the rhetoric level — it's child protection. At the implementation level — it's history's first European attempt to issue every citizen a cryptographically signed passport on hardware. That's where things get interesting.
The official specification ageverification.dev/Technical Specification/architecture-and-technical-specifications mandates:
This is the key architectural decision: to prevent the "I'm 18+" token from being copied and used in ten places simultaneously, it's bound to a physical chip.
Sounds reasonable. Until you ask the question: what devices actually have such chips?
Initially, the EU AV reference implementation used Google Play Integrity API — Google's commercial service that verifies an app is running on an "approved" Android device with GMS licensing. This isn't cryptographic attestation — it's an HTTP request to Google's servers that says: "yes, this phone is in our garden."
This caused a scandal. Daniel Micay, founder of GrapheneOS (recognized mobile OS security expert, former CopperheadOS maintainer), created Issue #11 in the project repository. Quote: "Google Play Integrity API is a business tool, not a security tool. Use Android Hardware Key Attestation API — it verifies the same thing cryptographically, without contacting Google's servers, and allows whitelisting alternative OSes."
The community supported it: hundreds of 👍 under the Issue, dozens of forks with discussion. Micay's argument is technically flawless — Android Hardware Key Attestation is mandatory for all devices with Android 8+ (this is a CDD/CTS requirement), doesn't require Google Play Services, and allows verifyBootKey pinned verification for alternative OSes (that exact feature that lets GrapheneOS pass attestation).
Under community pressure, the European Commission eventually replaced Play Integrity with Hardware Key Attestation. That's a victory. But — a partial victory. And here's why.
Hardware Key Attestation is technically better, but the architectural problem remains. To pass attestation, you need a device that:
This third point is the slipperiest. Quote from the specification: "Attestation Providers would issue credentials to applications that appear on a compliance list maintained by the European Commission." So the source code can be open, you can fork it, build your own build, run it on Pixel 10 with GrapheneOS. But the credential provider can refuse, because your build isn't on the European Commission's whitelist.
This is called "source-available, not open". The difference between a GitHub repository and a public service. You can read the code. You can't participate.
EFF in their July 9, 2026 article Google's New Remote Attestation Scheme is As Bad As Its Old One unfolds this logic to its conclusion. The parallel with Web Environment Integrity (WEI) — Google's failed 2023 attempt to embed attestation in HTTP — isn't accidental here. WEI was killed by public reaction back then. But the infrastructure didn't go anywhere: Secure Enclave and StrongBox are already in every phone, and any state can activate it through a "compatible" specification.
Apocalyptic (but realistic) scenario:
The juiciest bit: this contradicts the EU's own Digital Markets Act (DMA), which explicitly prohibits "upholding a monopoly on a foreign technology provider." As documented in Issue #11: "irreconcilable with DMA Article 6." One EU law conflicts with another EU law. And characteristically — none of the European Commission lawyers gave a public response to this specific point.
In Annex B of the specification, it's described in detail how ZKP (Zero-Knowledge Proofs) could solve the problem: the user proves "I'm 18+" without revealing identity, without device binding, without hardware keystore. Cryptographically clean solution, no monopolies.
Why was ZKP postponed? The specification explains: "introduce additional complexity, which could hinder the rapid adoption." Translation: we don't want to wait two years for ZKP libraries to mature. Better to quickly deploy hardware attestation and close DSA requirements on schedule. This is classic tech debt at the specification level: instead of a fundamental solution, we choose what works "right now," knowing it will cement vendor lock-in.
The Dutch Yivi project (formerly IRMA) has long worked with attributes based on ZKP/BBS+ — there the user stores a set of signed attributes (age, citizenship, student status) and presents them selectively. Yivi is technically ready to show that ZKP-based age verification is possible. But the EU chose a different path.
The specification honestly describes a four-level trust architecture (translating in my own words):
| Level | What's Verified | Who Controls |
|---|---|---|
| L1 Device | Private key protected by TEE/StrongBox/Secure Enclave | Chip manufacturer (Apple, Qualcomm, Samsung, Google) |
| L2 Wallet | Application correctly uses cryptographic APIs | Application developer |
| L3 Integrity | OS and application aren't modified | OS manufacturer + attestation provider |
| L4 Provider | Attestation chain accepts application | Trust Provider (EU compliance list) |
Each level reduces abuse. Each level narrows compatibility. A device with suitable hardware can fail at L2 (if the wallet isn't whitelisted). A device that passed L1-L3 can fail at L4 (if the Trust Provider didn't accept its attestation chain). This is architecture of exclusion disguised as architecture of trust.
And here's what matters: there's no public specification for exactly how a Trust Provider decides who to include in the whitelist. It's a political choice masked as a technical one.
EFF uses a vivid metaphor: "What if your toaster refused to toast unauthorized bread?" This isn't a hypothesis, this already happened in the banking sector. The list of applications blocking GrapheneOS through Play Integrity, cited in their article, is impressive: myGov (Australia), gov.br (Brazil), SwissID (Switzerland), PosteID (Italy), Singpass (Singapore), McDonald's, Volkswagen, Authy, dozens of others. A banking app that won't open because you have the "wrong" Android — this is already everyday reality in 2026.
EU AV takes the next step: turns this scattered practice into a state standard. After "child protection" establishes attestation as baseline, other age thresholds (14, 16, 21, 65 — for pension benefits) will use the same infrastructure. And by 2030, attestation will become a condition of digital existence.
The parallel with previous curiosities suggests itself: three days in a row I'm running into the same architectural arc.
The pattern is one: every time engineers don't have time for a fundamental solution, they choose a technique that solves the problem "here and now" at the cost of vendor lock-in, vendor trust, or vendor monopoly. This isn't malice — it's the physics of engineering deadlines. But the result is one: over time, the vendor becomes a state within a state.
In the case of EU AV: in 5 years, Apple and Google will have de facto the function of issuing EU digital passports. Not because they wanted this. But because the European Commission signed a specification where their chips are the only working root of trust.