No Stupid Questions
No such thing. Ask away!
!nostupidquestions is a community dedicated to being helpful and answering each others' questions on various topics.
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must be legitimate questions. All post titles must include a question.
All posts must be legitimate questions, and all post titles must include a question. Questions that are joke or trolling questions, memes, song lyrics as title, etc. are not allowed here. See Rule 6 for all exceptions.
Rule 2- Your question subject cannot be illegal or NSFW material.
Your question subject cannot be illegal or NSFW material. You will be warned first, banned second.
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Questions which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding META posts and joke questions.
Provided it is about the community itself, you may post non-question posts using the [META] tag on your post title.
On fridays, you are allowed to post meme and troll questions, on the condition that it's in text format only, and conforms with our other rules. These posts MUST include the [NSQ Friday] tag in their title.
If you post a serious question on friday and are looking only for legitimate answers, then please include the [Serious] tag on your post. Irrelevant replies will then be removed by moderators.
Rule 7- You can't intentionally annoy, mock, or harass other members.
If you intentionally annoy, mock, harass, or discriminate against any individual member, you will be removed.
Likewise, if you are a member, sympathiser or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people, and you were provably vocal about your hate, then you will be banned on sight.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- Majority of bots aren't allowed to participate here. This includes using AI responses and summaries.
Credits
Our breathtaking icon was bestowed upon us by @Cevilia!
The greatest banner of all time: by @TheOneWithTheHair!
view the rest of the comments
In principle it should be possible to do a zero-knowledge proof.
This means that the website asking for age verification asks a yes/no question like "Is this user 18+?" and the age verification service (like a digital ID provided by the government or whatever) answers "yes" or "no" accordingly, but without telling anything else about the user. Also, the verification service should ideally not know who asked for the age verification.
So the site you want to visit only knows the thing they need to know: Whether you are 18+ or not. Nothing else. And the age verification service only knows somebody asked for age verification and provided the answer, but do not know which site you visited.
This is all possible, but I don't have high hopes this is the intended implementation of any government seeking age verification, so don't get your hopes up.
The one who asked the verification service also shouldn't know who the verification service is, imho.
I'm not sure that is feasible, because in order to trust the answer, I feel the asker must know and trust the one providing the answer. It sounds like you're imagining a system with many different ID providers? What prevents me from creating my own provider that just answers "Yes", even for people under 18? If the site asking does not know it is my fake ID service providing the answer, I'm not sure they can trust any answer.
But I won't pretend to be an expert on this topic, so perhaps it is feasible somehow.
This is possible if there's a central authority for that that everyone can agree to trust, like the government records directly. The issue is ensuring the rest of the chain remains anonymous so the only thing the authority gets is the request that an undisclosed service is verifying John Doe is 18+ and nothing else. And that's not something many governments are going to want to allow with the increasingly alarming amount of authoritarian leadership.
There are some pretty strong arguments that even zk proof is a flawed way of preserving privacy though, in a variety of ways. It prevents pseudonymity by enabling one-user-one-account, and it leaves users vulnerable to being coerced to reveal their full online activities by handing over cryptographic keys.
Got ready to read some bullshit,
Vitalik Buterin
nevermind. But damn, what a great read. I haven't given much thought to on-chain ID in years and he lays it out pretty well. Still sounds like encrypted tokens are the way to go, but we all need to have multiple forms for it to protect anonymity.
If there's one person who knows their applied zk proofs, it's that guy.
Not monero or zcash devs?
I worked in this field for 3 years, a lot of the core parts are written, but there are a few key pieces missing and no one has taken it to real production.
You can use a passport in pretty much any country and prove you're over a certain age. Here is a demo: https://github.com/dog-18/dog18
The parts that are missing are primarily around making secure nullifiers, which prevents someone from reusing identities, but also without revealing any private information. We were pursuing research that allowed nullifier generation in MPC where none of the servers or the users knew the "salt" that their identity was hashed with, so no one could recover the original piece of unique data (like their passport number, even if a govt had a hunch about which passports signed up to a service) but it would also prevent them from signing up with multiple accounts. We got our funding cut pretty bad and management was a mess, so I left and that research I think was shut down. This really is the key part to actually make that viable in the real world though. It's maybe a year worth of research and a year worth of production left to make that practical.
Does that mean the government sees all the sites I've visited?
No, that's what I wrote as well. The identity service would not know what sites were visited or ideally not even how many sites were visited.
Indeed, technologically it is absolutely possible in multiple ways.
But the tempting possibilities of doing more than that are just too great.
doesn't this just raise the authentication requirements? like in the uk we got added checks for who was could work, and lots of deliveroo drivers shared the login + password of someone they knew who was verified.
You could make it single-use tokens and rate limit individual users when they request too many tokens in a short time. Someone could still share their tokens with a friend, but it doesn't scale to where thousands are verifying with some stranger's id.
I think it should be easy to identify when an account is being shared. For example if it's used from different ip addresses within a short amount of time