So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it.
-
@drahardja @david_chisnall Also, "coarse-grained" is nothing but theater. Frequently visited sites can determine a child's exact birth date by noticing when the API changes from returning "under 13" to "between 13 and 16."
@ieure @drahardja @david_chisnall Which makes it probably irresponsible for a parent to provide their child's real birth-date into this field that may be leaked to arbitrary untrusted parties.
-
@lerxst @david_chisnall Yeah, like 18 is not even standard across the globe.
@Arcaik 18 is the closest there is to a standard, due to the Convention on the Rights of the Child, which establishes 18 as the default age of majority (but stll allows it to be overridden by local laws). A curious example of another value leaking is how, because 16 used to be the age of majority in Netherlands for a long time, a lot of medical guidelines for trans youths, even in other countries, used to adopt 16 as an explicit age that a person would be able to consent to their gender (until the GOPnik bullies decided to start picking on trans women and children after the Oberge fell).
-
@Arcaik @lerxst @david_chisnall true. But the important is the country of child and whether he or she is considered adult in his own country by his own device. Until they are adults, it should require parent's consent.
@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.
-
@pemensik And how does this law change that?
The “parental controls” that exist today provides the same level of restriction as this law with less burden and fewer privacy issues.
@drahardja I think browsers should send underage header for every normal request, based on OS indication. Then instead of authenticating adults, rely on kids do not have powers to avoid sending such indication. If OS doesn't provide the information, we cannot make browser vendors sending it.
-
@pemensik And how does this law change that?
The “parental controls” that exist today provides the same level of restriction as this law with less burden and fewer privacy issues.
@drahardja I disagree existing parental controls have something similar. For example Windows controls won't work at all in Mozilla Firefox nor Google Chrome. This seems a way to fix it.
-
@david_chisnall So I also read the text https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB1043
I have MANY issues with how poorly defined many of the terms are in the document (e.g. is a website an “application”?), and how it still holds developers liable for verifying the provided age information (“internal clear and convincing information…that a user’s age is different”), but…
The part that to me implies implementation is that there is no leeway for the OS to *under*-report the account’s age group, e.g. reporting that a user is younger than they actually are—strictly, they are liable for civil penalties either way. This implies that the OS *must* collect the user’s date of birth and store it somewhere, and derive the age bracket from that date on a daily basis (like your algorithm says). This means that it’s not enough for a parent to set up an account as “13–16 years old” and leave it at that forever.
IMO the fact that the OS *must* collect a child’s birthdate to comply is an erosion of privacy.
@drahardja @david_chisnall The law says the OS must provide a way "to indicate the birth date, age, or both, of the use".
The only reasonable interpretation of this is that this is satisfied by asking for the "age" as just the year (because no reasonable person would expect the UI to ask for the user's age to day precision). But this makes the law kind of contradictory since you can't actually determine if someone is above 13, etc. merely from the age provided at account creation.
Maybe it's *intended* to be sufficient to just ask for an age (or a drop-down for each of these brackets) and rely on the parent to update this in the future as needed, but as you say that doesn't really seem to fit with how it's worded.
So yeah, just seems very poorly thought out in general.
-
@ieure @drahardja @david_chisnall Which makes it probably irresponsible for a parent to provide their child's real birth-date into this field that may be leaked to arbitrary untrusted parties.
@ids1024 @drahardja @david_chisnall Honestly, irresponsible for anyone at all.
-
@ids1024 @drahardja @david_chisnall Honestly, irresponsible for anyone at all.
@ieure @drahardja @david_chisnall For someone who is already an adult, if it just has these brackets it doesn't actually leak the age, only that one is an adult. Though it also serves no purpose.
II'd probably advise everyone to just enter Jan 1 1900 or Jan 1 1970 or something for all computers used by them or their children.
-
"I'm not convinced it takes that much bandwidth"
I regret engaging.@pkw AFAIK the issue is not the network bandwidth but how much the OS restricts underage users (children). Actually, according to @david_chisnall the #ageverification should be a totally local process, not even requiring network access. @AVincentInSpace
-
@pkw AFAIK the issue is not the network bandwidth but how much the OS restricts underage users (children). Actually, according to @david_chisnall the #ageverification should be a totally local process, not even requiring network access. @AVincentInSpace
I knew @pkw was talking about developer bandwidth, and I'm not convinced it takes much of that either.
-
I knew @pkw was talking about developer bandwidth, and I'm not convinced it takes much of that either.
@AVincentInSpace Oh, my! As a #nonNativeSpeaker I tend to miss those subtleties, I would have rather used the term "developer time" or at most "developing resources" @pkw
-
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'.
