So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
Pretty sure the law **requires** all apps (not just web browsers) to query for a signal, otherwise the Dev is in violation.
I don't see a requirement for the app to actually show age-inappropriate content to a minor. Even a completely kid-friendly app would violate the law.
-
Pretty sure the law **requires** all apps (not just web browsers) to query for a signal, otherwise the Dev is in violation.
I don't see a requirement for the app to actually show age-inappropriate content to a minor. Even a completely kid-friendly app would violate the law.
It's not clear (and probably should be clarified), but that's not how I read 1798.501(b). I interpreted it as 'if a law requires you to do some age-related blocking, you must use this API and not something else', which seems to be a laudable intent (in particular, it prohibits asking for passports and so on for age verification). In particular, 1798.501(b)(4) seems to indicate that this was the intent.
EDIT: Note that, in my proposed groups-based approach, it would be trivial for CRT initialisation to query group membership. That would automatically meet your interpretation of the requirement (being required to query it but not being required to do anything with the data is largely indistinguishable from not being required to query it). An OS could even put these values in the ELF aux args vector to make sure that every application 'queries' the data if that's how a judge would interpret it.
But also note that the law provides penalties for operating systems that do not provide the API, but no penalties for applications that do not comply. This, I presume, is because the intent is for those to be delegated by other laws that require age verification for specific purposes (some of which already exist).
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
@david_chisnall
Some people seem to interpret the bill as stating that every application would have to use the API every time it is run (but why would it if it has no use of age information to “comply with applicable law”?).
California’s AB 1043 Could Regulate Every Linux Command, and the Open Source World Is Too Quiet
California's Digital Age Assurance Act (AB 1043), approved by Governor Newsom in October 2025, sets out a statewide age assurance framework for operating systems and app stores. It requires operating system providers to present an age and date-of-birth declaration interface during account setup and to provide an API that can return an age bracket signal…
Open Source Guy (shujisado.org)
-
It's not clear (and probably should be clarified), but that's not how I read 1798.501(b). I interpreted it as 'if a law requires you to do some age-related blocking, you must use this API and not something else', which seems to be a laudable intent (in particular, it prohibits asking for passports and so on for age verification). In particular, 1798.501(b)(4) seems to indicate that this was the intent.
EDIT: Note that, in my proposed groups-based approach, it would be trivial for CRT initialisation to query group membership. That would automatically meet your interpretation of the requirement (being required to query it but not being required to do anything with the data is largely indistinguishable from not being required to query it). An OS could even put these values in the ELF aux args vector to make sure that every application 'queries' the data if that's how a judge would interpret it.
But also note that the law provides penalties for operating systems that do not provide the API, but no penalties for applications that do not comply. This, I presume, is because the intent is for those to be delegated by other laws that require age verification for specific purposes (some of which already exist).
@david_chisnall
I am not a legal expert but both 1798.501 a and b seem to use the same language to me. I don't find b4 as incompatible with requiring a request to be made.As for the penalties are they not set out at 1798.503 a? There it says "a person that violates" while on b which is good faith exceptions clearly spells out OS and app stores' providers.
I suppose it could also be a clarification not a contradiction.
It's good that there could be a mechanism to protect Foss developers.
-
@david_chisnall
I am not a legal expert but both 1798.501 a and b seem to use the same language to me. I don't find b4 as incompatible with requiring a request to be made.As for the penalties are they not set out at 1798.503 a? There it says "a person that violates" while on b which is good faith exceptions clearly spells out OS and app stores' providers.
I suppose it could also be a clarification not a contradiction.
It's good that there could be a mechanism to protect Foss developers.
Of course, my POV is very suspicious of the intentions of such initiatives and their goals in the 1st place.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
@david_chisnall I'm not going to spend the time to disassemble every bogus argument "for" bad legislation advancing fascist ideology.
I'm just going to say flatly that it's bad legislation written by the ignorant who intend to advance fascist surveillance.
And anybody defending or implementing it has declared themselves an enemy of freedom and democracy.
-
@david_chisnall I'm not going to spend the time to disassemble every bogus argument "for" bad legislation advancing fascist ideology.
I'm just going to say flatly that it's bad legislation written by the ignorant who intend to advance fascist surveillance.
And anybody defending or implementing it has declared themselves an enemy of freedom and democracy.
I'm going to guess that you haven't read the law, since it is explicitly written to eliminate the need for the kind of privacy-invasive age verification things that you (and I) object to.
-
I'm going to guess that you haven't read the law, since it is explicitly written to eliminate the need for the kind of privacy-invasive age verification things that you (and I) object to.
@david_chisnall yes, I have. And under absolutely no circumstances whatsoever is there any valid or legitimate reason to demand someone's age except to surveil or come back later mandating it be tied to other identifying information. Period.
I worked for a VERY short period for a company you've never heard of which is VERY involved in this shit. They can EASILY tie you to things with your DOB and IP address alone.
-
@david_chisnall yes, I have. And under absolutely no circumstances whatsoever is there any valid or legitimate reason to demand someone's age except to surveil or come back later mandating it be tied to other identifying information. Period.
I worked for a VERY short period for a company you've never heard of which is VERY involved in this shit. They can EASILY tie you to things with your DOB and IP address alone.
They can EASILY tie you to things with your DOB and IP address alone.
Which is partly why the law doesn't allow disclosing the DoB to applications, and instead gives them a 2-bit signal, where one of the states is 'over 18'.
-
They can EASILY tie you to things with your DOB and IP address alone.
Which is partly why the law doesn't allow disclosing the DoB to applications, and instead gives them a 2-bit signal, where one of the states is 'over 18'.
@david_chisnall and you think they can't ID you from that alone? You think it's going to stop there? Because it's not, period. It has never once stopped there in the history of forever.
"Oh the kids are faking it." -> MUST provide actual valid ID which is verified.
"They said they're over 18 but visiting Roblox." -> It's Junior
"They didn't set over 18 but they're visiting bank XYZ." -> It's Mom.
-
@david_chisnall and you think they can't ID you from that alone? You think it's going to stop there? Because it's not, period. It has never once stopped there in the history of forever.
"Oh the kids are faking it." -> MUST provide actual valid ID which is verified.
"They said they're over 18 but visiting Roblox." -> It's Junior
"They didn't set over 18 but they're visiting bank XYZ." -> It's Mom.
Add to that the delight of
Are you over 18 today? No
[next day] Are you over 18 today? yesSurprise, they have your DOB.
-
@pkw I'm not convinced it takes thay much bandwidth, and as for need, I mean, legal compliance is pretty important
The definitions seem a bit poorly thought out.
I have a good dozen computers in my house with various degrees of modifiablity. While some run OSes I can modify, some are retrocomputing devices too old to get updates and "smart" TV/appliances that I can still use to access the internet, but have no ready means to add "age verification" functionality to.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
The problem is that even the mere existence of such a thought, this “absolute salvation” of children, is tiresome. They need to tell it like it is once and for all and admit that they would like to achieve something else, period.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
@david_chisnall even setting aside the (il)legitimacy of age-gating the Internet, its vastly more problematic than that, for reasons I find obvious from the text of the law:
- who is an OS developer?
- if I contribute a package to Fedora or Debian or Alpine, am I an OS developer?
- which developers are liable if Fedora does not include an age field?
- am I liable if I contribute a package to a distribution that does not include an age field?
- what if I create a customized live image and share it with my friends? Am I an OS developer?
- what is a covered application store?
- is dnf or apt a covered application store?
- is the remote dnf or apt or apk repository a covered application store?
- is dnf supposed to use root’s age, the admin user’s, or the user who invoked sudo?
- is everyone who provides apt repos now responsible to do something with an age gate?
- is github a covered application store?
- is ubi/aqua/mise? Are they responsible for locally routing this age information, or for providing it to github when they download release binaries?It’s a law that was clearly written with no understanding of software distribution outside of Apple / Google / Microsoft / Steam, with extremely broad definitions of who may be liable.
In addition to advancing a fundamentally censorious view of internet safety.
-
@pemensik You forget that a typical Big Tech TOS includes a venue clause, specifying that the laws of wherever their headquarter is apply to the contract.
@riley @Arcaik @lerxst @david_chisnall sure, but I think it is not, should not be, about vendor HQ legal entity. Child should follow law of theirs guardians, not device vendor. If they live in a country with full independence in 21, okay. That information is needed for localisation and wireless protocols. Those are the only relevant. I cannot influence MS, but can do something on open systems, Linux distributions. Let's focus on those.
-
Yes, having extra groups and special files seems overkill for this. And the browser can easily query the data for its own user.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
@david_chisnall I am a parent with two young children.
I do not want a store or a website or anything else making decisions about what they do or do not show my child based on their age, with or without attestation or operating system support.I do want websites and stores to tell me what they would like to show and/or sell to my child, so I can decide whether or not it's appropriate.
-
So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it. It requires operating systems to let you enter a date when you create a user account and requires a way for software to get a coarse-grained approximation of this that says either 'over 18' or one of three age ranges of under-18s. Importantly, it doesn't require:
- Remote attestation.
- Tamper-proof storage of the age.
- Any validation in the age.
In short, it's a tool for parents: it allows you to set the age of a child's account so that apps (including web browsers, which can then expose via JavaScript or whatever) can ask questions about what features they should expose.
In a UNIX-like system, this is easy to do, with a tiny amount of new userspace things:
- Define four groups for the four age ranges (ideally, standardise their names!).
- Add a
/etc/user_birthdaysfile (or whatever name it is) that stores pairs of username (or uid) and birthdays. - Add a daily cron job that checks the above file and updates group membership.
- Modify user-add scripts / GUIs to create an entry in the above file.
- Add a tool to create an entry in the above file for existing user accounts.
This doesn't require any kernel changes. Any process can query the set of groups that the user is in already.
If a parent wants to give their child root, they can update the file and bypass the check. And that's fine, that's a parent's choice. And that's what I want.
I like this approach far more than things that require users to provide scans of passports and other toxically personal information to be able to use services. If we had this feature, then the Online Safety Act could simply require that web browsers provide a JavaScript API to query the age bracket and didn't work unless it returned 'over 18'.
@david_chisnall you are a traitor
You are implementing repression in free software before being forced to do so.
General operating system software should not need to know all of this.
Leave all of this to the proprietary world.
We have to fight for the future and for our freedoms, not just abide to whatever fascist government forces onto us.
-
@lattera My understanding is that any process can query this and the goal is to not give processes the user's date of birth. The four groups model means that apps don't see the date of birth for any adult user, and have to be running before and after the group membership changes to be able to infer the date of birth for children.
-
R relay@relay.infosec.exchange shared this topic
