Not such a bad idea [LWN.net]

Not such a bad idea

Posted Mar 12, 2026 17:10 UTC (Thu) by rgmoore (✭ supporter ✭, #75)
In reply to: Not such a bad idea by Wol
Parent article: California's Digital Age Assurance Act and Linux distributions

The other problem, of course, is that it's all very well having a binary child/adult "are you over 18?" switch, but different law systems have plenty of differing age requirements.

That problem is already taken care of. The idea is that the site is supposed to be able to ask about any age rather than just a generic 18. So if they're supposed to check for other ages, like the 11 and 14 you mention, they can just ask "are you at least 11" or "are you at least 14" and get simple yes or no answers. It's not a bad concept, though they need to refine it a lot.

Of course it still isn't perfect in other ways. If the site is allowed to keep asking and isn't restricted to a few defined ages, it could use a binary search to get a precise age after about 15 questions. Even if it's only allowed to ask for statutorily required age brackets, someone who comes back regularly could reveal their exact birthday if they're forbidden one day and allowed the next. It's still way better than the alternatives that result in people having to reveal extraneous, high sensitivity information to a third party for age verification.

to post comments

Not such a bad idea

Posted Mar 12, 2026 17:32 UTC (Thu) by dskoll (subscriber, #1630) [Link] (2 responses)

It's still way better than the alternatives that result in people having to reveal extraneous, high sensitivity information to a third party for age verification.

But there are zero-knowledge ways to prove your age. However, they assume that you trust your government and that your government is competent. (Your government already knows your date of birth, so you're not providing info to a third party.)

The original web site does not know your identity or your actual age, and the government age attestation provider does not know which web site was asking for age attestation. This problem has been solved ages ago by federated authentication systems.

I fundamentally disagree with age attestation at all. But if a government is going to mandate it, then it should be forced to set up and run a zero-knowledge age attestation provider. ZKPs are not a panacea, but IMO are a better solution than device-based attestation, which anyway is trivial to forge... for now, until governments start approving what software you are allowed to run.

Not such a bad idea

Posted Mar 12, 2026 22:09 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link]

However, they assume that you trust your government and that your government is competent.

I actually trust the California civil service to run this kind of thing if the legislature is smart enough to pass a bill requiring it. Our state government is absolutely not perfect- we've had our share of mistakes and boondoggles- but it's definitely capable of managing the technical side of this.

the government age attestation provider does not know which web site was asking for age attestation.

That's good to hear, because I don't think anyone wants to be in a situation where the government is immediately notified every time we visit an age restricted web site or view age restricted content. I think the typical voter would need a convincing explanation of how the system worked so they could really trust that the government was the one verifying their age but didn't get access to their browsing history in the process.

Not such a bad idea

Posted Mar 13, 2026 9:35 UTC (Fri) by farnz (subscriber, #17727) [Link]

Note that eIDAS (which is the overarching project that that zero-knowledge proof comes from) is not yet ready for wide deployment; they've been doing trials since 2016 to confirm that it works, and they've been refining it after field trials demonstrate that there are practical attacks on the protocols they've used.

Not such a bad idea

Posted Mar 12, 2026 17:35 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

There is, however, a way to turn it round: instead of the device attesting the user's age to the site, the site tells the device what age the user must be to access this piece of content (e.g. as a HTTP header or similar). The device can then make a decision about what to do, and can "fake" the user looking and closing the site without interacting if they're under age.

This requires a different set of legislation; you need the devices to comply with the restrictions indicated by the site or app developer, and you need to say that where someone correctly labels their content as "not for users below age X", then it is a matter of legal fact that all their users are above age X. Say "not for users below 21" on your site, and now you can neither be sued nor prosecuted on the basis that a 20 year old accessed the content.

Done properly, this also allows for sites with mixed content; a video platform could mark some content as "not for under 18s", and other bits as "not for under 11s". And because it's the device enforcing it, parental controls can let you grant exceptions; taking the UK's "12A" film rating, for example, the intended enforcement is "over 12, or accompanied by an adult". You could handle that by saying that the content is sent as "not for users below 12", and then I can grant an exception because I think my 11 year old can handle it.

Not such a bad idea

Posted Mar 12, 2026 18:18 UTC (Thu) by geert (subscriber, #98403) [Link]

Or... humans.txt?

Oh, that one is already taken.

Not such a bad idea

Posted Mar 12, 2026 18:48 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

This is the best solution I've heard so far. As long as it was made optional for devices to comply, I would support this.

Optional so that parents who want this for their kids can have it, but for adults who don't want it not to have it on their systems. And of course, web sites that advertise the age restrictions would have to be indemnified against people using devices that ignore the restrictions.

Not such a bad idea

Posted Mar 12, 2026 19:21 UTC (Thu) by farnz (subscriber, #17727) [Link]

The hard part is selling the "optional to comply" bit to legislators - the whole reason this mess is happening is that they want to protect children from unsuitable content, while still permitting adults freedom to access that same content.

The best I can see you getting is some variation on the theme of "the default restrictions match the age of the buyer, if known" - that way, if an adult buys a device, the device doesn't enforce, but if a child buys a device, it must enforce child restrictions on them.

Not such a bad idea

Posted Mar 13, 2026 9:08 UTC (Fri) by kleptog (subscriber, #1183) [Link] (1 responses)

If you squint a bit (read "OS" as "Android or iOS or TVOS" and "application" as "app from app store") then you could imagine that this is what they actually intended. They just didn't realise that the terms "operating system" and "application" mean something different to technical people than it does to the general public. It probably didn't occur to them that the services they are accessing are provided by systems that are also running an operating system with applications.

Android already provides an OS level API for determining if the current user is over 18, and apps can use that. Parental controls on devices is very common. Microsoft accounts also track this, it's just that on desktops its usage much less consistent.

I'm generally fairly optimistic about people's intentions. But I would expect a legislative process to do a better job of ensuring the texts are sane rather than expecting courts to fix them up later.

Not such a bad idea

Posted Mar 13, 2026 9:35 UTC (Fri) by farnz (subscriber, #17727) [Link]

The bit that's missing to convince me that it's just poorly drafted, and not intent, is protections for apps or sites that obey the law.

As written, it says that the developer can be penalised for not respecting this signal, but not that the developer is protected from consequences if they rely on this signal, but it's wrong. Indeed, it goes in the opposite direction - if the developer ought to know that the signal is wrong, they can be in trouble for relying on the signal over outside knowledge.

This is the worst possible outcome, IMO. It means that support for the signal is all stick, no carrot - not least because if you happen to know the signal is wrong, you can be penalised because you refused to let an adult access your service on the basis that the signal said they were under 13, and penalised because you let a child access your service on the basis that the signal said they were over 18.