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
-
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.
-
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 One problem with the law is that one section says: “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application. But another says: A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
It's confusing (more)
-
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 no, just no
-
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@infosec.exchange
That is a brilliantly simple, and sensible way to approach this. Let parents/guardians to set things up for their kids.
But the issue politicians will find with this approach right away is that it gives control away. We can't have that. It is governments' job to parent kids, not parents' job. -
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'.
What about an OS that doesn't want to or have the need to or the bandwidth
to do that ?
-
@david_chisnall One problem with the law is that one section says: “Covered application store” does not mean an online service or platform that distributes extensions, plug-ins, add-ons, or other software applications that run exclusively within a separate host application. But another says: A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.
It's confusing (more)
@david_chisnall ... to add some more: I have some Java applications such as a graphics editor that lets you draw curves and can convert those into inputs for other programs. You need /bin/sh and java to run it. So is it an application or just a plug-in according to this law? The only thing in it not appropriate for a child are terms in the documentation like "principal axes" and "affine transformations". I bet the lawyers who wrote the law would have trouble with those terms too.
-
What about an OS that doesn't want to or have the need to or the bandwidth
to do that ?@pkw @david_chisnall doesn't have the bandwidth to...store a file of birthdays and run a service to allow programs to query the user's 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'.
@david_chisnall All of this assumes good faith on the part of the website. But, if you are a predator looking for children, why wouldn't you actively seek out this signal? I have to be honest, there are way too many bad faith actors for me to see this as a good idea.
Some of them are lawmakers themselves. Here in the US, we don't manage to prosecute them.
-
@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.
@lerxst @david_chisnall Yeah, like 18 is not even standard across the globe.
-
@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 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.
-
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 posted an implmentation for Fuzix in an include file yesterday. However it will turn into a nightmare once you've got 200 conflicting jurisdictions and querying some of them in other locations is a violation of local law 8)
-
@Lemmus @david_chisnall Well, they can pry my general purpose computing devices from my cold, dead, arthritic hands.
-
@pkw @david_chisnall doesn't have the bandwidth to...store a file of birthdays and run a service to allow programs to query the user's age?
"doesn't have the bandwidth to...store a file of birthdays and run a service to allow programs to query the user's age?"
Correct. Does not have the bandwidth or need or desire to change their OS to
do that. That was my question.
-
@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.
There are multiple humans with the same legal name and everyone hates giving what they think is real identifying information, so to look someone up in local police databases they use the birthday to tell you apart.
-
@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?
This is just 2FA all over again. Some #Boomer that's a federal judge says, ''you can't follow them until you have two confirmed data points,'' then the plaintiff/defendant runs around with their new two-factor identity service.
🤷 
-
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 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.
-
"doesn't have the bandwidth to...store a file of birthdays and run a service to allow programs to query the user's age?"
Correct. Does not have the bandwidth or need or desire to change their OS to
do that. That was my question.@pkw I'm not convinced it takes thay much bandwidth, and as for need, I mean, legal compliance is pretty important
-
@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 "(or age, but I don’t know how an OS provider can *strictly* comply with this bill without the actual birthdate)"
If you're 18+ then age is enough, since your bracket will not change over time.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
3 marzo 1993: muore Albert Sabin
@anarchia
di Bruno Lai. Scopritore del vaccino che sconfisse la poliomielite: non volle arricchirsi con i brevetti. Albert Sabin (1906-1993). Albert Sabin è una delle figure più affascinanti della medicina del XX secolo, non solo per il suo contributo scientifico, ma...Vedi l'articolo
https://www.rivoluzioneanarchica.it/3-marzo-1993-muore-albert-sabin/
-
Quello che mi stupisce di più in tutto questo è che Prodi festeggi la fine del Ramadan, visto che è appena iniziato... 😁
-
## 📡 Non è un giocattolino. È radio. Punto.
A prescindere dai miei 30 anni passati sui ponti radio.
A prescindere dalla patente da radioamatore dal ’95 (ok, nominativo scaduto… ma il cervello no).Quando vedo qualcosa di nuovo, non mi metto a premere pulsanti a caso come fosse l’ennesima app per chattare con gli amici.
Mi documento.
Perché **LoRa non è “messaggini simpatici via Bluetooth”**.
È una tecnologia radio seria. Con fisica, limiti normativi, parametri tecnici e responsabilità.Se vogliamo fare le cose in modo utile — non folkloristico — si parte dalle basi:
👉 https://www.loraitalia.it/wiki/cose-lora/
---
## ⚙️ Cos’è davvero LoRa
LoRa non è un social.
Non è WhatsApp in montagna.
Non è “ah guarda che figo, mi vedo sulla mappa”.È una modulazione radio a spettro espanso (Chirp Spread Spectrum), progettata per:
* coprire grandi distanze
* consumare pochissima energia
* lavorare in banda ISM 868 MHz
* rispettare il famoso **duty cycle 1%**Quel famoso 1% che molti ignorano, ma che significa:
> puoi trasmettere solo per 36 secondi ogni ora su quella frequenza.
Non è un dettaglio.
È ciò che distingue chi gioca da chi capisce cosa sta facendo.---
## 🧠 Nodo, rete, copertura
Un nodo non è “una chat portatile”.
È un elemento di una rete mesh.
Può fare da router, da client, da infrastruttura.
Può estendere copertura.
Può collegare zone isolate.Ma per farlo bene devi sapere:
* dove lo metti
* che antenna usi
* che altezza hai
* che ostacoli hai intorno
* che parametri radio stai impostandoNon è magia. È propagazione.
-Se l’obiettivo è “scrivere ciao dal divano”, va bene tutto.
Ma se l’obiettivo è rendersi utile, creare copertura reale, fare rete, costruire qualcosa che rimanga, allora si studia.
Si parte dalla documentazione.
Si capisce cosa si sta usando.
Si rispettano le regole radio.Poi si monta l’antenna.
Io non sto abbandonando nulla.
Sto solo facendo quello che ho sempre fatto quando si parla di radio:
Prima capire.
Poi trasmettere. 🙏
#MESHTASTIC
-
@meatlotion wow, it's beautiful!
-
@stefano the view from my bedroom window. Not as colourful, but definitely as hopeful.
-
📬 NicFab Newsletter #10 | March 3, 2026
Privacy, Data Protection, AI & Cybersecurity — weekly review.
In this issue: EU enforcement actions, EDPB developments, cybersecurity alerts, and AI Act analysis.
👉 Read the full issue: https://www.nicfab.eu/en/newsletter/2026-03-03-issue-10/
📩 Subscribe: https://www.nicfab.eu/en/pages/newsletter/#subscribe-now
#Privacy #GDPR #DataProtection #AIAct #Cybersecurity #InfoSec
-
@antonemma infatti io NON uso Microsoft ma esclusivamente #Linux e #SoftwareLibero. In particolare ho ancora una TV tradizionale che però uso come monitor multimediale collegato ad un #Raspberrypi con kodi.tv. Non c'è collegato niente altro
-
@esna@serafuku.moe 이미 國漢文混用體로 쓰고 있습니다. 😎
