Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can one verify age without giving away identity?


Yes, technical capability will ship in chrome https://developers.google.com/privacy-sandbox/protections/pr...


What do you think the odds are that someone will give you a state token attesting to you being 18+ and that the issuer won't keep a "paper trail" back to your identity so they can prove they did their due diligence?

I'll give you a hint. It's 0%.

The recurring theme in all these systems is that everything you do online can be tracked backed to your real world identity. What happens when all the major tech platforms require some kind of attestation to participate and publish information? Can you still criticize politicians and rich people after that?

At that point I'd rather just go to BestBuy and buy a "not a bot" card for $100 cash.


The insurance on what I linked is that the issuer cannot see who redeemed the token, so the issuer can’t link an individual to what sites they visited.


> The publisher site makes a request to the issuer to redeem the trust tokens.

They don't explain it very good because that makes it sound like they're asking the issuer to validate a token which implies the potential to correlate it to the user.

That whole scheme seems pretty bad IMO. It looks like it boils down to sites sharing trust data which means huge platforms are going to become the arbiters of who's good vs bad. Even if the system works well and sharing trust info reduces bots and bad actors, it's going to have a negative effect on new market entrants because it's likely they'll have to buy trust data rather than having some kind of peering arrangement.

It seems like big tech companies are hellbent on controlling every minute of our lives. It's disappointing.


Not exactly. You would still need to reveal yourself to the issuer. It only hides you from the consumer.


And it potentially locks out smaller browsers who might want to get started but who aren't on the approved age verification trust anchor list.


Yes, you can with cryptographic certificates.

App: https://certisfy.com/

Demo: https://youtu.be/92gu4mxHmTY

Happy to discuss.


This might hide identity from the person requesting the info, but not from the trusted authority. In theory the authority could collect data on where requests are coming from, or where the certs are used. To my knowledge, there's no way to completely hide identity while also verifying an attribute and ownership.


There are actually ideas using crypto to provide proof of properties without a trusted entity having to know what the proof will be used for, and without the requester of the proof being able to learn more about the identity. E.g. (in french) https://linc.cnil.fr/demonstrateur-du-mecanisme-de-verificat...

Now i think it is still either a dangerous slope, or it will end up inefficient, because of credential sharing; the typical modern idea to avoid that is to require the user to have a locked smartphone, wich is quite an intrusive requirement.


This is close. But I believe an attacker could use the signature to tie it back to a user if the gain access to the trusted authority information. There's no way to do it truly anonymously. Even the article recognized its pseudonymous.


It does hide identity from all parties except the party you decide to share your identity with.

Here's the technical details on how that is achieved: https://cipheredtrust.com/doc/#pki-id-anchoring


I don't see anything in that link explaining how one could verify age while remaining anonymous to all parties. How does one verify the age is correct and associated with the true person? It also seems the cert is for specific sites. So doesn't that mean the identity provider (trust anchor?) who verified the age now has a list of which sites you're using your certs on sinc eyou must define a reciever (recipient domain?)? Maybe you can explain the flow in an example?


>So doesn't that mean the identity provider (trust anchor?) who verified the age now has a list of which sites you're using your certs on sinc eyou must define a reciever (recipient domain?)? Maybe you can explain the flow in an example?

When a trust anchor does verification and issue you the certificate, you get a PEM file, their connection to the process is done. Yes they know who you are but can't track what you do with the certificate after they issue it to you.

On the other hand if you were to use that certificate to commit a crime, the signature will provide access to the trust chain, thus law enforcement could use it to find you by reaching out to the issuer. This is a feature not a bug, it combines privacy and accountability, no different from conventional non-digital world expectations.

The use of receiver id, happens after you have the certificate, the issuer is not involved. The receiver id is for the benefit of the receivers of signatures from your certificate, it allows them establish a sticky anonymous cryptographic identity for you without knowing who you are, this is a way again to have privacy while having accountability. This demo touches on the approach: https://www.youtube.com/watch?v=92gu4mxHmTY

Reach me via my profile if you're interested in knowing more.


Yeah, so the government can track you, and really anyone who gains access to the signature and trust chain can track you. The trust anchor also has to verify your identity to verify your age in order to issue the PEM file.

So to answer my original question - no, you can't anonymously verify age. Someone has to verify your identity (a central authority in my comment, which in your system is a trust anchor) and your signature can be tracked back to you (as a fearure).


I missed your concern about pure anonymity in the whole process, the answer is NO.

You can't have such a system that is totally anonymous, it is private but not anonymous. This means it is largely anonymous but for instance law enforcement might be able to track you down...I happen to think this is a good balance though I am sure not every one agrees.


It's not just law enforcement though. With the way the laws are today, you could have the trusted entity selling that data if they're partnered with some consumers. If you save the cert usage (on the consumer side) you could eventually utilize it if the trusted entity changes hands, policies change, etc. The government is also a potential malicious actor depending on which government and how you want to define malicious.

Of course there are other issues in the chain concerning anonymity, like ISPs.


Yes and no. You could prevent most people from accessing the identity and superfluous info including exact age, but that would require a trusted central authority to essentially provide a yes/no answer for a given age threshold.


Yes, if you use an intermediary service. The service verifies your identity, and then it provides an attestation about your age.


So the answer is "no", since you are still revealing your identity to the intermediary, and can not subsequently control how they use that information.


True, the answer is always going to be "no" depending on how hard-lined you are about privacy.

But with a few reasonable concessions, you can get a lot of benefit.

For instance, most people believe that the government itself be able to verify your identity, through birth certificates or passports or drivers licenses or tax IDs.

If you're willing to allow the government to verify your identity, how about a trusted private company that you get to select?

If that company is then trusted by others as an identity verifier, then although you may have to reveal your identity to one trusted entity, you don't have to reveal your identity to any of the others that accept their attestations about attributes like age.


There's an easy fix for that: use as an intermediary a service that already knows who you are.

Age verification should involve three parties: you ("the User"), the site that wants to know that you are past a certain age ("the Site"), and the service that actually checks your age by looking at your documents or whatever ("the Service").

Using protocols based on zero-knowledge proofs or blind signatures it is possible to design a protocol whereby (1) all that the Service learns when the User uses them to verify for some site is that the User has asked to verify for somebody but they don't know who, (2) all the Site learns is that the User passed the age check and used the Service to do it, and (3) someone how obtains complete logs of both the Site's age verification communications and the Service's age verification communications cannot figure out how to match them up except by timing.

To elaborate on matching records from the Site and the Service, if for example the Site only had one user sign up in the last month who used the Service for verification and the Service was only asked to participate in one verification that month then you can infer the User's identity.

If the Service is doing lots of verifications for a large number of sites, so during the few seconds that your signup or login at the Site is being processed at the Service there are dozens of other verifications also going on there involving dozens of other sites, then someone who gets records from the Site and the Service gets dozens of people who might have been the one who actually used the Site.

We can make it even harder for someone to match things up. First, we can add random delays between the the User initiating a signup at the Site and the User initiating verification with the Service and between the Service's finishing of that and the User using that result to complete signup. So now someone who obtains signup records from the Site and tries to use timing to match them up to users of the Service will need to look at Service records from a wider interval.

Second, the User's client can make random dummy verification requests at random times. That increases traffic to the Service which helps make it harder in general for timing analysis to work. It also makes it so if someone is trying to figure out who signed up at the Site on a specific time and they find you did a verification in the right timeframe and ask you what you were verifying for you can say you weren't...it must have been one of the random dummy verifications.

Third, there should only be a few providers of the ID checking side of this (the Service). It would probably make the most sense for this to be handled by government, probably be the same departments that issue the ID documents you will be using to prove identity. This helps ensure that they are dealing with a large number of verifications, which is the key to protection against timing attacks.


We could do the Leisure suit Larry style of age verification where it asks you questions only an 'adult' would know.


It would be fun to have a committee to decide--regularly, maybe even weekly--what sorts of timely questions should be asked to determine if someone's old enough to view porn. The meetings would be hilarious!

Everyone knows the classics like showing a picture of President Clinton at his desk and asking the question, "How many people are in this picture?" or show them a picture of a pager and ask, "what is this device?" but for such a committee it would actually be cutting edge research! They'd need to keep track of cultural influences that came and went on a weekly basis (or at least monthly).

"Meme Archivist" could actually be considered a respectable and lofty position in government!


That pretty much broke down the moment the internet was created and the answers to the questions were the first thing put online.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: