Comment by spwa4
8 hours ago
> Not if you use a challenge-response protocol where the client returns a zero-knowledge proof of age, where the proof incorporates a random string sent by the website.
Obviously it does. These $1 per-day apps are 24/7 online and so challenges can simply be proxied just the same as tokens.
> ... law enforcement has local access to the minor's hardware ...
This is a large part of what people, in practice, want to prevent using this scheme.
> Once you've been revoked, you have to go through the hassle of setting this all up again, which might be enough incentive to keep it reasonably secure ...
States want to know who to punish when this happens. Which also details how this is defeated: you can't revoke the token, because that makes getting a conviction near-impossible and it exposes the states to counterclaims.
The people who install such forwarding apps don't have money for the court to charge, and they can't take away their identification apps (which these will be, obviously) because that's the cheapest way for states to communicate with them.
Unless you build this into the base layer of the internet (which European networks like minitel did, by the way, with France telecom graciously checking it for free. Free for the state, of course. YOU paid per packet)
> ... to keep it reasonably secure ...
Oh and "reasonably secure" won't cut it. Someone committed suicide after a message was posted, and they're "reasonably secure" who it came from? You see the problem, I hope.
Are you saying such proxying apps exist now? Can you link a source for me?
Regarding my scheme:
The only way law enforcement should have access is if they show up and get the phone in their possession, with a warrant. Which could happen any time some teenager posts something without realizing it identifies them.
If the teenager has your full credentials, that's when law enforcement sees who you are, and can take whatever action we deem appropriate. I would think just revocation if you might have been hacked, more severe if it's clear you shared on purpose. Revoking credentials doesn't interfere with the person using the app for other purposes, or with any prosecution, and criminal prosecution doesn't rely on the perp having money; quite the opposite in fact.
If you install a proxying app for the challenge-response, you're installing an untrustworthy app from a criminal to take payment for a criminal scheme, with risk of prosecution if that criminal gets caught.
Nothing in society is perfectly secure. There are all sorts of ways that we allow some crimes and tragedies to happen because we know that preventing them would be even worse. There are good reasons that courts have long protected privacy and anonymous speech, even though we could solve more crimes without those protections.
> The only way law enforcement should have access is if they show up and get the phone in their possession, with a warrant. Which could happen any time some teenager posts something without realizing it identifies them.
It’s beyond crazy that we’re actually talking about police showing up at someone’s house because they suspect a social media post came from an under-18.
This is one step away from your local government unmasking their Internet critics and sending police to their house by “suspecting” that they might actually be a minor.
> If the teenager has your full credentials, that's when law enforcement sees who you are, and can take whatever action we deem appropriate. I would think just revocation if you might have been hacked, more severe if it's clear you shared on purpose.
Why would you assume the person giving out the token is in the same jurisdiction? The tokens would almost certainly be coming from another country.
The police aren’t going to be tracking down teens, confiscating their phones, running forensic analyses, and then doing the work of getting tokens revoked through a possibly international process. They barely have enough time to show up and take a report when someone does minor physical proper damage.
All this does is open up the process for targeted abuse when governments or police need an excuse to go after someone posting on social media.
But ... you were arguing method X prevents this from "They become a traceable identity token". And what are you going to do with the anonymous tokens? You'll identify whose credentials they are ...
If you can identify physical hardware from a request or post, obviously it's not anonymous. In fact, if you can identify the owner of credentials from the credentials, they're not anonymous. Obviously in an actual anonymous system it is utterly impossible to do this, whoever you are.
So you've just proven your own argument wrong. Anonymous age verification online is impossible. You don't agree?
No, you don't look up the token. You check a zero-knowledge proof.
The way this works is, there's a function with both public and private inputs, and an output. You can send me public inputs, and I can pass those plus my private inputs into the function, and give you the function output, along with a proof that the output is correct given your inputs.
So in this case, the government has a public key, which it uses to sign your credentials, consisting of your birthdate and a unique identifier.
The website sends you a large random number.
The public inputs are the government public key, the random number, today's date, and maybe a revocation list of identifiers.
The private data is my unique identifier and birth date.
The function returns true if my calculated age > 18, the government's signature of my data is valid, my private identifier is not on the public revocation list, and (to avoid replays) that the hash of your random number is not zero.
I send you back the generated proof, which is just a 256-bit number. You can check that the proof is correct without looking anything up. The proof does not give you any way to reconstruct my private data. It is only associated with the random number you gave me, and the public data everyone knows.
To keep the revocation list from growing forever, we could also make credentials expire after some period of time. Add an issue date to the private data, and we can add an expiration check to the function. Client software can automatically get a new credential if the old one is valid, expiration is just to allow us to delete old identifiers from the revocation list.
A hole in the above scheme is that government could try redoing proofs for a given random number, using all the current identifiers. To prevent this, the user passes in another random number as private data, and the function checks that that doesn't hash to zero either. User can change that random number every time, its only function is to change the generated proof to something the government can't replicate.