[fc417fc802]

Well it probably needs a bit more complexity to avoid being trivially broken. Codes are one time use; the service has them attested by the token provider behind the scenes, and the provider is in turn under contract with the government. Tokens are also activated at the point of purchase similar to gift cards in order to prevent bulk theft and resale. A law in the vein of HIPAA prevents collusion between the retail establishment and the token provider.

[palata]

People, you have to read about zero knowledge proofs. Look at e.g. Privacy Pass.

> A law in the vein of HIPAA prevents collusion

No need if you use cryptography. This thing that, you know, works well for encrypting stuff? Spoiler: it can be used for age verification.

[rstuart4133]

>> A law in the vein of HIPAA prevents collusion > > No need if you use cryptography.

True for age verification, but not true in general. If you have something that can be used illegally, it's very handy to allow firms to rent / hire it out anyway but make the hirer responsible for any illegal activity.

An example is hiring a car, and the car is used to ram-raid a shop. Today this is solved by handing over a government ID to the rental company. Commit a crime in the car and they hand that over to police, but it has the sad side effect of handing over information to the car rental they can use to track you, and worse sell to others.

Using a zero knowledge proof for a valid driver's licence fixes the privacy problem, but at the expense of the hire company not being able to transfer responsibility for illegal activity onto the hirer. I suspect if that happened no one would hire out cars any more.

You can easily design something that is Zero Knowledge to the car hire firm, but includes an opaque token they can hand over to the government on lawful demand. It contains all the details needed to pursue the law breaking hirer. Thus there is still a role for the law here - you can't always do everything with crypto.

This is a very minor quibble - I agree completely with what I think is your main point. This Google change is a privacy disaster. It's a step towards an enshittified internet with the gateways onto it controlled by a few big tech firms.

But I don't think just yelling "just use ZK" is helpful. It's much harder than that - ZK is only part of the puzzle. Passkeys are currently caught up in the same attestation trap, and there is no workable solution in the offing. Banks and other high trust applications need some assurance your FIDO private key is being handled securely. The solutions on the table are Apple not doing attestation, or Google who does at the low low price of selling your true name to Google. Both "solutions" suck, horribly.

ZK proofs of things like licences and age have to solve the attestation problem, and solve extra stuff as well. I'm not holding my breath.

[palata]

> But I don't think just yelling "just use ZK" is helpful.

Agreed. I am just very frustrated, because I feel it is an important topic. And I wish I saw adult discussions about it. And instead, people who claim to be "tech-savvy" keep whining about the fact that it will fundamentally leak their ID everywhere. Like they somehow understood the point for E2EE, and repeat it here confidently. If tech-savvy people can't be bothered to understand how this works, why should politicians?

I have the same frustration with the anti-5G crowd yelling that it will boil your blood. There are many valid reasons to criticise 5G and have a constructive debate, but they choose to be wrong anyway.

[rstuart4133]

> If tech-savvy people can't be bothered to understand how this works

You underestimate your own abilities. Tech savvy doesn't mean they think much about crypto.

To get a feel for this I asked Gemini "If you were to survey a group of people who would be called "Tech Savvy", what percentage of them would be aware you could construct a zero knowledge proof for a person's age that revealed nothing beyond they were older than a given threshold?". The answer was 5%..10%. That rises to a surprising low 20%..30% for Software Engineers. It's only once you get to Software Engineers who write security systems that you get above 50%.

Gemini didn't give any references so those figures could be complete rubbish, but in my experience they seem on the high side. Many very experienced engineers I interact with clearly have not thought very deeply about how crypto systems interact with human trust. Granted understanding the implications of crypto is yet another step beyond understanding the maths, but I'm amazed at how many technology curious people haven't bothered to take that step.

The good pollies on the other hand probably have a very good intuitive feel for human trust systems and how to navigate them. They rely on engineers to tell them what is possible of course, and they won't care about the details. But what they will care about is whether the engineers can deliver the system they promised, and there I have to admit our track record is appalling. How many government IT initiatives have you seen deliver what was promised on time and on budget? So when you tell them you can build a ZK system that delivers in all these privacy promises, expect a very sceptical reception.