Recently the UK has enacted a law which requires websites to verify the age of users before certain types of content which might be harmful to children. Because "think of the children".[1]
Now while I may be in favour of restricting access to harmful content from the vulnerable, I'm not convinced
this isn't going to spread progressively to censor more topics, and it probably already is counterproductive in many cases. And it doesn't even help.
And fuck me, but websites are doing this in the most terrifying way possible, demanding things which no-one should be posting to the internet at random. Passport scans, banking details, photos of the user with their mouth open.
This is merely the proposal of a technical system which would ameliorate the situation, but understand I don't think the law is a good one.
A big part of the problem is that you need to deal with every website independently.
A trusted third party could help with this, but it needs to be private as far as possible. I don't want to give my personal details to practically every website I use.
And it needs to be less gameable than at least the current median strategy (which to be fair is apparently often really bad).
So I am proposing a system which will verify you once, and then authenticate your individual website accounts without necessarily knowing what they are.
It works like this:
1) User authenticates themselves once with this business. Unfortunately there's no getting around this. There will probably be a small charge required. Potentially it requires a video call or something to be beyond reproach. But at least it can all happen 'locally' - there's no need to send data abroad.
Also, personal information is not stored - only very basic account details are retained.
The system relies on the fact that once you are 'of age' - that is, over 18, this will be true forever.
Note - only one authentication account can be created per bank account. The business keeps track of 'used' cards in a Bloom filter or similar - a setup which can be tested to determine whether a set of banking details has (probably) been inserted, but can't output the details themselves - and also doesn't relate it to any specific account.
2) User creates an account, with a unique (and non-identifying) username, and inputs a pass phrase. Once set, these can not be changed. The user will need to keep hold of these.
3) Each website has a main domain. For example, for the halfbakery it is "halfbakery.com" In addition, it makes a short 'pepper' phrase publicly available. The user takes the domain name and pepper phrase and feeds them, along with their unique username and pass phrase to a small program which the age authentication service provides. This is a simple script (which could be written in e.g. javascript to be downloaded, verified and run offline by the paranoid) which generates a cryptographically secure hash.
4) To authenticate to a website, the user inputs this hash into a text field.
The website can request (and retain as desired) the authentication server's list, which is supplied pre-hashed (using the web domain and pepper phrase as well as service username and pass phrase), and is therefore anonymised.
If the user-supplied hash is present in the hash list, the user is authenticated. This information can be retained for all future authentication checks against that user.
The website is advised to restrict the authentication to a single account - that is, it may refuse duplicate hashes for multiple user accounts. This would obviously require retaining a list of authenticated hashes (or a Bloom filter record, or similar). This would be a good reason not to share authentication account details. However, it would also preclude alternate accounts. For this reason, the website may choose to provide a second (or multiple further) pepper phrases, which are generated and function for authentication supplied in the same manner.
In this manner, each individual website doesn't need to know anything about the user, only that they have previously been verified as over 18.
Furthermore, the authentication service doesn't know the users registered to any particular website.
The hashes are probably at least 256 bits, to avoid both hash collisions and to prevent randomly guessing an active hash code.
If a website is hacked and the list of authentication hashes stolen, the website changes its pepper phrase and revokes all existing authentications. All users would then need to re-authenticate. For this reason, websites may choose to re-hash the hash lists - and similarly hash the hashes users supply before comparison.
[1] I will henceforth call people who say this "paedophiles".