Hacker News Reader

Comment by jlokier | Hacker News Reader

> But the only way to do this is to require ID checks, effectively regulating and destroying the anonymous nature of the internet

That seems intuitive, but it's not actually true. I suggest looking up zero-knowledge proofs.

Using modern cryptography, it is easy to send a machine-generated proof to your social media provider that your government-provided ID says your age is ≥ 16, without revealing anything else about you to the service provider (not even your age), and without having to communicate with the government either.

The government doesn't learn which web sites you visit, and the web sites don't learn anything about you other than you are certified to be age ≥ 16. The proofs are unique to each site, so web sites can't use them to collude with each other.

That kind of "smart ID" doesn't have to be with the government, although that's often a natural starting point for ID information. There are methods which do the same based on a consensus of people and entities that know you, for example. That might be better from a human rights perspective, given how many people do not have citizenship rights.

> (and probably unconstitutional under the First Amendment, to boot.)

If it would be unconstitutional to require identity-revealing or age-revealing ID checks for social media, that's all the more reason to investigate modern technical solutions we have to those problems.

View on HN

It'd be cool if any of the proposed bills actually suggested something like this. They do not. They specify an ID check.

I'm not a cryptographer so I might miss something but I have the impression that

- either a stolen card can be reused thousands of time meaning that it's so easy to get a fake that it's not worth the implementation cost

- either there is away to uniquely identify a card and then it becomes another identifier like tracking ids.

It would be neat if some authority like the passport office or social security office also provided a virtual ID that includes the features OP described and allowed specific individual attributes to be shared or not shared, revoked any time, much like when you authenticate a 3rd party app to gmail or etc.

These are the things that the post office should be handling.

Putting on my conspiracy hat for a minute: They don't want to make it easy for you to authenticate anonymously. They obtain their surveillance data from the companies that tie you, individually, to your data. They'd be shooting themselves in the feet.

Yeah, hell no.

Assuming you can make active queries to the verifier, you could do something like

- Have your backend generate a temporary AES key, and create a request to the verifier saying "please encrypt a response using AES key A indicating that the user coming from ip X.Y.Z.W is over 16". Encrypt it with a known public key for the verifier. Save the temporary AES key to the user's session store.

- Hand that request to the user, who hands it to the verifier. The verifier authenticates the user and gives them the encrypted okay response.

- User gives the response back to your backend.

Potentially the user could still get someone to auth for them, but it'd at least have to be coming from the same IP address that the user tried to use to log into the service. The verifier could become suspicious if it sees lots of requests for the same user coming from different IP addresses, and the service would become suspicious if it saw lots of users verifying from the same IP address, so reselling wouldn't work. You could still find an over-16 friend and have them authenticate you without raising suspicions though, much like you can find an over-21 friend to buy you beer and cigarettes.

Since you use a different key with each user request, the verifier can't identify the requesting service. Both the service and the verifier know the user's IP, so that's not sensitive. If you used this scheme for over-16 vs. over-18 vs. over-21 services, the verifier does learn what level of service you are trying to access (i.e. are you buying alcohol, looking at porn, or signing up for social media). Harmonizing all age-restricted vices to a single age of majority can mitigate that. Or, you could choose to reveal the age bucket to the service instead of the verifier by having the verifier always send back the maximum bucket you qualify for instead of the service asking whether the user is in a specific bucket.

There is no way my 94-year-old neighbor can successfully do any of that.

That's the protocol for the computer, similar to oauth. From the user perspective, your 94-year-old neighbor would have an account with id.gov that they've somehow previously established (potentially the DMV or the post office does this for them), and the user flow works much like "Sign in with Google" buttons do today.

If you can make active queries to the verifier, so can any adversarial party. These kinds of ZK-with-oracle schemes need to be very carefully gamed to ensure they're truly ZK, and not just "you learn nothing if you only query once."

> and the service would become suspicious if it saw lots of users verifying from the same IP address

This implodes under CGNAT, cafe internet, hotel internet, etc.

You can make active queries, with the user's involvement. The verifier can potentially have a prompt with e.g. "The site you were just on would like to know that you are over 21. Would you like to share that with them?"

We do need to get people onto ipv6 so CGNAT can die. Restricted services could potentially disallow signups or require more knowledge (e.g. full ID) if coming from shared IPs as a risk mitigation strategy, depending on how liable we want to hold them to properly validate age. If you've already signed up for facebook at home, obviously you don't need to validate your age again at the cafe.

Fake IDs exist in the real world. The system doesn't have to be perfect, and we can say that there's some standard of reasonable verification that they should do for these sorts of cases.

Personally I'm more in favor of an approach where sites label their content in a way where parents can configure filters (ideally using labels that are descriptive enough that we don't get into fights over what's "adult", and instead leave that decision to individual families), but if we're going to go an ID-based route, there are at least more private ways we could do it, and I think technologists should be discussing that, and perhaps someone at one of these big companies can propose it.

Addendum: you can actually preserve the privacy of which bucket the user is in to all parties if this is sufficiently standardized that it goes through a browser API.

- Have the service generate the request as above, but now the request is "Please encrypt a response with key A for the user coming from ip X.Y.Z.W".

- Service calls a standard browser API with the request, telling the browser it would like to know the user is in the over 16 bucket. Browser prompts the user to verify that they want to let the service know they are over 16. Browser sends the request to the verifier.

- Verifier responds with a token for each bucket the user is in. So a 22 year old gets an over-16 token, an over-18 token, and an over-21 token.

- Browser selects the appropriate response token and gives it back to the service.

So the service only ever learns you are over the age limit they care about, and the verifier only ever learns that you asked for some token, but not which one.

mDL wide scale rollout works be using the trusted computing element that is part of your phone and enrollment would be the same as obtaining a driver’s license in the first place.

There is no physical card - there is an attestation that only an enrolled device can hand out with revocation support in case of security flaws.

Is it going to be absolutely secure? No. The cost just needs to be high enough that it becomes inaccessible to the vast majority of adolescents.

Theft of your parents phone becomes a lot easier attack vector but phone biometrics/password requirements will thwart that for most parents.

This doesn’t need to be 100% fool proof.

You can also use fake ID to buy booze.

Making it illegal is, by itself, enough to discourage a lot.

Those need some kind of face to face interaction. The perceived risk of being caught is much higher.

You can't run for loop on buying booze with fake id.

There's a unique identifier, but it's your secret and can't be used for tracking. Sites needing verification don't learn anything except that you "have" a token matching the condition they are checking. This includes not learning your unique identifier, so they can't use it for tracking. The issuer also doesn't learn anything about your verification queries.

You have an incentive to keep the secret token to yourself, and would probably use existing mechanisms for that: You might manage like your phone number, private email and other personal accounts today. Not perfect, but effective most of the time for most people.

You might decide to share it with someone you trust, like your sibling. That's up to you, but you wouldn't share it widely or with people you don't trust, even under pressure, because:

To prevent mass reuse of stolen tokens, it's possible to use more cryptography to detect when the same token is reused in too many places, either on the same site or across many sites, without revealing tokens that don't meet the mass-reuse condition, so they still can't be used for tracking. If mass-reused tokens auto-revoke, they can't be reused thousands of times by anyone, and that also provides an incentive to avoid sharing with people you don't trust.

I won't pretend this is trivial. It's fairly advanced stuff. But the components exist these days. The last paragraph above requires combining zero-knowledge proofs (ZKP) with other branches of modern cryptography, called multi-party computation (MPC) and perhaps fully homomorphic encryption (FHE).

I dont want government crapware on my device to access the internet.

I also dont want third party crapware on my device to access the internet.

"wowee it can be done without revealing my identity to anyone but the government or the corp running the chain"

No thanks

Identity is not revealed.

Do you think the NSA would balk at that challenge?

It doesn't have to be based on crypto designed by NSA, does it?

Design is far from the only threat vector. Any implementation that is less than perfect is prone to all kinds of attacks. A few years ago, there was a report that the NSA could decrypt a double-digit percentage of encrypted web traffic thanks to a larger-than-expected bag of factored primes they keep handy.

Great story, are you claiming that NSA can infer from zero-knowledge proofs inputs, maybe map cryptographic hashes to plain input text or something of that nature?

No, but I bet a dollar that NSA isn't just going to collectively fold hands and say "These schemes and implementations are too good and too secure for us to break. We'll ignore the meta data, network analysis, side channels and our data centers that can store 2 days worth of internet traffic; we'll give up and focus on defensive security only"

Your argument applies equally to any initiative ever made by humans that mentions "internet". Yet it appears quite few things exist on the "internet". We do have cryptography with good guarantees available.

My argument is not that those things don't exist - its just that to my knowledge, I never heard of any real-life implementation that's guaranteed to be NSA-proof[1] - you're welcome to offer a counterexample.

1. Your fancy encryption scheme is pointless if your plaintext can be acquired at either endpoints, of if a bug in the implementation leaks data. The security of the whole matters a lot more than the individual parts as attackers go for the weakest link.

You're not transmitting sensitive information in the first place.

You very obviously have to reveal your identity to some party or other, otherwise 12 year olds wont be excluded.

Let me expand on this because Digital Identity proponents tend to try and oversimplify everything and then act surprised when their favorite cryptos implode.

There are 2 situations.

1. Everyone who wants to access restricted content needs to access a government or corporate tool to generate their wallet or keys or whatever you want to call it.

2. Everyone in the jurisdiction is required to sign up for the tool.

1. Is effectively putting yourself on a list for future fascist governments to purge.

2. Is an onerous burden on the entire population. We had enough issues with Digital TV.

Government already has all information about you, they put on your passport when they print it for you. Zero knowledge proofs allow you to generate attestation about some facts (ie that you are above 21 years) where 3rd party can verify it, where proof itself doesn’t reveal your identity or any other information - just the fact that you’re passing this check is revealed.

Yes and you can consider the passport office a list of everyone who wants to travel overseas.

Ditto, if you apply for internet porn license, you will be on a list of internet porn enthusiasts. Its non trivial information that its largely in your best interest not to provide the government.

Again this all happens before your zero knowledge check.

There is no porn enthusiasts list.

To access your fav porn site, you provide claim that you're above 21 that porn site is able to verify.

There is no link revealed between your identity and porn. There are no lists.

Zero-knowledge focuses precisely around this fact of not revealing extra information.

> The government doesn't learn which web sites you visit, and the web sites don't learn anything about you other than you are certified to be age ≥ 16.

If the zero-knowledge proof doesn't communicate anything other than the result of an age check, then the trivial exploit is for 1 person to upload an ID to the internet and every kid everywhere to use it.

It's not sufficient to check if someone has access to an ID where the age is over a threshold. Implementing a 1:1 linkage of real world ID to social media account closes the loophole where people borrow, steal, or duplicate IDs to bypass the check.

As I mentioned elsewhere, you’re falling for letting perfect be the enemy of good. The ZKP + phone biometrics only needs to raise the cost of bypass above what adolescents have access to. And no, you can’t just share the same ID because there’s revocation support in the mDL and it’s difficult to extract the raw data once it’s stored on the trusted element. This is very similar to how credit cards on phones work which are generally very difficult to steal.

Sorry, you’re not thinking like a group of 15 year olds trying to get online.

The revocation list means nothing when they can get ahold of someone’s older sibling’s ID and sign up for social media.

Did everyone just forget what it’s like to an ambitious kid who wants to get online?

Do people really think a platform that needs people to jump through these hoops and use this imaginary international ID architecture is feasible?

Does anyone really think that kids won’t just set their location to Estonia and/or use a VPN to circumvent all of this?

This. The parties that this will detriment are all older people. Kids will simply bypass it.

You’re thinking like a group of technically proficient 15 year olds and their friends. That’s a small minority. The vast majority of teens are likely to be stymied.

Revocations are not for the individual ID but if an exploit is found compromising the IDs stored on a trusted element. Your older siblings ID can’t be used to sign for millions of accounts - just those who the older sibling lets borrow their phone that has their ID (and assuming there isn’t some kind of uniqueness cookie that can be used to prevent multiple accounts under a single ID). That’s a much different and more manageable problem (fake ids via older siblings have been a thing for forever).

>As I mentioned elsewhere, you’re falling for letting perfect be the enemy of good

No, this line of reasoning deserves nothing but absolute contempt when it comes to laws. We are not talking about getting the finnicky API to work at your job. Too often laws have had unintended consequences as a result of loopholes or small peculiarities. If the damn law doesn't even work on a fundamental level then it should be opposed on principle.

You’ve just described literally every single law. Congrats. You’re now appreciating what it’s like to live in a law-based society.

It don't have to be perfect, but it need to have some way to do spot checks.

If there is no risk involved, everyone will jump on doing it.

There are technical methods to detect and revoke large-scale reuse of an uploaded id. I wrote more detail in another comment.

That only covers large-scale reuse. It doesn't cover lending your id to your younger sibling if you want to, or if they find a way. Maybe that should be acceptable anyway. Same as you can lend your phone or computer to someone to use "as you", or you can buy them cigarettes and alcohol. Your responsibility.

A super interesting example of this is the proof-of-passport project.

https://github.com/zk-passport/proof-of-passport

Today you can scan your passport with your phone, and get enough digitally signed material chained up to nation level passport authorities to prove anything derived from the information on your passport.

You could prove to an arbitrary verifier that you have a US passport, that your first name starts with the letter F, and that you were born in July before 1970, and literally share zero other information.

The selective disclosure is super cool, I wonder how it works since smthing like a hash of DG1 is what is actually signed, how can you selectively disclose verified data from "inside" the hashed area? It does not sound very feasible to me but I am not an expert in zk-snarks etc.

There are some wrinkles that prevent passport data being used more broadly - technically it is a TOS violation to verify passports / use the ICAO pkd without explicit permission from ICAO or by direct agreement with the passport holder's CSCA (country signing certificate authority). Some CSCAs allow open use but many do not.

Also, without being too pedantic about it, what you are able to prove is more like possession of a document. An rfid passport (or rfid dump & mrz) - or in fact any kind of identity document - does not prove that you are the subject - you need some kind of biometric bind for that.

ZK circuts have gotten really fancy lately, to the point where full blown ZK virtual machines are a thing, which means you can write a program in rust or whatever, compile it to riscv, and then run it on the risc zero zkVM. (https://github.com/risc0)

This means you can literally just write a rust program that reads in the private data, verifies the signature, reads the first byte in the name string and confirms that it matches what you expect, and then after everything looks good, it returns "true", otherwise it returns "false". This all would happen on your phone when you scan a QR code or something that makes the request, then you send the validity proof you generated to the verifier, they can see that the output was true, and nothing else.

In theory, the private data would be stored on a trusted device you own, like your phone or something, so someone who steals your phone would have a hard time using your identity. Using fancy blockchain stuff you could even to a one time registration of your passport such that even if someone steals your passport, they wouldn't be able to import as a usable ZK credential. Presumably there would be some logic around it so you can re-register after a delay period or something, giving the current credential holder a chance to revoke new enrollment requests or whatever. So, yes, proving your exact identity to a website isn't perfect, but it's easy enough to make it really noisy if someone is trying to tamper with your identity, and maybe that's good enough.

If you want to go the trusted hardware route, you could make someone take a picture of their face with some sort of trusted hardware camera on their phone or laptop, and then use some zkml magic to make sure it kinda looks like the face on the passport data. Given the right resources, trusted hardware is never that hard to tamper with, so I don't like that solution very much.

What's often more important in an online context is that your credential is unique. It doesn't matter who you are, it matters that you've never used this credential to sign up for a twitter account, or get past a cloudflare captcha, or any other captcha use case. If you steal 10 passports, maybe you can set up a bot that will automatically vote for something 10 times, but at least you can't vote millions of times. This is sybil resistance, and it's massively important for a ton of things.

Thanks! I have a big rabbit hole to go down now :)

I don't get what causes the proof to fail if I provide the wrong bytes to the zkvm when it tries to read from inside the hashed area after the hash & signature are verified (this might not be directly sequential I guess, I think it has to be part of the same proof).

Put another way, I get we have to zk prove that a) I know a message M that hashes to H ... (can see this is do-able from googling), but also that a particular byte range M[A-B] is part of M, in a way that the verifier can trust I'm not lying and I don't see how the second bit is accomplished. It feels like there are also details in proving that the data comes from the right "field" in the DG1.

This stuff is such black magic! EDIT: will try this out in ZoKrates...

> Using modern cryptography, it is easy to send a machine-generated proof to your social media provider that your government-provided ID says your age is ≥ 16, without revealing anything else about you to the service provider (not even your age), and without having to communicate with the government either.

There's just one problem. How does the machine proving your age know that you are who you say you are? Modern cryptography doesn't have any tools whatsoever that can prove anything about the real body currently operating the machine--it can never have such a tool. And the closest thing that people can think of to a solution is "biometrics," which immediately raises lots of privacy concerns.

> the closest thing that people can think of to a solution is "biometrics," which immediately raises lots of privacy concerns.

Is using FaceID a privacy concern? This mechanism can be built into phones much like passkeys.

> I suggest looking up zero-knowledge proofs.

Sure, but is the Florida legislature actually looking into stuff like this?

Why would they, when it is not in the governments interest?

The government need not know what sites you visit. It is damaging enough that the government know that you are visiting sites that require an age verification. You can then be flagged for parallel construction if you should, I don't know, start a rival political party.

Not if this were widespread. I wouldn’t be too bothered if the government knew that I either watched an R-rated movie or rented a car or purchased alcohol or created a Facebook account.

Now do need an abortion or sought out gender affirming care. Today’s “no big deal” can become tomorrow’s privacy nightmare.

You missed the either in GP's comment. i.e. they know you did one of those things because you requested an over-18 token, but not which one. The more covered activities there are, the more uncertainty they have about why you might have asked for a token.

This isn't really my area of expertise, is there a way to know for sure that those are all the same token? Or could the government just lie and say they are all the same when in reality they can really differentiate.

The government would have to document the API for requesting tokens for anyone to use it. I suggested a scheme here[0] where it's clear that the government doesn't get any information about the service (unless the service re-uses AES keys) and the service doesn't get any information about the user other than whether they're in the appropriate age group.

Potentially there could be coordination between .gov and the service to track users by having each side store the temporary AES key and reconcile out-of-band. But .gov has other ways they could get that information anyway if they have cooperation from businesses (e.g. asking your ISP for your IP address, and asking the service provider for a list of user IPs).

[0] https://news.ycombinator.com/item?id=39183486

Definitely, we can use a government issued id, or we can create our own. Social graphs i call em. Zero knowledge proofs have so many ground breaking applications. I have made a comment in the past, relevant to how could a social graph be build, without the need of any government [1]. We can create effectively one million new governments to compete with existing ones.

[1] https://news.ycombinator.com/item?id=36421679

Governments monopolize violence. At least at the foundational level. When too many of them compete at once it can get very messy very quickly.

Let's suppose that 1 million new governments are founded, and violence still can be enforced only by the existing ones. The new governments will be in charge of ids, signatures, property ownership and reputation. Governments of Rust programmers, or Python programmers, or football players, or pool players, or truck drivers will be created.

When a citizen of Rust programmers social graph uploads code, he can prove his citizenship via his id. We may not even know his name, but he can prove his citizenship. He can sign his code via his signature, even pull request in other projects. He can prove his ownership of an IT company, as it's CEO, the stock shares and what not. And he will be tied to a reputation system, so when a supply attack happens, his reputation will be tainted. Other citizens of Rust's social graph, will be able to single out the id of the developer, and future code from him will be rejected, as well as code from non-citizens.

Speaking of supply chains, how about the king of supply chains of products and physical goods? By transferring products around, in a more trustworthy way, by random people tied to reputation, Amazon may get a little bit of competition ain't it?

see also an older comment of mine https://news.ycombinator.com/item?id=38800744

Government is not the correct word to use for this idea.

Allright, social graphs then. I use social graphs and e-gov interchangeably, but social graphs might be better.

I've been thinking a lot lately about decentralized moderation.

All we need to do is replace the word "moderate" with "curate". Everything else is an attestation.

We don't really need a blockchain, either. Attestations can be asserted by a web of trust. Simply choose a curator (or collection of curators) to trust, and you're done.

Yeah, blockchain is not needed at all. A computer savvy sheriff might do it, an official person of some kind. Or even private companies, see also "Fido alliance".

Additionally the map of governments which accept Esthonian passport might be of some relevancy here[1].

[1] https://passports.io/programs/EE1

But in reality this would not hide age, for example if a child signs up for Facebook, the only information revealed is that they are <16 years old. But once they turn 16, they want to have an unrestricted Facebook experience, so they will send a new token to Facebook, showing that they are older then 16 now. Facebook can now record the day the user does this and will now know the approximate birthday of a person. Sure, the user might not do this right on their birthday, probably in a span of a few weeks, but they will still have a good understanding of the age. This system would still be better then having to reveal your whole Id with all details.

You can send a proof that someone's government-provided ID says that their age is ≥ 16.

That's not enough proof to levy a requirement.

So I hash some combination of ID, name and birthday and send it to Facebook to create an account. Facebook relays that hashed info to a government server which responds with a binary yes/no.

Of course you need to trust that the hash is not reversable.

That doesn’t stop kids from using Facebook, but it stops kids’ ID from being used to create an account.

Thanks for bringing this solution up. Many people are unaware of Zero-Knowledge proofs are actually possible. Probably because it's very counter intuitive.

And as with electronic voting, the contract will go to the lowest bidder with the worst security, not the company that's got the CS chops to do it right.

We did a hackathon at work and one of the guys from one of my project teams covered this stuff as his project.

I trust that it _would_ work 100%,but what I don't trust is that a government would implement it properly and securely, because no government works like that lmao (even NZ's great one).

I mean living in the UK now I got like a dozen different fucking gov numbers for all manner of things, dvla, NHS, nin, other tax numbers, visa, etc...why isn't there just one number or identity. Gov.uk sites are mostly pretty stellar besides.

Reply on news.ycombinator.com