←back to thread

347 points iamnothere | 8 comments | | HN request time: 0s | source | bottom

Also: We built a resource hub to fight back against age verification https://www.eff.org/deeplinks/2025/12/age-verification-comin...
Show context
pksebben ◴[] No.46236900[source]
This keeps coming up and we keep having the same debates about what Age Verification isn't.

For the folks in the back row:

Age Verification isn't about Kids or Censorship, It's about Surveillance

Age Verification isn't about Kids or Censorship, It's about Surveillance

Age Verification isn't about Kids or Censorship, It's about Surveillance

Without even reaching for my tinfoil hat, the strategy at work here is clear [0 1 2]. If we have to know that you're not a minor, then we also have to know who you are so we can make any techniques to obfuscate that illegal. By turning this from "keep an eye on your kids" to "prove you're not a kid" they've created the conditions to make privacy itself illegal.

VPNs are next. Then PGP. Then anything else that makes it hard for them to know who you are, what you say, and who you say it to.

Please, please don't fall into the trap and start discussing whether or not this is going to be effective to protect kids. It isn't, and that isn't the point.

0 https://www.eff.org/deeplinks/2025/11/lawmakers-want-ban-vpn...

1 https://www.techradar.com/vpn/vpn-privacy-security/vpn-usage...

2 https://hansard.parliament.uk/Lords/2025-09-15/debates/57714...

replies(14): >>46236954 #>>46237349 #>>46237480 #>>46238016 #>>46238148 #>>46238925 #>>46240138 #>>46240141 #>>46240546 #>>46240662 #>>46240975 #>>46241941 #>>46242412 #>>46243136 #
knallfrosch ◴[] No.46237349[source]
> If we have to know that you're not a minor, then we also have to know who you are

That is untrue

replies(1): >>46237429 #
phyzome ◴[] No.46237429[source]
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.)

replies(7): >>46237529 #>>46237535 #>>46237741 #>>46237759 #>>46237958 #>>46239717 #>>46240178 #
pksebben ◴[] No.46237535[source]
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.

replies(7): >>46237671 #>>46237758 #>>46238433 #>>46239088 #>>46240107 #>>46241986 #>>46242597 #
magicalhippo ◴[] No.46237671[source]
> 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...

replies(3): >>46237909 #>>46237981 #>>46241679 #
mzajc ◴[] No.46237981[source]
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.

replies(1): >>46238674 #
MatteoFrigo ◴[] No.46238674[source]
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, ...

replies(2): >>46239192 #>>46239356 #
1. pksebben ◴[] No.46239356[source]
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?

replies(2): >>46239546 #>>46240488 #
2. MatteoFrigo ◴[] No.46239546[source]
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.

replies(1): >>46240801 #
3. kahnclusions ◴[] No.46240488[source]
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.

replies(3): >>46240924 #>>46240968 #>>46241582 #
4. sdwr ◴[] No.46240801[source]
> 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.

5. shermanyo ◴[] No.46240924[source]
Excellent, clear example.
6. notpushkin ◴[] No.46240968[source]
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/

7. hunter2_ ◴[] No.46241582[source]
> 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).

replies(1): >>46242036 #
8. cycomanic ◴[] No.46242036{3}[source]
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).