California's Digital Age Assurance Act and Linux distributions [LWN.net]

By Joe Brockmeier
March 11, 2026

A recently enacted law in California imposes an age-verification requirement on operating-system providers beginning next year. The language of the Digital Age Assurance Act does not restrict its requirements to proprietary or commercial operating systems; projects like Debian, FreeBSD, Fedora, and others seem to be on the hook just as much as Apple or Microsoft. There is some hope that the law will be amended, but there is no guarantee that it will be. This means that the developer communities behind Linux distributions are having to discuss whether and how to comply with the law with little time and even less legal guidance.

The law requires operating-system providers to provide a form of age verification that can be queried by any web site, application, or online service "that distributes and facilitates the download of applications from third-party developers" for computers, mobile devices, or other general-purpose computing devices. The law goes into effect on January 1, 2027, which leaves less than ten months for distributions to determine if the law applies to them and then implement a solution if it does.

The law was introduced in February 2025 and passed into law in October 2025. Unlike other legislation, such as the European Union's Cyber Resilience Act (CRA), it seems to have slipped in under the radar without raising any real protest from the open-source projects it affects. It seems to have gathered widespread attention in the Linux community after Aaron Rainbolt started a discussion about the new law by cross-posting a message about "the unfortunate need for an 'age verification' API" to Debian, Fedora, and Ubuntu mailing lists on March 1. He provided a pointer to the California law as well as a similar bill that is working its way through the Colorado legislature.

Requirements

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.

In order for businesses to comply with the Age-Appropriate Design Code Act and other laws, the Digital Age Assurance Act compels operating-system providers to "provide an accessible interface at account setup that requires an account holder [...] to indicate the birth date, age, or both, of the user of that device". This is to allow third parties to query the user's age bracket to determine, for example, if they are old enough to access certain content or applications. Requiring online platforms to perform age verification, though, means that they are handling personally identifiable information (PII); the law is positioned as a privacy-friendly alternative to allowing those services from collecting or retaining PII beyond what is necessary to provide the service. For example, rather than a site asking the user for their birthday to ascertain their age, the site is supposed to send a query using an API asking for the age bracket of the user instead. So the site does not collect data that indicates that user "CAGamerPerson7" was born on June 7, 2014; it only gets a signal to attest that the user is in a certain age bracket.

In the US, various state legislatures have been passing laws that require sites to verify the age of people who attempt to access "adult" content or putting age restrictions on social media platforms like TikTok and Instagram. For example, a number of states now require adult web sites to verify a user's age. This is usually done by asking the user to show government-issued ID or to use third-party service that verify age (also, usually, by reviewing the person's ID). Several states also have either banned minors from having social-media accounts, or require parental consent to have an account. There are also laws that try to make online services "safer" for children, such as California's SB-976 ("Protecting Our Kids from Social Media Addiction Act"). That law, passed in 2024, makes it "unlawful for the operator of an addictive internet-based service or application [...] to provide an addictive feed to a user, unless the operator does not have actual knowledge that the user is a minor".

There is more age-verification legislation on the horizon. User "aaronsb" on Reddit dug into the age-verification bills being introduced in the US. California's law is a version that is being pushed by a group called Common Sense Media, which is a nonprofit organization that is advocating for laws it says will "hold tech accountable, and put children's well-being at the center of the digital world". Another version, called the "App Store Accountability Act" has been introduced in many other states. It is being pushed by a group called the Digital Childhood Alliance. According to aaronsb, the purpose of that legislation is to shift age-verification from providers like Meta or Epic Games to the app stores. That legislation does not appear to impact providers of open-source operating systems.

The methods of age verification have been a nightmare for users who care about privacy. The implementations have often required users to provide legal ID to a third party in order to prove their age; these providers are ripe targets for attackers, and a number of them have already exposed that information via data breaches of one form or another. California's law, at least, allows the user to self-supply their age range without sharing data with a third party; we can breathe easy knowing that no 13-year-old would ever fib about their age in order to access "forbidden" content.

The push for age-verification laws has not been restricted to the US, of course. In 2023, France passed a law requiring age verification for minors using social media, and the UK enacted the Online Safety Act. Australia passed the Online Safety Amendment in 2024. No doubt there are many more that have either passed or are under consideration.

The California law is overbroad and makes no exceptions for open-source operating systems. It defines an operating-system provider as "a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device". The penalty for non-compliance is $2,500 "per affected child for each negligent violation", but not more than $7,500 per child. That seems to leave the door open for any operating-system provider, including projects like Debian or Fedora, to be sued by the state if the distributions do not have a mechanism to comply with this by next year.

Distribution discussion

Rainbolt said that, since operating-system providers will need to provide an API for age verification, he was looking into implementing one for the Kicksecure and Whonix distributions. He threw out a few ideas about how to implement the functionality required, such as using the D-Bus service AccountsService. However, this would pose a problem for long-term-support (LTS) distributions; California's law requires the age-attestation interface be available even if an operating system had been installed and had accounts set up before January 1, 2027 as long as the device is still getting updates. Therefore the law seems to require that operating-system providers implement this for older systems that are still getting updates, meaning that it would apply to some fairly old Linux releases. To account for that requirement, he suggested that distributions take a hybrid approach by introducing a new D-Bus interface, "org.freedesktop.AgeVerification1", that could be implemented in AccountsService or via another application as a stop-gap solution.

There was some discussion about the details of how age attestation could be implemented to comply with the California law as well as other age-attestation requirements in other jurisdictions. One might think that California's law would provide more details about implementation, but it does not. It simply specifies that an operating-system provider must provide developers with "a signal with respect to a particular user with a digital signal via a reasonably consistent real-time application programming interface that identifies" the user's age bracket.

Danielle Foré, founder and CEO of elementary OS, weighed in with some ideas and pointers to documentation of Apple's Declared Age Range API. In a private message, she said that the implementation being discussed would be modeled after that API:

It's entirely on-device, self-attested, and does a decent job providing the least information to developers we possibly can while still following the law to the best of our understanding.

I think the general consensus among folks participating here is that we don't think age declaration is the best way to empower parents and we all are very interested in asking for as little data as possible, storing it on your device only, and giving only the bare minimum data as required by law to app developers. It's being discussed begrudgingly. Nobody is eager about this and we're all hoping the laws get overturned before the implementation deadlines

Legal analysis

A number of people active in the discussion Rainbolt started said either that they thought the law did not apply to open-source operating systems, or suggested that the projects should ignore the law. For example, attorney Vincent F. Heuser Jr. said he doubted that California "can actually succeed in applying the law to Debian, Ubuntu" and others. Debian developer Soren Stoutner said that distributions should "do nothing towards implementing this dangerous legislation", as he expected it would be overturned or unenforced. There also has been much discussion on Fedora's Discourse forum and elsewhere, but there is something of a vacuum when it comes to official legal guidance. I reached out to a number of legal experts and organizations that might be well-positioned to comment. The Software Freedom Conservancy (SFC) and the Electronic Frontier Foundation (EFF) responded.

Bradley Kühn, policy fellow and hacker-in-residence for the SFC, replied with some observations about the law, including the fact that Governor Gavin Newsom had included a signing statement that urged the legislature to amend the law to address some concerns expressed by video-game developers and streaming services. That might be an opportunity to also exempt open-source operating systems. Kühn said that it was "not a disaster for FOSS" even if it did go into effect as written: "DRM, vendor-restricted boot, other copyleft-violating technologies are not required for implementation". He added that the SFC is only focused on the impact on FOSS itself and copyleft licensing, as that is its area of expertise. The SFC is still analyzing the bill, and he said that it would likely issue a comprehensive statement in about a month.

Samantha Baldwin, a policy and research staff technologist on EFF's Public Interest Technology team, said that the bills were "technologically ignorant". The only carve-out in the bill is for broadband internet access services, "which we suppose is meant to exempt routers and modems from needing to implement age bracketing". The EFF released a statement in March 2025 detailing its concerns about the bill at the time, including worries about platforms censoring protected speech as well as the impact of age-verification laws on all users from a privacy and security standpoint. The EFF does hold that the law is enforceable for operating systems produced by FOSS projects:

The bill drafters seem to only be thinking about general purpose operating systems from corporate vendors, but almost any digital device runs an operating system of some kind. It is completely nonsensical technically. It is not feasible to have your headphones, your insulin pump, your ebike, your oven, your kerosene powered cheese grater implement age bracketing, yet all of these run operating systems.

These bills strike at the heart of digital liberty, at our ability to have control of our own devices. They seek to restrict our ability to run open platforms composed of software that is both free as in speech and as in beer.

Nothing in the bill language exempts noncommercial projects, meaning open source research operating systems like the BSDs, Plan 9, OpenSolaris, etc. are all affected.

These laws should be challenged on their constitutionality in court.

Status

How Linux distributions and other open operating systems will choose to react or implement this is still largely up in the air. MidnightBSD has declared on its download page that residents of countries, states, or territories that require age verification "are not authorized to use" the operating system. Fedora Project Leader Jef Spaleta noted that the age-verification law was "fully in the realm of requiring legal advice". Jon Seager, VP engineering for Canonical, said that the company is aware of the legislation and is reviewing it with legal counsel. "There are currently no concrete plans on how, or even whether, Ubuntu will change in response".

System76, which is based in Colorado, produces the Ubuntu-based Pop!_OS distribution. Its CEO, Carl Richell, said that he has met with Colorado senator Matt Ball, who is the co-author of that state's age-attestation bill. He said that Ball suggested excluding open-source software from that bill, which "appears to be a real possibility". In addition, he expected there would be amendments to California's law.

It's my hope we can move fast enough to influence excluding open source in the CA bill amendments.

No illusions, it's an uphill battle, but we have an open door to advocate for the open source community.

If we are lucky, open-source operating systems will be exempted before California's law goes into effect and before Colorado's bill is passed into law (if it is). That does not mean that such laws are actually good policy, however, just that open-source projects won't bear the brunt of having to implement functionality to be compliant with bad policy. At best, the Digital Age Assurance Act seems to be futile attempt at "protecting" children while actually accomplishing nothing more than adding compliance headaches for operating-system providers and application developers.

to post comments

Also affects application developers

Posted Mar 11, 2026 17:58 UTC (Wed) by dskoll (subscriber, #1630) [Link] (8 responses)

The law doesn't just affect OS providers. It also affects application developers. From the California law:

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.

"Developer" is defined in the law as "a person that owns, maintains, or controls an application."

So if you write an application that does not request an age-bracket signal from an OS provider, you are breaking the law. This means that technically, cp, ls, and so on need to request an age-bracket signal, though it's not at all clear what they have to do with the signal other than "comply[ing] with applicable law"

The law is a real mess and preferably should be struck down, or if not, then at the very least heavily amended.

Also affects application developers

Posted Mar 11, 2026 19:30 UTC (Wed) by RazeLighter777 (subscriber, #130021) [Link]

This was also something I saw from the bill after a close reading of the text. It has garnered little discussion online.

This requirement is arguably much more contentious as it exposes developers of any application to legal liability. I surmise that this requirement alone from the law is unconstitutional.

First, the law burdens the right to receive information (through applications). The U.S. Supreme Court has recognized that the First Amendment protects not only the right to speak but also the right to receive ideas and information, such as in Stanley v. Georgia and Lamont v. Postmaster General. A requirement to present identification before entering a bookstore could deter people from accessing controversial or sensitive material. Courts often treat such “chilling effects” on reading as constitutionally significant.

This law, because it requires developers to distribute their applications and operating systems with a feature to request age bracket data from their users, is compelled speech. This compelled speech is agnostic to the type of application or it's purpose, meaning that it is content-neutral.

Content neutral restrictions on speech typically fall under intermediate scrutiny, as opposed to content-based restrictions which typically fall under strict scrutiny.

To pass intermediate scrutiny, the challenged law must:

1) further an important government interest (lower burden than compelling state interest required by strict scrutiny test)
2) and must do so by means that are substantially related to that interest.

[1]

I would argue that the state has an important government interest to protect children online. However, it's unclear that the state has an interest in ensuring every single program on the operating system requests the users age.

Moreover, this law fails to achieve this by means that are substantially related to this interest as required by law. Let's look at US West, Inc. v. United States [2]. This ruling concerned a law passed preventing telephone providers from providing video services, and was subject to the same intermediate scrutiny.

The court ruled that the state "must demonstrate that the recited harms are real, not merely conjectural, and that the regulation will in fact alleviate these harms in a direct and material way".

It is unclear how the government can demonstrate that the particular harms to children are alleviated by this bill. Requiring every single application to verify the age of the user, regardless of the contents need for age verification, opens up the user to profiling and data collection that place the child at risk. Moreover, it is clear that these measures do not *effectively* mitigate the problem, as the child can (and will!) very simply bypass these measures.

(A child can simply misrepresent their age by setting their age during installation or after the effect. They may also install an operating system without age bracketing APIs in place. Or they can simply install a virtual machine where they control the operating system.)

I don't think these laws are constitutional as written, and the state would have an uphill battle in enforcing them. I expect many more court challenges to arise.

[1]: https://www.law.cornell.edu/wex/intermediate_scrutiny
[2]: https://law.justia.com/cases/federal/district-courts/FSup...

Also affects application developers

Posted Mar 11, 2026 20:34 UTC (Wed) by fredrik (subscriber, #232) [Link] (3 responses)

Heh, almost-sorry-not-sorry for the following noise. Couldn't resist... *<:)

"Developer" is defined in the law as "a person that owns, maintains, or controls an application."

As a devil's advocate - and very much in the spirit of a developer who knowingly attempts to circumvent the law by legally invalid technical interpretations, and who has only read the above quote - what about the following argument?

My client, on trial, admits that they are both, a person who owns[0] the application "Baz", and that they are a person who is a maintainer of the application "Baz". Baz is an application that is provided to users under a FLOSS license.
My client has two objections to the charges of failure to implement functionality in Baz that fulfills the law's age verification requirements.
1. My client argue that they are never in control of said application when it is run by a user of the application on the user's computer. Hence my client can only comply to the law to the extent that the controlling user permits it.
2. Since the law was introduced, my client provides optional patches for the application, which implements a technical measure in the application to fulfill the law. When patched the application inquires the user's age range, and provides said range to any service which the application interacts with and which inquires the application about the user's age.
All users who are under the jurisdiction of the law, are encouraged to run versions of the application which includes these patches.
Hence, my client argues that they cannot be held responsible for users who are within the law's jurisdiction, but still choose not to apply the patches to their copy of Baz. Such unlawful usage is the fault of the user of Baz, not the owner or maintainer of Baz.

So... dear hypothetical arm-chair prosecutors, game on! What is your legal objection to these arguments?

A variation on objection 2: No patches are provided. Instead affected users are encouraged to both implement and apply patches that provide the necessary age verification. Baz is FLOSS after all. The user can modify it to ensure that when executed, Baz complies with any laws applicable to the user.

[0] I interpret "own" in the copyright sense of the word. Again, I really have only read the above quote, nothing more. PS. This comment may well be as obviously stupid as the law. So let me conclude with an preemptive apology to all who are annoyed by it. Cheers!

Also affects application developers

Posted Mar 11, 2026 22:57 UTC (Wed) by Wol (subscriber, #4433) [Link]

> [0] I interpret "own" in the copyright sense of the word. Again, I really have only read the above quote, nothing more. PS. This comment may well be as obviously stupid as the law. So let me conclude with an preemptive apology to all who are annoyed by it.

My reaction was that if you are not the sole maintainer AND copyright holder, then the end user is just as much the owner of a FLOSS program as the maintainers.

Cheers,
Wol

Also affects application developers

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

This is one of the reasons the "on the market" language the EU uses is so useful. Since it clearly scopes it to commercial transactions with EU entities. This law is placing specific obligations on "developers" and "operating system providers" (where?) but that's actually beside the point. Whether it's a developer, an AI or a vibe-coder doing the implementation, you care about the end-result, not who is doing it.

If this is typical for US regulations, then I understand why you need powerful regulators. Since basically the state has taken it upon itself to try and force companies/people (worldwide?) to work a specific way, rather than defining the rules of the game and letting the market figure out the most efficient way to achieve the desired result.

Also affects application developers

Posted Mar 18, 2026 12:01 UTC (Wed) by vonbrand (guest, #4458) [Link]

Another variation, a configuration option adds age limiting. Perhaps needs to be configured separately for a variety of age-reporting services.

Also affects application developers

Posted Mar 11, 2026 22:47 UTC (Wed) by WolfWings (subscriber, #56790) [Link] (1 responses)

It doesn't even separate out python (the interpreter) versus a python script that uses Tkinter to provide a full GUI interface, under a raw enough reading it appears it would apply to both the interpreter on loading the script AND the script to have to query this nonsense.

Also affects application developers

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

Also, this part is curious:

"Covered application store" does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application.

So, hypothetically, if you made a web browser plugin that let people access gambling sites on the Dark Web that aren't normally accessible... your plugin wouldn't need to worry about the user's age? Or, you could make a shared library that grants access to age-restricted material, but because the code runs "exclusively within a separate host application" you're OK? The law as written is a complete dog's breakfast.

Also affects application developers

Posted Mar 12, 2026 6:38 UTC (Thu) by MortenSickel (subscriber, #3238) [Link]

This means that technically, cp, ls, and so on need to request an age-bracket signal, though it's not at all clear what they have to do with the signal other than "comply[ing] with applicable law"

$ cp -R ~dad/pr0n.

Sorry, you are outside the age bracket to access that content

One reaction

Posted Mar 11, 2026 18:33 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

I'd like to believe that publishing a general purpose operating system for anyone to copy and which lacks these features is within our US constitutional right of free speech and is a human right as well.

Just ignore it

Posted Mar 11, 2026 18:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

I think the consensus right now is to just ignore it. This law is DoA with its enforcement likely ending after one public court case.

Condolences in advance to whomever ends up in that court case, and I'll make sure to donate to their defense fund (if needed).

Defence in depth, versus leaks

Posted Mar 11, 2026 19:16 UTC (Wed) by davecb (subscriber, #1574) [Link] (3 responses)

If we wanted this as one approach in a multi-approach defense in depth, it's every bit as good as a lock on a glass door.

In the California scheme, and for any given operating system, there has to be a source of the age. In a phone or laptop bought by a parent for a child, this can be a "assertation" by the purchaser.

Given that, an age requirement can function if an only if
- the child is young enough, and
- they have no-one who can help them reinstall.

For an older child, buying the their own phone or reinstalling Windows will defeat this kind of measure. The scheme fails for proprietary OSes just as it does for Linux.

For any child with root, creating another account will do the job in double-quick time. Guaranteed fail!

I've come to think that we're missing the real point by miles. We're banning the wrong thing, https://leaflessca.wordpress.com/2026/02/09/wrong-ban/

This is derived from M Fioretti's "Dear parents, social media are yesterday's battle", https://mfioretti.substack.com/p/dear-parents-social-medi...

Defence in depth, versus leaks

Posted Mar 11, 2026 19:45 UTC (Wed) by Sho (guest, #8956) [Link]

Note that it's entirely conceivable that the source of the legislation is banking on an assertion-based approach to demonstrably fail in the market, and then proceed with proposing more stringent laws based on device-locking and centrally issued client certificates.

Markets with comparable infrastructure exist (e.g. South Korea) and are the envy of some legislators.

Defence in depth, versus leaks

Posted Mar 11, 2026 20:10 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

> I've come to think that we're missing the real point by miles. We're banning the wrong thing, https://leaflessca.wordpress.com/2026/02/09/wrong-ban/
>
> This is derived from M Fioretti's "Dear parents, social media are yesterday's battle", https://mfioretti.substack.com/p/dear-parents-social-medi...

How about no? Perhaps parents should learn how to do proper parenting, instead of banning this and that.

Also: https://blog.system76.com/post/system76-on-age-verification

Defence in depth, versus leaks

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

> Perhaps parents should learn how to do proper parenting, instead of banning this and that.

Your children are so lucky to have you. If you don't have any yet, please consider?

Not such a bad idea

Posted Mar 11, 2026 21:01 UTC (Wed) by marcH (subscriber, #57642) [Link] (23 responses)

> 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.

Not such a bad idea

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

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 (subscriber, #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.

Multiple Users per Account

Posted Mar 11, 2026 21:10 UTC (Wed) by senders (subscriber, #113889) [Link]

From the text it reads like the initial submission of age is done at "account setup". So my family PC in the living room which has 1 account called "LastName PC" shares 1 age for ever user in my house? How is this even remotely useful?

if i require my kids to use their own "kids account" 1) normal parental controls exist already so what value is added here
2) this requires, in non-linux, my CHILD to register with an online account thus tracking their data etc... which defeats the whole "protect the kids" b.s
3) as implied in the article: if this is checked against a service at creation time: requires Internet access to setup a user on a PC

Did I miss something? Like obviously this is DoA if it gets challenged by anyone who has actually used a computer in the last ... 75 years.

Due to this experience [...] we banned the entire state of California for life.

Posted Mar 11, 2026 21:42 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

Lolwut?!

This reminds me of the Malibal guy, in reverse. :D

<https://www.reddit.com/r/programmingcirclejerk/comments/1...>

I expect the second most likely outcome of this to be people banning the entire state of California from using their code, after the most likely one, which would of course be this bill being revoked.

Due to this experience [...] we banned the entire state of California for life.

Posted Mar 11, 2026 23:32 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

Oh, indeed.

> MidnightBSD has declared on its download page that residents of countries, states, or territories that require age verification ""are not authorized to use"" the operating system.

Parental supervision required

Posted Mar 11, 2026 21:48 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

we can breathe easy knowing that no 13-year-old would ever fib about their age in order to access "forbidden" content.

The age is set at the time of account setup, and the idea seems to be that parents will set up accounts for their kids rather than letting the kids do it themselves. If the parents set the ages of their kids accurately, all well and good. If they set the ages of their kids inaccurately or if they allow their kids to set their own ages unsupervised, the parents aren't in a strong position to complain about their kids accessing forbidden content. It isn't a perfect solution, but it does theoretically give parents a way of age restricting their kids' access while minimizing the information leakage.

Parental supervision required

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

I would have no issue is this were an optional feature of an OS. Then parents who want it could buy devices that support it (or enable it under settings), set up their kids' accounts, and all would be well. I wouldn't even mind if the law said something like "vendors that do not provide parental controls must prominently advertise that fact" or something.

Mandating age-bracket signals for every OS and every app? Uh... no. Just no.

Parental supervision required

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

> I would have no issue is this were an optional feature of an OS.

Of course this will always be "optional" somewhat because it will be at the very possible easy to defeat.

Android parental control is pretty hard to defeat today, but nothing stops a kid from buying a cheap used phone and setting it up from scratch while lying about their age. Yet parental control is still very useful because not every kid wants to go that far. As a parent you cannot be constantly watching over your kids' shoulder; that's what parental control is for.

Parental supervision required

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

Of course this will always be "optional" somewhat because it will be at the very possible easy to defeat.

The law does not make it optional and it imposes substantial fines on developers who don't include it. I know it will be effectively optional for end-users, but as a developer, I don't relish being on the hook for the fines if I don't include this in my software.

Parental supervision required

Posted Mar 12, 2026 17:56 UTC (Thu) by paulj (subscriber, #341) [Link]

It doesn't minimise DoB leakage at all.

Any application (inc. web site applications, there will no doubt be some HTML API in time for this) that can get the age category 'signal' can just store 1 instance of the tuple of (category indicated, date last requested) for each user and then just note when a fresh 'signal' differs from the stored - the DoB is within the range [date last requested, current date]. So a popular 'application' for a given user who is under-18 has 1 or more chances to acquire the user's DoB down to a fine granularity (to the day potentially). And popular 'applications' with large user-bases will be able to build up databases of DoBs that are correct down to the day for large numbers of people.

Another volley in the war on general purpose computing.

Posted Mar 11, 2026 23:31 UTC (Wed) by Karellen (subscriber, #67644) [Link] (1 responses)

They're still trying to mandate the existence of a Turing machine that can only run the good programs.

something something stupidest timeline.

Another volley in the war on general purpose computing.

Posted Mar 13, 2026 23:17 UTC (Fri) by Karellen (subscriber, #67644) [Link]

I guess this would mean that work on legacy OSs, like FreeDOS, would have to stop? Unless you put age verification in them, but then they're no longer being a copy of the thing they're a copy of.

But also you wouldn't be able to write a new OS from scratch, unless the first part you implement is age verification? Otherwise you might have an OS without one. So the first thing Linus would have to do would be to write an age verifier, before he started printing "A" and "B" from separate threads.

smh

Lack of privacy protection

Posted Mar 12, 2026 3:47 UTC (Thu) by ryannestone (subscriber, #182659) [Link]

I wonder what age a user is if they have x cookie and the signal from the browser graduates from one age bracket to another. Age was previously inferred but is now a datum.

This is a ridiculous law by uninformed lawyers, unfortunately I suspect it will be constitutional.

Pull a Zimmermann

Posted Mar 12, 2026 4:09 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (1 responses)

I think distros should just do as Phil Zimmermann did, when PGP was deemed "weapons-grade encryption" and thus verboten - Jawohl! - from being exported, i.e. publish the source code - free speech and all -, which they do already anyway, for export to problematic jurisdictions and try to restrict downloads of the compiled version in those areas, just hard enough to maintain plausible deniability. Thus they don't provide an actual working OS and someone running it must have compiled it from source; "what're ya gonna do, officer?" So the user is the actual OS provider. Do educate them on the legal ramifications and lean back. Or just cripple it enough to render it inoperable, also much like those "export" versions of "weapons-grade crypto", which capped key size at 56 bits, IIRC. It's an easy enough fix for the end user, if they were to actually go the extra mile, instead of just VPNing their way to the real download. "But what are we supposed to do about that, officer? For all we knew they were sitting in that internet café over there, when they downloaded it."

I keep being amazed at the seemingly ever increasing gullibility of the simple minds in politics. One cannot force DRM in FOSS, because that's what it is: Digital Restrictions Management, just wearing it's shining armor of righteousness today. They may as well just do a popup asking if the person at the helm is really, really old enough and, to make extra sure, make them swear they are being truthful, so help them Saint IGNUcius!1!!

Pull a Zimmermann

Posted Mar 12, 2026 12:31 UTC (Thu) by chris_se (subscriber, #99706) [Link]

> I think distros should just do as Phil Zimmermann did, when PGP was deemed "weapons-grade encryption"

While I think this was a fantastic stunt back then, you do realize that this was never actually tested in court? The investigation against Zimmermann was dropped in 1996 without this having ever gone to court. (The same year the executive order was signed that started the process of lifting most restrictions - though I don't know off the top of my head which of these came first.) And even if the book thing had held up in court, you'd still have the issue that PGP was downloaded from US servers from users outside of the US _before_ the book with the PGP source code was printed. Sure, the book showed the absurdity of trying to have this kind of government control, and it was fantastic politics, but in a court of law Zimmermann could still easily have lost just because of the previous downloads where he hadn't yet printed the book.

Firefox parental control integration

Posted Mar 12, 2026 4:24 UTC (Thu) by fraetor (subscriber, #161147) [Link]

I can't find a good source on it from my phone, but fairly recently a new about: page was added to Firefox that displays when accessing a site that signals it is adult content[^0] while the current user account has parental controls enabled.[^1]

IIRC there was an accompanying help article that indicates the intent is to encourage local age assertion over the current remote assertion now done in the UK and other countries. It explicitly said that an admin would be able to bypass, but that is part of the parental responsibility to setup the computer appropriately.

[^0]: Which sites like gambling and porn already signal in a meta tag for SEO reasons and existing safe-search style filtering.
[^1]: I can't remember if it was enabled only on Windows so far, or still a work in progress thst will be fully enabled later.

Zippo Test

Posted Mar 12, 2026 6:09 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

Non-interactive websites generally can't be bound by laws of states outside the website's home jurisdiction, unless they are specifically targeting harmful actions toward a remote jurisdiction:

https://en.wikipedia.org/wiki/Personal_jurisdiction_in_In...

Bottom line, if you're a noncommercial distro, go shatter any download mirrors located in the People's Republic of California, and you should be good to ignore this. I doubt noncommercial distros will have to geoblock California. Maybe they'll want to -- I kind of do -- but they don't have to. Now, go get legal advice, go talk to a real lawyer, all of that, of course. But, I'm probably right.

OS age verification ...

Posted Mar 12, 2026 11:16 UTC (Thu) by gwojcieszczuk (subscriber, #93675) [Link]

I think it was Bryan Lunduke's video on youtube posted on 24th Feb 2026 that spread those news to wider community, not Aaron Rainbolt. Am I wrong?

My thoughts, as someone on the internet since I was WAY too young (~7 years old) and is now watching this unfold

Posted Mar 12, 2026 12:31 UTC (Thu) by jpeisach (subscriber, #181966) [Link]

A few things I'd like to say:

1) This is making it harder for children to find what they love.

If it wasn't for having access to a laptop, I would not have made my own virtual machines, Minecraft mods, and as a result, not found my love for computers and technology.

Access to a computer and the things you can do on it is very special. It allows people like me to go on sites like Wikipedia and YouTube, and explore what our interests are. The brain is still developing at this age, and my neurons have made their connections with this knowledge I have picked up. I am so glad that I had this opportunity, because now I am about to graduate high school, going into college with a great foundation in what I already know. And I have already done so much in the open source space, across so many projects. All that time could be wasted for future generations.

So anytime there is an attempt to place restrictions on people using technology, it mildly bothers me. I think that if a parent does their parenting, you don't have to worry about exposure to obviously bad content. It means one thing if this is a part of some online service, like YouTube, where it is trying to recenter content that is more appropriate (though, unfortunately, the kind of content you see on YouTube Kids is brainrot).

When you are bringing this to an **operating system**, then that makes everything harder to work with. If a young adolescent is interested in, say, rock music, then it can be difficult to listen to some songs because of the profanity, which is probably another thing that people want children to avoid seeing.

As for the "protect the children", maybe it should be "protect the children whose parents cannot tell them how to use the internet safely"? Just like a kid should know not to walk into a "bad neighborhood", they should know not to visit a "bad website".

2) The enforcement and "now what"

Developers can use the information, but then what? A calculator is still going to be a calculator. A movie application is still going to show movies. Even the example I just mentioned about music makes no sense, because how would you make sure each song is "clean"?

I think the ultimate goal of the bill was to make the politicians feel happy. They obviously have no idea about how easy it is to bypass age restrictions, and they certainly have no idea how an operating system works. Honestly, if someone makes a first log-in experience that asks for age, and then it closes and does nothing - not even save the data - that would be enough.

We will probably end up with video games refusing to open, or browsers refusing to access certain websites just based on whatever info is given. As for application developers, I honestly think they will do nothing. California is probably not going to spend tax dollars on running through each possible type of application, each implementation of said application, map out which is a "risk to children" and then take action.

3) If this does go into effect and is enforced, the D-Bus route is actually not bad.

It would prevent each application from needing their own verification system, and instead just give a source that can be referred to. This way, there isn't age information being stored in a million databases and decreases risk of said database being breached, which in my opinion makes this data more secure.

It's not a matter of OSS vs proprietary

Posted Mar 13, 2026 5:49 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (4 responses)

IMHO it's wrong to see this as an OSS-specific issue.

The issue is the lack of understanding of what a computer and what an operating system are. An operating system is just a piece of software that share resources between applications (RAM, storage, power, time, etc).

First, a lot of operating systems do not even have any user. Think about all the RTOS running in various home appliances like heaters, wash machines, music instruments, "smart" light bulbs, connected power plugs etc. You certainly don't want an ESP32-based light button to ask you your age when you press it. And whose age should a heater ask ? All people in the room ? And what if a minor enters the room ?

Second, a very large number of operating systems are automatically deployed without a human using them. Think containers/VMs used by CI/CD jobs for example, or many containers used to start network services. Who's the user there ? If I start Apache in a container, are visitors the users ?

Third, many operating systems support plenty of users, so the notion of download/installation of an OS/application etc has nothing to do with the user. What about enterprise or campus servers ?

Fourth, many operating systems are just not connected to the net. Some of the ones above are in this case, many internal enterprise servers as well, same for factory robots and machines. Do you imagine a concert where each member of the group asks all the ages of the attendees to start their synthesizer ? I'm purposely exagerating but it's to illustrate the total disconnection of this bill with reality. I think the authors confuse operating system and web browser because their only contact with a computer was their smartphone and they don't understand what is what on it. Not to mention the lack of understanding of the impacts on existing deployments. It's really pathetic.

Name and shame should be used there: every application, OS that has to block access to comply with this stupid bill should just indicate "in order to comply with censoring imposed by Mr XXX and his party YYY we're no longer allowed to let you use this application".

It's not a matter of OSS vs proprietary

Posted Mar 13, 2026 10:54 UTC (Fri) by jpeisach (subscriber, #181966) [Link] (3 responses)

As I said above, literally a popup window asking for an age is sufficient to please the politicians

It's not a matter of OSS vs proprietary

Posted Mar 13, 2026 11:16 UTC (Fri) by geert (subscriber, #98403) [Link] (2 responses)

Not all devices running an OS have a display (or display a web page, FWIW).

It's not a matter of OSS vs proprietary

Posted Mar 13, 2026 11:23 UTC (Fri) by jpeisach (subscriber, #181966) [Link] (1 responses)

> Not all devices running an OS have a display (or display a web page, FWIW).

Then as far as politicians are concerned, that is not a computer, LOL.

It's not a matter of OSS vs proprietary

Posted Mar 13, 2026 13:53 UTC (Fri) by wtarreau (subscriber, #51152) [Link]

> > Not all devices running an OS have a display (or display a web page, FWIW).

> Then as far as politicians are concerned, that is not a computer, LOL.

They're speaking about operating systems, not computers. It would be easier if they'd speak about computers, defining what they call as such.

Gutted by the 9th Circuit

Posted Mar 13, 2026 19:41 UTC (Fri) by songmaster (subscriber, #1748) [Link] (1 responses)

https://www.techdirt.com/2026/03/13/ninth-circuit-guts-ca...

Gutted by the 9th Circuit

Posted Mar 13, 2026 20:55 UTC (Fri) by jzb (editor, #7867) [Link]

Note that it is the "Age Appropriate Design Code" -- one of the laws that the "Digital Age Assurance Act" is supposed to support -- that was struck down. Not sure how this ruling might impact the age assurance law.

Why are we worried?

Posted Mar 19, 2026 15:22 UTC (Thu) by wpeckham (guest, #179663) [Link]

A Federal judge has already ruled in a Texas case that such a requirement without strict definitions is not constitutional for applications. I see no reason why it would suddenly be constitutional for an OS if it is not for applications.

I also see a problem with enforcement if the people, community, foundation, or company creating the OS or device has no presence or direct business in the state of jurisdiction. And what about devices, companies, or distributions that reside entirely outside of the USA? The distributions I use right now are homed in Ireland, France, Greece, and Germany.

I have to wonder if defaulting to the date 1 January of the 10th year previous would satisfy some of these laws? Currently 2016-01-01. (I really do NOT mind if sites I connect with think I am 10.)

Meta is being intentionnaly dumb

Posted Mar 26, 2026 17:19 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

The correct way to implement such a thing is to clearly define a (limited) set of legal age brackets in law and to have a public service that delivers "I am in the xxxx age bracket" time-limited (month ?) attestations. And then allow people to load those attestations in app and browsers. And forbid the remote querying of those attestations except for the cases mandated by law.

That would nicely protect users because the attestation is delivered separately, asynchronously, and contains zero private information (parents should make sure their kids can not copy the attestations like they make sure of a lot of other things, and distribution of attestation private copies should be prosecuted).

Do you think all Meta engineers are so dumb they can not conceive such a thing? Of course not. They just want either a totally broken system that absolves them from any responsibility, or a system completely controlled by a few corporations (themselves included), no scope limit between legal age check and pervasive privacy invasion, and nothing that would add friction to accessing toxic (high engagement!) material.

Meta is being intentionnaly dumb

Posted Mar 27, 2026 9:55 UTC (Fri) by kleptog (subscriber, #1183) [Link]

> a public service that delivers "I am in the xxxx age bracket" time-limited (month ?) attestations

Doesn't have to be a public service. Your bank/local council/insurance company/employer can all attest your age bracket. An app on your phone that scans your passport/ID card can do it. All you need is a standard mechanism to trigger them.

The issue is more that in the US people desperately hold onto the idea that they can be totally anonymous to everyone, including the government, while ignoring that businesses and the government amass your personal data in a non-transparent way. Which mean your birth date and other personal data is already spread around, but you can't actually derive any benefits from it. Worst of both worlds.

Better to have a structured system where you can view and verify what data people have about you, and then be able to use that for your benefit. Like the aforementioned attestations.