EFF launches Age Verification Hub

> If we have to know that you're not a minor, then we also have to know who you are

That is untrue

Are you aware of any age verification systems that do not have this property?

(This includes being robust against law enforcement action, legal or otherwise.)

How about:

https://blog.google/technology/safety-security/opening-up-ze...

Like many mention in other comments on this post, it's possible to implement using ZKPs. There are likely other methods that would be effective without compromising privacy. None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification.

When I say "if we have to know you're not a kid, we have to know who you are" I'm not stating an actual truth, but the argument as it is playing out politically.

> None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification.

The EU age verification solution says implementations SHOULD implement[1] their ZKP protocol[2]. Not linking it to the user is stated as an explicit goal:

Unlinkability: The goal of the solution is to prevent user profiling and tracking by avoiding linkable transactions. Initially, the solution will rely on batch issuance to protect users from colluding RPs. Zero-Knowledge Proof (ZKP) mechanisms will be considered to offer protection. More details are provided in Section 7.

[1]: https://ageverification.dev/av-doc-technical-specification/d...

[2]: https://ageverification.dev/av-doc-technical-specification/d...

1) Large social media companies know you better than your friends. That has been known for 10 years and they're way better now: https://www.nytimes.com/2015/01/20/science/facebook-knows-yo...

2) Cigarette vending machines accept VISA cards and government IDs and they're offline.

3) A medium-sized social media network required photos (not scans) of GovIDs, where only year of birth and validity date need to visible. The rest could be blacked out physically.

4) You can guess users' age and only request solid proof only for those you are unsure about.

The problem is that we technical users think of a one-size-fits-all technical approach that works, without a single fail, for all global users. That is bound to fail.

It is only a law and you can break it big time or small time. Reddit's approach might proof way too weak, it'll be fined and given a year to improve. Others might leave the market. Others will be too strict and struggle to get users. Others might have weak enforcement and keep a low profile forever. Others will start small, below the radar and explode in popularity and then enforcement will have to improve.

You can also request identity and then delete it. (Yes, some will fail to delete and get hacked.)

Giving Facebook a free pass is stupid. They're selling your age cohort "10-11" within 0.0037ms for 0.$0003 to the highest bidder on their ad platform.

> the argument as it is playing out politically.

The law does not mandate identity, so your argument does not hold.

Cool trick to tie in the libertarian idea of protecting yourself from legally sanctioned government actions.

If privacy is an explicit goal, why isn't it a MUST? Why even bother with the initial batch issuance phase? And what's stopping them from silently adopting a batch size of 1?

> Are you aware of any age verification systems that do not have this property?

As I understand it, it's the goal of OpenID4VP[1][2]. Using it a site can request to know if the user is over 18 say, and the user can return proof of just that one claim, I'm over 18, without sharing identifying information.

The new EU age verification solution[3] builds on this for example.

[1]: https://openid.net/specs/openid-4-verifiable-presentations-1...

[2]: https://docs.walt.id/concepts/data-exchange-protocols/openid...

[3]: https://ageverification.dev/

Is there a good explanation of how ZKPs prevent attestation providers (which presumably know your identity) from linking an issued proof back to you if, for example, the website elects to store it? I can wrap my head around RSA and ECC and PKI, but I haven't managed to make sense of this yet.

Assuming that's even a goal, of course. The cited paragraph mentions RPs (the websites, from what I understand), but makes no mention of attestation providers.

Can't read the specs at the moment, but what prevents the age verification service and the age-gated website from coluding and de-anonymizing your porn use?

Okay but then if a ZKP solution is presented, that's calling their bluff. They now have one less excuse for surveillance.

EDIT: Actually do one better - tell them that for 16+ websites, you're actually protecting teenagers by keeping them anonymous.

Yeah, getting into the car with the guy holding the gun doesn't become okay because you have a great argument you're waiting to use down the road. He's already got the gun out.

We should have started arguing when he just said he had a gun, indoors, in the crowd. We shouldn't have quietly walked outside at his demand. But that all happened. Here we are now, at the car, and he's got the gun out, and he's saying "get in", and we're probably not going to win from here -- but pal, it's time to start arguing. Or better yet, fighting back hard.

Because that car isn't going anywhere we want to be. We absolutely can not get in the car right now, and just plan to argue the point later. It doesn't matter how right the argument is at all.

This is, of course, very technical, but here is how it works at a high level.

In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly.

The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...

Haven't either had time to fully wrap my head around the details.

At least in the EU solution they say there would be multiple attestation serivices the user could choose to use. So that would be technically better than nothing.

The thing is that as far as I can tell, a ZKP of age involves a state or similar attestor to issue an ID/waller that can be querried for age without revealing identity.

But attestor has to have certainty about the age of the person it issues IDs to. That raises obvious questions.

What states are going to accept private attestors? What states are going accept other states as attestors? What state won't start using its issues ID/Wallet for any purpose it sees fit?

This system seems likely to devolve national Internets only populated by those IDs. That can all happen with ZKPs not being broken.

That is how states work.

If it's not linked to an identity, why can't a kid use a parent's key?

the more I think about it, the more I feel like I need someone with deep knowledge to explain ZKPs to me.

So like, we've got this algorithm that gets sent our way and we run it and that provides kind of a cryptographic hash or whatever. But if we're running the algorithm ourselves what's to stop us from lying? Where does the 'proof' come from? What's the check that it's running and why do we inherently trust the source it's checking?

Excellent question. More generally, what prevents me from copying the credential and giving it to somebody else?

The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware.

In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware.

How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model.

In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.

So adults are required to own a phone to prove their age?

Can I log into an age gated service at a library without a phone?

I am someone with "deep knowledge", but HN is not the proper place for this discussion. See https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.htm... for the gory details.

Here is a hopefully simple example of how this ZKP thing may even be possible. Imagine that you give me a Sudoku puzzle. I solve it, and then I want to prove to you that I have solved it without telling you the solution. It sounds impossible, but here is one way to do it. I compute the solution. I randomly scramble the digits 1-9 and I put the scrambled solution in a 9x9 array of lock boxes on a table. I have the keys to the 81 locks but I am not giving you the key yet. You randomly ask me to open either 1) one random row chosen by you; 2) one random column chosen by you; 3) one random 3x3 block chosen by you; or 4) the cells corresponding to the original puzzle you posed to me. In total you have 28 possibilities, and assume that you choose them with equal probability. You tell me what you want and I open the corresponding lockboxes. You verify that the opened lock boxes are consistent with me knowing a solution, e.g. all numbers in a row are distinct, the 3x3 block consists of distinct numbers, etc. If I am cheating, then at least one of your 28 choices will be inconsistent, and you catch me with probability 1/28, so if we repeat this game 1000 times, and I don't know the solution, you will catch me with probability at least 1-(1/28)^1000 which is effectively 1. However, every time we repeat the game, I pick a different random scrambling of the integers 1-9, so you don't learn anything about the solution.

All of ZKP is a fancy way to 1) encode arbitrary computations in this sort of protocol, and 2) amplify the probability of success via clever error-correction tricks.

The other thing you need to know is that the protocol I described requires interaction (I lock the boxes and you tell me which ones to open), but there is a way to remove the interaction. Observe that in the Sudoku game above, all you are doing is flipping random coins and sending them to me. Of course you cannot let me pick the random coins, but if we agree that the random coins are just the SHA256 hash of what I told you, or something else similarly unpredictable, then you will be convinced of the proof even if the "coins" are something that I compute myself by using SHA256. This is called the "Fiat-Shamir transformation".

How do we implement the lock boxes? I tell you SHA256(NONCE, VALUE) where the NONCE is chosen by me. Given the hash you cannot compute VALUE. To open the lock box, I tell you NONCE and VALUE, which you believe under the assumption that I cannot find a collision in SHA256.

Another excellent question. The current answer in the EU seems to be "you need a phone". My preferred answer (despite being one of the Google guys who designed the ZKP mechanism) would be that the government sends you some sort of plastic card with a chip that does not tie you to a phone. Still fighting that battle.

I think a parent should be able to give their kid access if they deem their kid mature enough. If the kid can handle social media without it becoming an addiction or a self-esteem issue or similar, then it would generally be a net positive. For example, social media may include YouTube which has a lot of educational content. Why hold the kid back?

GNU Taler has an age-verification extension.

To make this more concrete: There are a lot of "legally sanctioned" government actions happening in the US right now that are pretty dubious. That includes digging up old laws and giving them spicy new interpretations that legal experts agree are an abuse of power and not in the intent of the original law.

Some of these are getting batted down by judges, so right now the category of "legal" is especially vague. That's why I phrased it like that.

But also, we see cops just straight up stalking people using government tools. So that's another reason to be concerned about "legal" government actions.

Nothing to do with libertarianism.

Sure it's possible, but are there implementations in use that meet this criterion?

Because if there aren't, then it matters substantially less whether they're possible.

I have one: https://news.ycombinator.com/item?id=46223051

> How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France).

Are you saying that someone goes to city hall, shows ID, and gets a DOCUMENT that certifies age, but doesn't link back to the person's identity? And it's married to a fingerprint in front of the person checking ID?

Is there a limit on how many times someone can get a DOCUMENT? If not, it'll become a new variation of fake id and eventually there's going to be an effort to crack down on misuse. If yes, what happens if I get unlucky and lose / break my phone limit + 1 times? Do I get locked out of the world? The only way I can imagine limiting abuse and collateral damage at the same time is to link an identity to a DOCUMENT somehow which makes the whole ZKP thing moot.

I'd be more worried about the politics though. There's no way any government on the planet is going to keep a system like that limited to simple age verification. Eventually there's going to be enough pretense to expand the system and block "non-compliant" sites. Why not use the same DOCUMENT to prove age to buy beer? Sanity for guns? Loyalty for food?

What happens if the proof gets flipped to run the other direction and a DOCUMENT is needed to prove you're a certified journalist? Any sources without certification can be blocked and the ZKP aspect doesn't matter at that point because getting the DOCUMENT will be risky if you're a dissenter. Maybe there's an interview. Maybe there's a background check. Has your phone ever shown up near a protest?

It's just like the Android announcement that developers need to identify themselves to distribute apps, even via side loading. The ultimate goal is to force anyone publishing content to identify themselves because then it's possible to use the government and legal system to crush dissenting views.

Big tech caused most of the problems and now they're going to provide the solution with more technology, more cost, and less freedom which is basically what they've been doing for the last 2 decades so it's not a surprise.

I’m not exactly sure about ZKPs but for age verification the “proof” can come from the government but in such a way that the web service doesn’t know anything more than whether an assertion is true, and the government doesn’t know anything more than you wanted to verify some assertion.

This is a simplified method for age verification:

I want to buy alcohol from my phone and need to prove I’m over 18. SickBooze.com asks me for proof by generating a request to assert “age >= 18”.

My phone signs this request with my own private key, and forwards it to the government server.

The government verifies my signature against a public key I previously submitted to them, checks my age data in their own register of residents, and finally signs the request with one of their private keys.

My phone receives the signed response and forwards it back to SickBooze.com, which can verify the government’s signature offline against a cached list of public keys. Now they can sell me alcohol.

- the “request” itself is anonymous and doesn’t contain any identifying information unless that is what you intended to verify

- the government doesn’t know what service I used, nor why I used it, they only know that I needed to verify an assertion about my age

- the web service I used doesn’t know my identity, they don’t even know my exact age, they just know that an assertion about being >= 18 is true.

Thanks for answering, I appreciate it.

> How do we implement the lock boxes? I tell you SHA256(NONCE, VALUE) where the NONCE is chosen by me. Given the hash you cannot compute VALUE. To open the lock box, I tell you NONCE and VALUE, which you believe under the assumption that I cannot find a collision in SHA256.

That's the bit I was missing! The prover pre-registers the scrambled solution, so they can't cheat by making up values that fit the constraints.

Excellent, clear example.

I would throw in Privacy Pass [1], just in case the government and SickBooze.com can exchange info.

Sadly, it‘s still hard to explain how exactly it works, but conceptually simpler than arbitrary ZKPs.

[1]: https://privacypass.github.io/

> the government [...] only know[s] that I needed to verify an assertion about my age

This is problematic if a majority of things needing age verification are looked down upon; for example, insurance companies would love to know what people don't do things needing age and therefore don't buy alcohol (at least not online).

> Why even bother with the initial batch issuance phase?

This is a solution that requires non-trivial interaction between many paries.

It seems very reasonable to want to get the parties started on the implementation so they can iron out issues in the infrastructure they're building while they work on the details of the ZKP aspects.

One thing to keep in mind when reading about any "ZKP protocol" is that on its own the term has the same inherent vagueness as "end-to-end encrypted" - especially when like here there are more than two parties concerned to solve a single verification.

What information is not disclosed to whom? In what way is it ZK?

One example is Googles "zero-knowledge age verification" where AFAICT, Google still has full insight into all the sensitive data and metadata. It's not like they inherently need to be the designated middleman but that is how the scheme is designed. Therefore I find it ingeniously marketed. A bit like saying "Facebook Messenger protects all your messages with end-to-end encryption", which is arguably technically true but misleading and not an honest statement.

The simplest possible such method? Single-use age verification codes, generated and validated by the government, sold on physical scratch cards with in-store verification of ID, piggybacking on the infrastructure we already use for selling alcohol and cigarettes.

This would be far easier to implement for websites too. You'd just have a single, unauthenticated API endpoint which, given a code, tells you if the code is valid (and marks it as used). Integrating with such an API is about 1 day of work for a competent dev. Even open, non-profit platforms like Mastodon could easily implement such a mechanism.

Scratch cards wouldn't have to be the only way of getting such codes. THe vast majority of people could just generate them in their banking app or whatever (which would still be far more privacy friendly than the current ID verification mechanisms).

The first question is how would the insurance find out that you are doing lots of things requiring age verification? The only body that could tell them is the government, while a distrust in the government can be healthy, I think this is the least thing to worry about, the government typically knows already much more damaging things than how often you ask for age verification.

Moreover, that would only work if there are relatively few things that require age verification and it needs more than just being looked down upon, i.e. while alcohol buying might be interesting information for insurances, watching porn is likely less interesting. Even worse, if the insurance can't distinguish between porn and alcohol (which they can't by design even if the government would give them the information about how often you ask for age verification).

I somewhat understand your argument about how to prevent misuse, but I'd say one could do that by embedding the key in an ID card and someone will have to connect the ID card to the phone/computer (e.g. via NFC). So obviously you can pretend you lost your ID card and get a new one, but I would say that you can only do that so often until someone will get suspicious, just as if you would ask for a new passport every couple of months someone would start asking you some serious questions.

Regarding using the document to buy beer, that's already done, you need to provide ID. I also hope you being asked to provide ID for buying guns, but then again I'm not from the US, so I have quite a different opinion on gun ownership.

All that said though, we are currently watching some of the most significant civil rights abuses by authorities, all without any ID system and people are worried about age verification? If the government wants to abuse their power they don't need an ID system, they just look at your social media profile at the border.

I guess owning some computer should be fine as a requirement? It just should not be tied to the US megacorps. A web app perhaps?

You may be confusing the UKOSA (which is about surveillance) with the concept of age verification more generally.

> same inherent vagueness as "end-to-end encrypted"

Recent HN discussion example: How Kohler Inc. has a toilet feces analysis camera with "end to end encrypted", except they're one of the ends so it is deceptive advertising.

https://news.ycombinator.com/item?id=46129476

> Eventually there's going to be enough pretense to expand the system and block "non-compliant" sites. Why not use the same DOCUMENT to prove age to buy beer? Sanity for guns? Loyalty for food?

You're not wrong to be concerned about those impulses, but I think this is getting into "perfect is the enemy of good" territory.

A really authoritarian government isn't going to make an effort to misuse the system that way: They'll tear it down entirely and go back to worse-alternatives which we already use, where they do know all parties involved and exactly when and what was being checked.