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'.
-
@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
-
Kids are smart enough to get around age limits. Many parents don't understand tech enough to set them up correctly to begin with.
When lawmakers realize this doesn't really help in a few years, they will then demand that we begin uploading ID's. It'll be a small step since so many readily capitulated with the OS intrusion.
Honestly, our gov't supports genocide, illegal wars, and protects child abusers instead of prosecuting them. Why trust them?
@Jeramee @david_chisnall The government that made this age-range law is not the same government that started illegal wars.
-
@Jeramee @david_chisnall The government that made this age-range law is not the same government that started illegal wars.
@nicolas17 @Jeramee @david_chisnall Are you kidding?
-
@nicolas17 @Jeramee @david_chisnall Are you kidding?
@Andres4NY state vs federal?
-
@Andres4NY state vs federal?
@nicolas17 Have you seen who is the governor of the state that is proposing this? Have you seen who was AG of that state for half a decade (starting around 2011) who openly supported genocide? Both parties have happily supported the Epstein class. Pretending that there's some vast difference between the feds and states when it comes to this stuff is pretty wishful thinking.
-
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 shouldn't be allowed, as it creates a precident to intrude more into our peaceful lives. Fascism is sickening.
-
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 Does this law only apply to desktop OSes? I fail to see why my NAS needs an age api.
-
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
Я это вижу так, что в системе просто должен быть какой-то файлик, который будет хранить мою дату рождения, и все приложения смогут обратиться к этому файлику просто чтобы не спрашивать меня, есть ли мне 18. Условно, захожу я на страницу игры в Steam, на сайт секс-шопа, на страницу фильма с рейтингом 18+ на сайте кинотеатра. Я не хочу каждый раз вводить дату своего рождения. Будет удобно, если это можно будет как-то автоматизировать. Но опять же, я не вижу причины, почему это должно быть делом государства. Это задача инженерная, а не юридическая. -
@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.
-
undefined oblomov@sociale.network shared this topic
-
@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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@francommit ancora una cosa, se metto un apparecchio fisso sul tetto, esso farà solo da router/ripetitore in quanto il bluetooth del telefono non arriva fino lassù (nel mio caso tre piani) quindi i messaggi verranno hoppati al mio apparecchio "mobile".
Il nodo router/ripetitore avrà un suo identificativo e dovrò configurarlo prima di installarlo sul tetto.
Posso utilizzare la stessa app per configurare due apparecchi? (ricevere solo da uno, quello " mobile")? @snow @lgsp @andre123 @gecco
-
@snow @ilarioq @lgsp @andre123 @francommit ma mi era parso di capire che collegando il nodo a internet serve per coprire le zone che altrimenti non sarebbero coperte. Non ricordo esattamente dove l'avevo letto ma mi pare fosse così.
Dove ho intenzione di mettere il nodo (in cima all'edificio dove lavoro) non arriva nulla (tranne un nodo che è comparso ieri pomeriggio e poi è sparito) e se nel futuro compaiono altri nodi allora lo scollego da internet.
-
Puoi farlo, sì.
Ma prima capiamo cosa succede davvero.Se nel punto dove hai messo il nodo non ricevi praticamente nulla via radio, metterlo come router non serve.
Un router mesh ripete solo quello che sente.
Se non sente nodi LoRa… non ha nulla da ripetere.Collegarlo al Wi-Fi con MQTT non lo trasforma in “ponte radio”.
Lo trasforma in un gateway Internet.Quindi:
* via radio → inoltra solo ciò che riceve via radio
* via MQTT → scambia traffico con altri nodi collegati a InternetHa senso farlo router con MQTT solo se:
* vuoi fare da ponte tra rete radio locale e rete Internet
* sei in una zona dove almeno qualche nodo radio arriva
* vuoi creare un punto di accesso stabile h24In breve:
Un router non crea copertura dal nulla.
Estende ciò che già riceve.La copertura si crea con posizione, antenna e altezza.
Non con una spunta nell’app 😉
-
@gecco Qui a Milano è un po' un casino, purtroppo.
-
@kenobit io ti consiglierei la bici :)
-
@snow @ilarioq @lgsp @andre123 @francommit ti chiedo una precisazione a riguardo, una precisazione a cui non ho trovato risposta.
Visto che da dove ho messo il mio nodo non prendo praticamente nulla, potrei mettere il mio nodo come router e attaccarlo al wifi con mqtt? Cioè si, posso farlo :) ma ha senso farlo per coprire una zona non coperta? E' questo il senso di configurarlo così?
-
Tienilo come **client** 👍
Anche in modalità client il nodo può comunque ritrasmettere i pacchetti che riceve dai nodi vicini.
Non è “muto”.La differenza è che il router è ottimizzato per fare infrastruttura:
priorità più alta nel forwarding, pensato per stare acceso h24 e sostenere traffico continuo.Se il tuo nodo:
* non è in posizione dominante
* non è fisso
* non resta acceso sempre
* non vede molti altri nodi con buon segnaleallora deve stare in **client**.
Diventa router solo se un giorno lo metti in alto, fisso, acceso 24/7 e con buona visibilità radio.
In una mesh servono pochi router ben piazzati, non tanti messi a caso 🙂
-
@kuechenlatein @freuwesen habs gefunden. ist ein generelles problem, das nur durch rank math sichtbar wurde!
ich arbeite an einem fix!
