So, I have actually read the text of California law CA AB1043 and, honestly, I don't hate it.
-
@pkw I'm not convinced it takes thay much bandwidth, and as for need, I mean, legal compliance is pretty important
"I'm not convinced it takes that much bandwidth"
I regret engaging.
-
"I'm not convinced it takes that much bandwidth"
I regret engaging.@pkw If your operating system has one developer and one user, it's a project of a couple hours to write a daemon that always returns an "18+" signal. If your project has one developer and a number of users, you add systemd-birthdaysd to your standard distribution and have done with it. If your name is Suckless, you write your own daemon to parse /etc/passwd and it takes you a couple weeks tops.
We can have a separate discussion about whether we're being frogboiled into accepting a surveillance state. But "what if I don't want to" is not an excuse.
-
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 Is your impression that this law was specific enough to apply only to desktops? Not servers, not appliances that create users?
-
@david_chisnall It doesn't matter how inoffensive it might seem now. 1) It won't remain that way, and 2) politics and politicians should not be designing nor mandating requirements in software when maybe 1 in 10,000 of them have any understanding whatsoever of how what they're dabbling in works (and, perhaps more importantly, often fails to work).
The formerly lesser-evil Democrats in their misguided zeal to legislate utopia, now by dabbling in technology design, are pushing me into the arms of the anarchists.
@kramaker I quite like this text on how best to practice anarchy in software development https://applied-langua.ge/software-and-anarchy.pdf
-
@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.
@drahardja @david_chisnall What about devices that have more than one user? E.g. Library computers, or family laptops, or “smart” home appliances?
-
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 Now automatically deploy 5000 instances that do that. Spin up 20000 container instances, pods which are dynamically created and destroyed every 30 seconds. It's idiotic technically illiterate nonsense written by simpletons for the clueless.
-
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 The problem is of evolution: once this stage is normalised, the next is for that first age entry to actually become full age verification. Is a slippery slope. It’s the same problem that’s going to occur with Apple’s recent age verification addition in iOS.
-
@pinepotpourri @david_chisnall It goes beyond that. Maybe a parent shouldn't have absolute control of their kids. Maybe they shouldn't be able to prevent their LGBT child from finding out that they aren't monstrous freaks, all alone in the world, and there are others like them, living happy lives, just to give one example.
-
@pinepotpourri @david_chisnall It goes beyond that. Maybe a parent shouldn't have absolute control of their kids. Maybe they shouldn't be able to prevent their LGBT child from finding out that they aren't monstrous freaks, all alone in the world, and there are others like them, living happy lives, just to give one example.
@not2b Honestly yes, but without precautions, children can be put into far more danger than just "who am I?," as a gay I understand what you mean but I also feel that self confidence comes from the soul, not from those around you?
-
@drahardja @david_chisnall What about devices that have more than one user? E.g. Library computers, or family laptops, or “smart” home appliances?
@nolitimere @david_chisnall Yep. What about kiosks?
-
@drahardja @david_chisnall nope, I don't think we have something similar. What can stop 13 years old kid to create a new account parent doesn't even know about? Can Windows or Android prevent that? Can non-IT parent configure it? I don't think so.
@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.
-
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 nope
-
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 Or just don't start adding unneeded user verification processes. There's nothing more needed than a UID and a way for them to secure their account themselves using systems they themselves have control over, and none of that requires any form of PID. Least of all their age.
-
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'.
-
@drahardja @david_chisnall Tizen OS - a Linux based OS by Samsung.
Hold on, need to verify my age so I can open my fridge and drink my Mountain Dew Verification can before losing access to my devices.
@pwloftus Is this the straw man engineering department?
-
@david_chisnall nice feature to have in an OS. Not so nice feature to have because of a law.
@avuko @david_chisnall
Nice feature to be a web standard so parents can block adult websites easier (of course, sure, I know from experience, children will find bypasses) and for adults not to have to answer for the 1000th time that they are adults just to check a Steam page or something like this.
But not a law. -
@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 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."
-
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
systemd-birthdayd:^) -
@pwloftus Is this the straw man engineering department?
@txtx @david_chisnall It’s the Reduced Absurdity Dept. The Staw Men are down the hall
-
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 this seems to infringe on the rights of children who don't want to be identified as a child? And this also perpetuates power imbalances as a parent can limit what the child does. I disagree with this post and wish the worst on you. I am sending you an immense amount of negative energy now
