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
-
@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.
-
@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.
(opens arms)
-
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 oh, I think this is *almost* the correct thing to do. I think underage indication is a way to go. But parents should be able to select sites with more precise age group. By default it should be only true/false. To make advertisement targeting a bit less specific. For example only sites over 13 need better indication. Parent should know sites his kid has account on. Or block some of 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'.
@david_chisnall no, there is no need for periodic actions. Store kids birthday in the system, but provide API telling apps only age group, unless the app is whitelisted. Birthday or birth year on the local device should not be too sensitive to store.
-
@lerxst @david_chisnall Yeah, like 18 is not even standard across the globe.
@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.
-
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'.
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?
-
What about an OS that doesn't want to or have the need to or the bandwidth
to do that ?@pkw @david_chisnall you as a parent won't buy it for your children or take the responsibility for it. All it needs is clear indication that system has underage accounts support.
-
@david_chisnall We already have parental controls in many OSes. Why do we need a law that specifies a particular implementation?
@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.
-
@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.
-
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's bullshit
-
"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?
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!
