HN Debrief

European digital ID wallets rely on safety services of Google and Apple

  • Privacy
  • Regulation
  • Security
  • Europe
  • Infrastructure

The article says European digital ID wallets are being built in a way that leans on Google and Apple safety and attestation services, especially on mobile, which turns a public identity layer into infrastructure controlled by two US platform companies. In plain terms, the concern is not just that iPhone and Android dominate smartphones. It is that access to state-backed identity, age checks, and other public services can end up gated by platform trust systems that citizens do not control and that alternative operating systems often cannot pass.

If you ship anything that depends on government identity or age checks, plan now for non-phone and non-Google/Apple fallback paths. The immediate pressure point is policy and procurement, because once attestation gets baked into public services it becomes much harder to unwind than to stop upfront.

Discussion mood

Strongly negative. People saw the design as a sovereignty failure, an anticompetitive gift to Google and Apple, and a civil-liberties problem because remote attestation lets public services decide which devices and operating systems citizens are allowed to use.

Key insights

  1. 01

    GrapheneOS support would not fix lock-in

    Allowlisting GrapheneOS sounds like an escape hatch, but it barely changes the structure of control. Android key attestation is still rooted in hardware vendor certificate chains, so on a Pixel it is still Google-backed attestation that merely recognizes GrapheneOS AVB keys. That means one custom ROM on one approved device can pass, while other ROMs, self-built variants, and other hardware still fail. The policy question stays exactly the same. Who gets to decide which citizen devices are legitimate enough for public services.

    Do not treat “supports GrapheneOS” as a meaningful interoperability win in procurement or standards work. Ask whether the system accepts user-controlled devices in general, not whether it has a short allowlist of exceptional cases.

      Attribution:
    • Retr0id #1
    • hmlwilliams #1
    • seba_dos1 #1
  2. 02

    The EU framework leaves room for alternatives

    The reference implementation is influential, but it is not the law. Several commenters pointed out that wallet providers can choose different implementations and that the EUDI framework already contemplates smart cards and standalone hardware tokens, while EU rules forbid making a smartphone mandatory for public services. The catch is obvious. If those alternatives are optional rather than mandatory, many countries will skip them and the mobile-first design becomes the real default.

    Focus advocacy on making physical and cross-platform options mandatory, not merely permitted. In government tech, optional alternatives usually disappear under delivery pressure and app-store convenience.

      Attribution:
    • u1hcw9nx #1
    • layer8 #1
    • chatmasta #1
    • deaux #1
  3. 03

    Use national ID cards as trust anchors

    A more defensible architecture is to let the physical ID card do the sensitive cryptographic work and use the phone as a dumb relay for routine interaction. Smartcard chips already keep the signing logic and keys on the card, which shrinks the trusted computing base dramatically compared with a full mobile operating system. That does not remove every phishing or man-in-the-middle risk, but it avoids making Apple or Google the arbiter of whether your phone is acceptable for civic identity.

    For high-stakes signatures and onboarding, prefer designs where the credential lives on a card or token and the app is replaceable. That gives you a path to support desktops, alternative phones, and future devices without rewriting the identity model.

      Attribution:
    • lxgr #1 #2
    • okanat #1
    • LelouBil #1
  4. 04

    Privacy claims depend on verifier design

    Several people noted that selective disclosure and age-only proofs do not automatically make the system anonymous in practice. One commenter explained that the current style of design can avoid verifier-to-verifier tracking by using batches of single-use tokens, but the issuer may still be able to link tokens back to a person. Another warned that verifier endpoints and timing data can still create logs that are useful for surveillance. The protocol details decide whether “over 18” actually behaves like a private attribute check or like a state-observed event.

    If you evaluate digital identity products, ask for a concrete unlinkability story and for data-flow diagrams, not just buzzwords like ZKP or selective disclosure. Privacy breaks at the issuer and verifier layers long before the cryptography looks weak.

      Attribution:
    • ulrikrasmussen #1 #2
    • 28304283409234 #1
  5. 05

    The exclusion problem is broader than hobbyist ROMs

    The practical risk is not limited to privacy enthusiasts running GrapheneOS. Commenters pointed out that any citizen using e/OS, Huawei devices without Google Play, Linux phones, or no smartphone at all can get pushed into a second-class path. Once digital ID becomes the preferred or only realistic way to access services, “there is still a fallback” stops meaning much if the fallback is slow, obscure, or incomplete.

    When you hear that a service is “not mandatory,” check whether the alternative is equally usable in speed, coverage, and cost. Accessibility failures in identity systems usually show up as degraded service long before they show up as formal exclusion.

      Attribution:
    • ulrikrasmussen #1
    • ralferoo #1
    • edukite #1

Against the grain

  1. 01

    Governments are outsourcing hard security work

    A minority view said the mobile platform dependency is not just laziness or capture. Building secure, accessible identity systems across millions of citizens is expensive, especially once you include anti-fraud systems, account recovery, accessibility, support, and the cost of lost devices. From that angle, Google and Apple are being used because they already provide the security and operational scaffolding that governments have failed to build themselves.

    If you argue for a sovereign alternative, include the operating model, support burden, and recovery workflow. A proposal that only replaces attestation without replacing mass-scale support will lose to the duopoly on delivery risk.

      Attribution:
    • spwa4 #1
    • nradov #1
  2. 02

    Remote attestation has legitimate uses

    Not everyone accepted the blanket claim that attestation is inherently bad. A few commenters argued it can be useful when it serves the device owner or when it proves that a remote service is running audited code inside a secure enclave. GrapheneOS Auditor was cited as an example of owner-directed attestation. That does not rescue the public-ID design here, but it weakens the idea that all attestation is automatically abusive.

    Separate “attestation as a primitive” from “attestation as a gatekeeper for civic services.” You can reject the current policy without arguing that every use of attestation is illegitimate.

      Attribution:
    • jt2190 #1
    • Retr0id #1
    • microtonal #1
  3. 03

    The EU may want compliant platforms, not sovereignty

    A more cynical reading flipped the sovereignty argument on its head. Instead of treating Google and Apple dependency as a mistake, these comments suggested policymakers may prefer tightly controlled app-store ecosystems because those ecosystems are easier to regulate, easier to pressure, and easier to turn into enforcement points for future rules. Another reply pushed back that the real controller is still Apple, Google, and by extension the US, not Brussels.

    Watch for whether future policy fights target dependency itself or merely demand more leverage over gatekeepers. Those lead to very different end states for users and for independent software.

      Attribution:
    • nickslaughter02 #1
    • sam_lowry_ #1
    • 71bw #1

In plain english

Android Hardware Attestation
An Android mechanism that uses hardware-backed keys to prove information about a device and its verified boot state.
AVB
Android Verified Boot, the Android security chain that verifies software during startup.
e/OS
An Android-based mobile operating system that aims to reduce dependence on Google services.
EUDI
European Digital Identity, the European Union framework for digital identity credentials and wallets.
GrapheneOS
A privacy and security focused alternative Android operating system, mainly for Google Pixel devices.
Play Integrity
Google’s Android service that lets apps check whether a device, app, and operating environment meet Google’s integrity requirements.
remote attestation
A way for a device to prove to a remote service what software or hardware state it is running, so the service can decide whether to trust it.
secure enclave
A separate hardware security processor that stores keys and performs sensitive operations apart from the main operating system.

Reference links

EU identity specifications and implementation

Attestation and alternative mobile platforms

Policy, enforcement, and advocacy

Related national identity systems and examples