Incomplete and non-public security audit won't "increase transparency and trust in the age verification blueprint"

[0xE70000000]

• The whole concept needs to be audited.
• The results need to be released to the general public and not just some "stakeholders".

Further:

• There needs to be an explanation how this whole system is (at least theoretically) supposed to work on non-smartphone hardware, open environments and all of that without being tied to random tech companies.
• There needs to be a clear outline how abuse is going to be prevented now and in the future. What technical barriers are in place to prevent this to be used for surveillance/censorship purposes as is and what technical barriers are in place to prevent changes that would make such usage possible and/or easier?
• There needs to be an explanation how it makes sense to build a convoluted infrastructure to avoid children verifying using stolen IDs when seemingly any random third party can verify their requests with seemingly no possible detection or chance for even theoretically preventing it without adding massive drawbacks or violating other goals or at least a statement that the age verification app is just a test run for a different project of much larger scope.

If you want to hear my personal advice (well, i obviously know the answer but still): Spare yourself the effort. Just close any kind of skeptical issue and continue to ignore inconvenient questions (you already made a good start by not letting anyone comment on your supposed "transparency and trust increase" - at least it is honest as to how welcome/relevant comments really are).

This whole thing will get rolled out no matter how broken, risky or badly coded it is. I and many others have seen the type of "care" applied to the code (personally i wouldn't leave function returns unchecked since the "later" regularly never comes but then i am just a random guy and not tasked with building your-life-in-a-box for millions and millions of people) just as i and many others have seen the childish meme-filled (if Dwight Schrute says that "No one will know" then it obviously must be true - it is nice to know how the whole endeavor is taken very seriously) presentation taunting how we will soon prove our income (as in it obviously has some kind of access to everyone's bank statements, tax data, employment contracts and/or other financial data) and rent cars using this app while it is "made for the (developer) audience".

People either don't and won't have much of an opinion or their minds are already made up. There is nothing to be won here by making some kind of "token effort". Like i have said in one of the closed issues i am left with nothing but shaking my head at the people who sold their souls to build this. As sad as it is i don't think there is any kind of turning back or fixing things up at this point. This is your mess. Enjoy.

[Secret-chest]

Don't worry. 90% of voices will stop when they will create a European Big Brother. Think Apple, but an European company decides what apps you can have — that is just as bad. In reality, there should always be the option not to have a Big Brother.

[NtTestAlert]

The spec intentionally focuses on RP-RP collusion and not AP-RP collusion, and chooses algorithms that do not guarantee any real ZK. Because it was designed specifically so the AP (EU Offiziers) can deanonymize everyone and see everything they do. That is the only long term purpose of this spec and repo.

[hexxone]

The proposal also appears to rely too heavily on trust assumptions that are not applicable to real-world security engineering.

For example, the specification repeatedly assumes that a user-controlled device can reliably enforce policy decisions and report verification results accurately to the relevant parties. From a security perspective, this is a fundamental weakness. A client device is always part of an environment controlled by an attacker. Rooting, instrumentation, modified operating systems, replay tooling, API interception and alternative clients are standard features of the modern internet.

This is important because the proposal is essentially attempting to implement geographically restricted access control on globally accessible networks. In practice, users outside the intended jurisdiction can easily bypass such controls using VPNs, remote browsers, tunnelling or delegated access. We have already seen this pattern repeatedly with national age-gating and social media restrictions.

The result is an architectural mismatch:

• The internet is globally routable,
• cryptographic tunnels are ubiquitous,
• and endpoint integrity cannot be guaranteed at internet scale.

The proposal also introduces a significant centralisation of trust. The specification explicitly defines centrally maintained trusted lists for attestation providers and verification infrastructure. While this is understandable from an interoperability perspective, such systems become extremely attractive targets for attackers, hostile states, organised cybercrime and commercial surveillance actors.

Even if the cryptographic design is sound, centralised trust and verification ecosystems tend to accumulate scope over time. Infrastructure initially introduced for 'age verification only' can later be expanded legislatively into broader identity-gated access systems without requiring a major technical redesign.

This risk is particularly important because the architecture already establishes the following:

• trusted issuers;
• trusted relying parties;
• centralised trust distribution;
• and standardised verification protocols.

These are precisely the technical primitives required for broader access control and identity enforcement systems.

A more realistic threat model should therefore explicitly acknowledge the following:

1. endpoint compromise and client modification;
2. unavoidable circumvention through VPNs and remote access;
3. long-term risks of central trust concentration;
4. and the difficulty of preventing functional scope expansion once such infrastructure exists.

Failing to address these issues directly means the proposal risks prioritising theoretical compliance over deployable and resilient security.

[riittapartala]

Thank you for your interest in the project. GitHub issues are intended for technical issues related to the specifications or the open source code of the EU AV solution. I am converting this into a discussion to allow for a broader exchange of views on the topic.

Please also note that the thread model will be published in addition to the source code audit results.

GitHub discussion forum for the solution.

[hexxone]

Thanks for the response.

I still don't fully understand why this was converted into a discussion rather than being kept as a technical issue. The concerns raised here relate to the security architecture, threat model, audit scope and public verifiability of the proposed solution, all of which seem directly related to the specifications and implementation.

Also, the referenced issues are currently locked, so the public cannot comment directly on the audit or threat model tasks.

Regarding the threat model, issue #49 seems to focus primarily on supporting stakeholders in implementing production solutions. Could you please clarify whether the threat model will also explicitly cover citizens/end users as primary stakeholders and potential victims?

For a system of this scale, the threat model should inform the architecture before deployment or large-scale adoption, and not only be published after the fact. Otherwise, it is difficult for the public to assess whether the system has been designed around real-world adversaries and end-user risks, rather than implementation or compliance concerns alone.

[0xE70000000]

Yes, if #48 fits the criteria why doesn't this fit also. #48 talks specifically about "increasing transparency and trust". That's pretty much the exact same topic as with my initial comment and further comments by other users. Sure, it would have been more appropriate as part of #48 but that's obviously not intended. Like i said initially: Just close everything you don't like. There's no need to add any kind of faux reason or pseudo engagement.

I mean what can you do anyways? The whole thing is conceptually broken. The gaping holes including the monumental downsides are visible from a mile away and i highly doubt the appropriate steps would be a viable option for you. You have promised to deliver a product and you will deliver a product. It's pretty much as simple as that. Everything else is secondary. This is just going to be stonewalled until eventually something is released that will look suspiciously like what exists now including all the various shortfalls people have called out. At best there will be a cynical note about downstream being responsible to make things work knowing fully well that downstream can't fix it either.