Age verification and privacy: avoiding an Ashley Madison scenario

Age verification and privacy: avoiding an Ashley Madison scenario

There's been a lot of talk recently about the plans to introduce a government-backed age verification system for adult content in the UK. Concerns - quite reasonable concerns - are flying around that the creation of such a system would, by definition, result in a list of 'deviants' which might be abused by an increasingly totalitarian government.

I agree with these concerns. I think the age verification system is ineffective and unnecessary. Firstly, unless we end up with a China-style Great Firewall scenario, they'll only apply to content produced in the UK, which just means consumers will seek out content produced elsewhere. Secondly, instead of trying to fight tooth and nail to block out something which humankind has sought out forever, we should be addressing the nature of the harm done by adult content with increased and mandatory full-spectrum sex and relationship education.

Even so, it seems pragmatism might (yet again) take a backseat, and we might end up with an age verification system anyway because it makes good tabloid headlines and will win votes among the conservative-leaning population.

If we must have such a system, let's look at ways to attenuate its risks whilst preserving its functionality. To do that, we need to break down the flow of information between users and organisations.

Let's define some terms first.

Naming of Parts

PII: "Personally Identifiable Information". Sensitive information which must be safeguarded, such as a User's full name, home address, date of birth, etc.

User: A person who wants to use or subscribe to a Website, and to do so must prove to the Website that they are over 18 years of age. Colloquially, "you".

Website: A content provider which sells or provides content to Users, but needs to ensure that those Users are over 18 years of age. Colloquially, "a porn site".

AVS: "Age Verification System". An organisation which is trusted by Users and Governments to attest to the age of a User. May be a part of Government, but treated seperately here for the sake of clarity.

Government: A governing body which has mandated that qualifying Websites must verify Users are over 18 years of age before they are allowed access to their content. Governments hold PII for all humans who might be Users, including their date of birth and thus their age.

Token: A randomly generated chunk of data which can be used to maintain state. If I issue you a token, and someone later presents that token back to me, I might assume that the unknown person who presented the token is the same person to whom the token was issued.

Certificate: A chunk of data which has been cryptographically signed by an AVS. Such a signature allows a third party to verify that the data has not been modified by anyone but the signer without needing to communicate with the signer to perform verification. Certificates also include issuance and expiry timestamps, allowing them to be valid only for a set period of time. This data is also signed and immutable by anyone but the signer.

Approaches

In the following diagrams, which depict a sequence of events, time runs from top to bottom.

Weak anonymity, weak security

sequenceDiagram participant User participant Website participant AVS participant Government User->>+Website: User's PII Website->>+AVS: User's PII AVS->>+Government: User's PII Government-->>-AVS: PII verify response AVS-->>-Website: PII verify response Website-->>-User: Yes/no response

Pros

  • Simple and intuitive process.

Cons

  • All entities receive the user's PII, increasing the risk of unauthorised disclosure.
  • At least AVS, but possibly Government too, can associate a human with a list of the Websites they use.

Weak anonymity, strong security

sequenceDiagram participant User participant Website participant AVS participant Government User->>+AVS: User's PII AVS->>+Government: User's PII Government-->>-AVS: PII verify response AVS-->>-User: Token User->>+Website: Token Website->>+AVS: Token verify request AVS-->>-Website: Token verify response Website-->>-User: Yes/no response

Pros

  • User's PII is never sent to Website, avoiding a significant potential point of unauthorised disclosure. User does not even have to give Website their real name, unless required for billing purposes.

Cons

  • Increased complexity - User must know that they need to get a token separately to signing up.
  • At least AVS, but possibly Government too, can associate a human with a list of the Websites they use.

Strong anonymity, strong security

sequenceDiagram participant User participant Website participant AVS participant Government User->>+AVS: User's PII + certificate request AVS->>+Government: User's PII Government-->>-AVS: PII verify response Note over AVS: Build certificate response if PII is valid AVS-->>-User: Certificate response Note over User: Build final certificate from request and signed response Note over User: Store final certificate User->>+Website: Certificate Note over Website: Verify certificate validity Website-->>-User: Yes/no response

Pros

  • User's PII is sent to the bare minimum of destinations, and only once per signed token validity period.
  • AVS is not involved when Websites check the Certificate, so has no way to associate a human with a list of Websites they use.
  • AVS can revoke compromised or erroneous Certificates using existing standards (CRL, OCSP) without compromising User's identity as long as Certificates are built using a random Token as the identifying factor ("Common Name").

Cons

  • Further complexity. Even with automation, a User needs to understand the process to some degree.

Building the best system

As we've seen in the final diagram, we can have an AVS while still respecting privacy. With a sensible validity period - a year or so would be reasonable - the only thing the AVS or Government knows is that a particular human has requested a certificate at some point.

The even better news is that a system like this isn't anything new or cutting-edge. It's a slight variation on the way the existing SSL/TLS infrastructure works for securing web, email, and other Internet traffic. Whenever you see a tickmark or padlock next to a website name, your browser has verified the server's certificate is signed by a list of certificate authorities that the browser trusts.

This is feasible.

Actually getting the best system

To make this happen, we need to apply pressure. Few Governments have ever willingly chosen to collect less information about their citizens when given half a chance. In an ideal world this whole idea would be abandoned, but if we are going to be stuck with it, we need to use technology to reduce its impact as much as possible.

Support your local privacy activists. Organisations like the Open Rights Group and Backlash UK, along with individuals like Myles Jackman and Pandora Blake are doing fantastic work. If nothing else, write to your MP online for free. We need informed Members to bring up the technical options, and we all know that Parliament's general technical understanding is horribly limited.

And, of course, if you're working on this and want to bring me on board to help build the system, my contracting rates are quite reasonable.

Dave Williams

Dave Williams

https://dave.io

View Comments
Navigation