127
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Nov 2024
127 points (99.2% liked)
Programming
17672 readers
36 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
Not a cryptographic expert by any means but maybe something like this would work. This'd be implemented in common places people shop: supermarkets for instance. You'd go up to customer service and show your ID for visual confirmation only; no records can be created. In return the service rep would give you a list of randomised GUIDs against which the only permissible record can be "has been taken". Each time you need to prove your age you'd feed in one of those GUIDs.
this is an actual answer which is therefore interesting
Sadly, this type of scheme suffers from: 1) repudiation, and 2) transferability. An ideal system would be non-repudiable, meaning that when a GUID is used, it is unmistakably an action that could only be undertaken by the age-verified person. But a GUID cannot guarantee that, since it's easy enough for an adult to start selling their valid GUIDs online to the highest bidder en-masse. And being a simple string, it can easily and confidentially be transferred to the buyer, so that no one but those two would know that the transaction actually took place, or which GUID was passed along.
As a general rule, when complex questions arise which might possibly be solved by encryption, it's fairly safe to assume that expert cryptographers have already looked at the problem and that no easy or obvious solution exists. That's not to say that cryptographers must never be questioned, but that the field is complicated enough that incomplete answers abound.
IMO, the other comments have it right: there does not exist a general solution to validate age without also compromising anonymity or revealing one's identity to someone. And that alone is already a privacy compromise.
You upload identity to a site and it gives you a date stamped token which confirms your age.
Then when that token is uploaded to an SM site, it verfies the identity of the giver with the site that gives the token. The identity is a hash generated by the token site and contained in both the token and a namespace at the token site, so only the token site knows the real identity. Once the token has been confirmed, the namespace is re-used.
So you can't really sell the token, because its linked back to the identity you uploaded to the token site. You need to be logged in to the token site.
To make sure we're all on the same page, this proposal involves creating an account with a service provider, then uploading some sort of preexisting, established proof-of-identity (eg passport data page), and then requesting a token against that account. The token is timestamped and non-fungible, so that when the token is presented to an age-restricted website, that website can query the service provider to verify that: 1) the token is still valid, 2) the person associated with the token is at least a certain age.
If I understood that correctly, what you're describing is an account service combined with an identity service, which could achieve the objectives of a proof-of-age service, but does not minimize privacy complications. And we already have account services of varying degrees and complexity: Google Accounts, OAuth, etc. Basically any service where you log-in, since the point of logging in is to associate to a account, although one person can have multiple accounts. Passing around tokens isn't strictly necessary since you can just ask the user to prove account ownership by signing into their Google Account, for example. An account service need not necessarily verify age, eg signing in to post a comment on a news article.
Compare this with an identity service like ID.me, which provide records on an individual; there cannot be multiple records for the same live person. This type of service is distinct from an account service, but some accounts are necessarily tied to a single identity, such as online banking. But apart from KYC regulations or filing one's taxes online, an identity service isn't required for most day to day activities, and any additional uses pose identify theft concerns.
Proof-of-age -- as I understand it from the Australian legislation -- does not necessarily demand an identity service be used to satisfy the law, but the question in this Lemmy thread is whether that's a distinction without a difference. We don't want to be checking identities if we don't have to, for privacy and identity theft reasons.
In short, can a person be uniquely, anonymously age-verified online? I suspect not. Your proposal might be reasonable for an identity service, but does not move us further towards a theoretical privacy-centric proof-of-age validation mechanism. If such a mechanism doesn't exist, then the Australian legislation would be mandating identity checks for subject websites, which then become targets for the holder of those identity records. This would be bad.
To be certain the list isn't being handed out willy nilly, your id must be scanned, that will be kept for auditing purposes. If only 10 guids can be given at a time, this is the only way, plus it identifies ids used too often.
And I can guarantee any powers that bee will turn this into a service like stupid id.me where you create an account for guid access