So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it.
Uncategorized
85
Posts
56
Posters
1
Views
-
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'.
-
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 And then another state or country passes a law that requires four age ranges, or another one that requires two, but they do not map nicely to the three CA requires.
You have now replicated another timezone mess.
-
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'.
-
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 nice feature to have in an OS. Not so nice feature to have because of a law.
-
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 given the general trajectory and past instances of the public giving an inch and legislators taking a mile, it still makes me deeply uncomfortable.
-
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 We already have parental controls in many OSes. Why do we need a law that specifies a particular implementation?
-
@david_chisnall We already have parental controls in many OSes. Why do we need a law that specifies a particular implementation?
@drahardja The law doesn't specify a particular implementation, it specifies only that:
- They must exist.
- There must be some documented API to get the age range.
In particular, it doesn't specify what that API is, but does specify that it must be coarse-grained (giving no more information than the four age ranges, and not giving the precise age or date of birth).
-
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'.
My main worry that it will be some sort of gateway for further age verification creep. We're seeing this in the UK where the OSA, having failed to achieve any of its actual objectives (as many of us predicted a few years ago), is now being extended to incorporate broader-scope social media bans and even VPN bans.
Similarly the AV lobby could say that simple age attestation isn't accurate enough and start to demand more intrusive monitoring. Idk if that's far-fetched (maybe it is), but the situation in the UK does not make me hopeful for these kinds of laws
-
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 parental controls on most things are really broken - just badly thought through - lacking integration with each other - and plain buggy.
I think that effective regulation which actually required well functioning parental controls would be a game changer.
-
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'.
And then next year or the year after they require positive proof of identification to install an OS. And Raspberry Pi s become Illegal for anyone who lacks a Certificate of Need.
What could Possibly go Wrong?
-
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 going to disagree. Very vehemently.
This is just a foot in the door to surveillance. You of all people should know better than to defend this.
Sure it's this now, but at some point, it will become like every other system so far.
-
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 So we build yet another layer for users to select Jan 1st, 1970?
Seems like an enormous waste of time.
How about parents parenting?
I agree with you building something that is easy to bypass and doesnât require storage of PII is much better than the uploading of secure documents but in this case not making a change is also superior.
Parents adding their children to the sudoer list? Does any parent capable of this require an age verification system to assist them?
-
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'.
Local filtering is definitely the way to go here. Do I want parental controls to be legally mandated? Ehhh... Do I want to hand over my ID to 50 companies just to use the internet? Absolutely not.
It seems like the lawmakers actually thought about the privacy implications: Only 2 bits of information are ever disclosed and there's nothing stopping you from putting in a fake data (or rm-ing the file...).
Although I do think it should be implemented as a list of allowed content instead of an age: Having nothing allowed before 18 and everything allowed the day after seems arbitrary to say the least.
-
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 @dangoodin it doesn't require that *yet*.
-
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'.
It also covers:
1798.500 (e) (1) âCovered application storeâ means a publicly available internet website, etc..So, a private forgejo site could be held liable for every download of curl. I mean, if they didn't trap for an age signal that isn't defined yet by the law. If the store serves apps and libs, or software that are dependencies, then that is a huge legal mess waiting to hit a small project or solo dev at $2500-7500 a download.
-
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 don't believe they will stop legislating computer usage with this law. Do you?
-
@drahardja The law doesn't specify a particular implementation, it specifies only that:
- They must exist.
- There must be some documented API to get the age range.
In particular, it doesn't specify what that API is, but does specify that it must be coarse-grained (giving no more information than the four age ranges, and not giving the precise age or date of birth).
@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.
-
@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.
@david_chisnall In fact the text says so:
â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 for the purpose of providing a signal regarding the userâs age bracket to applications available in a covered application store.â
REQUIRES is the key word here. There is no reason why a birthdate (or age, but I donât know how an OS provider can *strictly* comply with this bill without the actual birthdate) is needed to create an adult account, but it will still be required.
Canât wait to enter my birthdate into my Samsung Smart Fridge (it has apps, so itâs an OS, maybe, probably). Surely it wonât be abused in any other way.
Ironically, the bill says that the OS provider âshall not share the digital signal information with a third party for a purpose not required by this titleâ but says nothing about sharing the actual birth date that I entered.
This is not a good bill.
-
It also covers:
1798.500 (e) (1) âCovered application storeâ means a publicly available internet website, etc..So, a private forgejo site could be held liable for every download of curl. I mean, if they didn't trap for an age signal that isn't defined yet by the law. If the store serves apps and libs, or software that are dependencies, then that is a huge legal mess waiting to hit a small project or solo dev at $2500-7500 a download.
That means a lot of open source app stores may need to be completely reworked. And forges/repos. And every bit torrent client.
Dependencies on apps that also double as non-covered applications now will need to be age gated.
Developers will need to know their legal liabilities in distributing every single executable they publish.
So, depending upon who is enforcing it, this shouldn't be a problem. đ«
-
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 That's surprisingly not that horrible.
For /now./
Still a bad precedent to set, though.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@gecco Qui a Milano Ăš un po' un casino, purtroppo.
-
@kenobit io ti consiglierei la bici :)
-
@kuechenlatein @freuwesen habs gefunden. ist ein generelles problem, das nur durch rank math sichtbar wurde!
ich arbeite an einem fix!
-
@gecco figo!
-
@kenobit esatto, poi la de marchi sta a max 700 metri da casa tua ;)
-
Anche Gaza paga il prezzo della guerra allâIran. Israele chiude i varchi, il cibo scarseggia
@news
https://www.eunews.it/2026/03/03/anche-gaza-paga-il-prezzo-della-guerra-alliran-israele-chiude-i-varchi-il-cibo-scarseggia/
Nella Striscia non entrano rifornimenti da sabato 28 febbraio, giorno del lancio dell'offensiva di Tel Aviv e Washington contro Teheran. World Central Kitchen: "Impatto immediato, non ci sono riserve". Oggi potrebbe riaprire il varco di Kerem Shalom
-
@pablitoeldrito azz, Ăš vero. Vado a informarmi, potrei iniziare.
-
@francommit ah grazie non avevo capito nulla! @snow @lgsp @andre123 @gecco
