|
|
Log in / Subscribe / Register

Not such a bad idea

Not such a bad idea

Posted Mar 11, 2026 21:01 UTC (Wed) by marcH (subscriber, #57642)
Parent article: California's Digital Age Assurance Act and Linux distributions

> The bill is short and, unfortunately, leaves a great deal unspecified. The preamble (digest) for the bill explains that existing California law, such as the Age-Appropriate Design Code Act, requires businesses that provide online services which are likely to be accessed by children to estimate the age of their users. This is in order to apply privacy and data protection, as well as to prohibit the use of "dark patterns to lead or encourage children" to provide more personal information than necessary, or to forgo privacy protections. One might wonder why the state of California wouldn't extend such courtesies to all users.

There are many technical and non-technical issues and maybe it's not feasible, but a centralized way to let applications and websites know the age bracket of the user sounds like a very reasonable idea. There are many gambling and other "adult" businesses that really want to follow the various laws of the places where they operate. When you can make good money legally, why risk it all with violations? Not all immoral businesses are as bad as social media.

This can still be useful even if "trust-based" and easy to defeat: not all 11-years old are tech geniuses and they are not all interested in adult content or chatting with traffickers. Even for young tech geniuses, having to defeat parental restrictions is better than unlimited access because having to cross that line sends a useful signal.


to post comments

Not such a bad idea

Posted Mar 11, 2026 21:31 UTC (Wed) by dskoll (subscriber, #1630) [Link] (22 responses)

There are many technical and non-technical issues and maybe it's not feasible, but a centralized way to let applications and websites know the age bracket of the user sounds like a very reasonable idea.

It sounds like a perfectly terrible idea to me, for all kinds of reasons.

First, a website can use the "age bracket" indicator to eventually determine the user's actual date of birth, or close to it. The procedure for doing this is left as an exercise for the reader. (Hint: Consider multiple visits to the site over time...)

Second, determining that someone is a minor can as well be used for nefarious purposes as for beneficial ones. Think targeted ads, or actually even worse, depending on what a website can trap someone into doing.

Third, the California law provides no effective way to provide a user's actual age bracket; there are many ways a user can lie about it. So it's just as effective to have an adult web site have something saying "You must be 18 or over to use this site" and have the person assert the age bracket when they enter the site.

Fourth, I'm an adult. All of my kids are adults. Anyone who uses my computer is an adult. I don't feel that I should share my date of birth, or age, or even age bracket with my operating system or random applications. They have no need to know that.

Not such a bad idea

Posted Mar 12, 2026 2:35 UTC (Thu) by marcH (subscriber, #57642) [Link] (9 responses)

> First, a website can use the "age bracket" indicator to eventually determine the user's actual date of birth, or close to it.

Then what? If only the date of birth were the worst privacy issue on the Internet...

> Second, determining that someone is a minor can as well be used for nefarious purposes as for beneficial ones. Think targeted ads, or actually even worse, depending on what a website can trap someone into doing.

Just because the API exists does not mean everything is allowed to use it - same as location, camera, microphone, etc. Exactly like with these other permissions today, an app or site requesting age when it has no reason too is not discrete and immediately draws suspicion.

> So it's just as effective to have an adult web site have something saying "You must be 18 or over to use this site" and have the person assert the age bracket when they enter the site.

Already answered.

> Fourth, I'm an adult. All of my kids are adults. Anyone who uses my computer is an adult. I don't feel that I should share my date of birth, or age, or even age bracket with my operating system or random applications. They have no need to know that.

If you had spent a fraction of the time looking at the proposal (or even just thinking about it), you would have noticed that there is only one age bracket above 18.

Not such a bad idea

Posted Mar 12, 2026 14:14 UTC (Thu) by dskoll (subscriber, #1630) [Link] (8 responses)

Then what? If only the date of birth were the worst privacy issue on the Internet...

Every new piece of information that can be deduced is yet one more widening of the attack surface for (eg) identity theft.

Just because the API exists does not mean everything is allowed to use it

Nope. Read the law. Every single application is required to ask for an age bracket signal.

you would have noticed that there is only one age bracket above 18.

Every new API is a widening of the attack surface. Every new piece of information an OS stores about me (and remember, it stores age or date of birth) is one more piece of thing that could be exposed in a hack.

Not such a bad idea

Posted Mar 12, 2026 14:26 UTC (Thu) by marcH (subscriber, #57642) [Link] (4 responses)

> Every new piece of information that can be deduced is yet one more widening of the attack surface for (eg) identity theft.

Identity theft is a real issue but it's a couple orders of magnitude worse in (at least) the US because of the incredibly stupid belief that immutable personal information 1. can be kept forever secret 2. can be used as a password!? This is especially stupid considering all that basic personal information is _already_ out of the bag and is already being marketed on more or less legal platforms. The sooner people in the US abandon those complete privacy illusions and get back to reality, the better.

There used to be a smarter time when people in the US didn't try to keep their social security number secret - just like in many other countries. I don't know what happened then.

> Nope. Read the law. Every single application is required to ask for an age bracket signal.

Not my understanding.

Not such a bad idea

Posted Mar 12, 2026 14:40 UTC (Thu) by dskoll (subscriber, #1630) [Link] (3 responses)

> Nope. Read the law. Every single application is required to ask for an age bracket signal.
 
Not my understanding.

Did you read the text of the law? Particularly 1798.501 (b) 1.

Not such a bad idea

Posted Mar 12, 2026 16:06 UTC (Thu) by kleptog (subscriber, #1183) [Link]

This language is terrible:

> 1798.501. (b) (1) A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.

So the Developer is a little daemon living inside your machine that has to do something ("request a signal") when you as a user do something ("download an application").

In all likelihood the Developer is actually asleep or busy doing actual useful work. Terry Pratchett makes jokes about machines being run by daemons, but that's not the real world. Which branch of government is tasked with ensuring legislation is actually sensible? The above is grammatically correct, but meaningless.

Not such a bad idea

Posted Mar 12, 2026 16:17 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

The text of the law has plenty of issues, especially the somewhat fictional line between "operating system" and "application". Would "curl" be part of the former or latter? Probably both...

On the other hand, the _intent_ of the law is pretty clear and stated in the first paragraph: make sure service providers grant children the "protections afforded to children". As the LWN article notes:

> One might wonder why the state of California wouldn't extend such courtesies to all users.

Obviously not a lawyer but if "applications" and online services don't want to be bothered by this new law, then easy enough: make your entire service "child-friendly" and don't spy on adults more than you're allowed to spy on children. Problem solved: if you assume the lowest age bracket then you don't need to ask for the actual age bracket. That's just basic logic and common sense but I agree it would be better to clarify it in the law.

Not such a bad idea

Posted Mar 16, 2026 18:14 UTC (Mon) by zhaan (guest, #177139) [Link]

> The text of the law has plenty of issues, especially the somewhat fictional line between "operating system" and "application". Would "curl" be part of the former or latter? Probably both...

"curl" is very much an application. It's separately developed, is cross platform, etc. It does not provide additional access to applications/services on top of it and doesn't even have HTML/CSS/JS support.

In terms of an example for "both", Emacs is a better example. Or Firefox/Chromium.

Not such a bad idea

Posted Mar 12, 2026 16:42 UTC (Thu) by jzb (editor, #7867) [Link] (2 responses)

The law is terrible, no doubt, but I think the definition of "application" is narrower than "every single application." The law defines an "application" as something that can "access a covered application store or can download an application", with an exemption for downloading extensions, etc. from an application store. Including the requirement to download applications or interact with an app store narrows what is considered "an application" considerably.

It would seem to include things like APT, DNF, flatpak, snap, GNOME Software, KDE Discover, etc., but exclude most of the software shipped with and used on a Linux distribution unless one is trying hard to stretch the definition considerably. At least that is my reading of the law; I am, of course, not a lawyer, nor do I play one on TV.

Not such a bad idea

Posted Mar 12, 2026 16:52 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Actually, it depends on your interpretation of the subordinate clause. Here's the text:

"Application" means a software application that may be run or directed by a user on a computer, a mobile device, or any other general purpose computing device that can access a covered application store or download an application.

You are taking the "that can access..." clause to modify "Application". However, I read it as modifying "a computer, a mobile device, or any other general computing device that can..."

If the word "and" had been inserted before "that can", then the "that can" clause would unambiguously refer to the "Application". As it stands, I believe it refers to the computing device.

Not such a bad idea

Posted Mar 13, 2026 13:39 UTC (Fri) by misc (subscriber, #73730) [Link]

Given Flathub distributed at least one game that would surely be classified as "not for kids" (the old Katawa Shoujo package), and now distribute a new modernized version ( https://flathub.org/fr/apps/sh.fhs.ksre ), I think that at least flatpak/flathub would be covered by the spirit of the law.

I do not know if the new version is the same as the old, but nothing indicate that the content was removed, and this is easy to verify.

For people who prefer to read code, there is some code around handling adult content on https://codeberg.org/fhs/katawa-shoujo-re-engineered/src/...

For people who prefer text, I think the game/script-a4-lilly.rpy file around line 3610 would be one of the clearest place.

And for those who prefer images to text, there is some explicit pictures in one of the game/event folder.

And of course, for people who want to test the game, you can just finish it in around 8h ( https://howlongtobeat.com/game/4943 ).

IIRC, there is a option to turn on/off the NSFW part, and I do not know if this is on or off by default. But I do not think this matter that much in practice, except that this is one example where a unified API would be useful (eg, something for parental lockdown).

Not such a bad idea

Posted Mar 12, 2026 10:17 UTC (Thu) by Niflmir (subscriber, #175249) [Link] (11 responses)

> Third, the California law provides no effective way to provide a user's actual age bracket; there are many ways a user can lie about it. So it's just as effective to have an adult web site have something saying "You must be 18 or over to use this site" and have the person assert the age bracket when they enter the site.

It's precisely the point that the controller of the user account can choose the value. If a parent allows their child adult access to the app store then they get it: they can choose to "lie" but it is their choice. If the parent allows the child to setup the account then the child can "lie" about it. But once the value is set then applications can start respecting it. It does end up with some ironies like needing curl to be considered adult content since that would enable requests to adult websites since the CLI permits choosing the ultimate "I'm allowed adult content" header value or whatever it will be. And so package managers shouldn't install it in a way that a child account could access it. Or it could just not install it if there is such an account, or uninstall if such an account was created.

That is exactly what parental controls on a device need to look like. A parent needs a simple manner in order to say: forbid adult content to my child's account (possibly with some granularity->age brackets). They need to do so at account creation and then be able to trust that the device will then take care of it. That means app stores/installation would need to respect it. Companies already lock down devices like this for employees but not with adult content in mind but just with random binaries in mind, some people would like to standardize that so they could deputize their supervision of their children to software in a standard way. If you let your child have access to general purpose computing (so a programming language), well then they can find workarounds and that can be acceptable to society: that a child that has access to python and is willing to use the requests lib to download pornography doesn't make the porn website liable: the parent chose to grant that access. If a kid uses a zero day to jailbreak, well the parent should be routinely checking the device for the child to have grown sophisticated enough to become a hacker/script kiddie.

Having an account level flag is really the most privacy preserving way to do it. If you let your child buy a phone and set it up, well then you know what is possible, you made your choice. Then all of those lame "Are you 18?" forms go away. This is what automated parental supervision of a general purpose computing device should look like. They won't ever learn how old I am and it is already illegal to track children, sure websites can do it, but they already illegally do so with other markers. That problem has to be solved in another manner, already.

Not such a bad idea

Posted Mar 12, 2026 12:33 UTC (Thu) by Wol (subscriber, #4433) [Link] (10 responses)

> Then all of those lame "Are you 18?" forms go away.

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.

In Britain you can be "adult" at 16/18/21/25 depending on the context. There's even more age variation in other countries I believe.

And then, where it would be useful is places like youtube, where we have U(nrestricted), P(arental) G(uidance), and then I think 11, 14 and 18 (minimum age) classifications. Dunno how this law is supposed to cope with PG, and do other countries have similar classifications? Doing that would also be a massive data leak, giving children's ages away to pretty specific age brackets ...

Cheers,
Wol

Not such a bad idea

Posted Mar 12, 2026 17:10 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (9 responses)

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.

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds