CassandrichI want someone (a real collaborator, not one of y'all as a joke) to try submitting a patch to musl adding a pw_dob field to struct passwd. I will roast and reject.
Ariadne Conill 🐰
@dalias I don't even want to figure that law out right now
@dalias my personal view is that most of fedi is rejecting a boogeyman created by lunduke
the california law is clearly intended for consumer OS with cloud services and app stores.
but importantly it has quite a few features that seem desirable
- the assured age bucket is configurable by the device owner
- it is not verified with third party services like persona
- app developers have to accept it as a valid age verification unless they have direct knowledge that the age verification is invalid (!)
the latter seems actually to be good, as there is less personal data processing happening. it makes it illegal for app developers to demand ID, they have to accept the attested signal.
I don't even know what shape, if any, compliance for a distro would look like, but most likely that information wouldnt be stored in /etc/passwd anyway.
most likely we would just have a daemon that generates attestations based on a configured age bracket. no libc changes needed 😵💫
Jackie@dalias @burnoutqueen my points are
- the law is not targeted (as in intention) at FOSS projects
- a compliant OS can simply generate any signal it wants and remain compliant with the law
- people are vigorously debating the law as represented by Bryan Lunduke, a known chud
Val Packett 🧉@ariadne @dalias @burnoutqueen
- everyone keeps repeating VERIFICATION VERIFICATION VERIFICATION but the referenced laws EXPLICITLY DO NOT propose verification, it's a SIGNAL
@ariadne @burnoutqueen @valpackett But requiring signaling is a step towards requiring verification, and doesn't meet the needs of someone who doesn't even want signaling (maybe because they don't want to have to lie, or because of risk of exposure).
@burnoutqueen @valpackett @dalias sure. but given this I think it isn't a problem for traditional distro unless california says they want to sue distros.
Tiota Sram@ariadne @burnoutqueen @valpackett @dalias there's an obvious alternative move here: just say "users in California shouldn't download this distro" on your website. IANAL but I've seen at least one serious org take this stance. If you want to build political resistance to verification (which is clearly the writing on the wall and which is already mandated for other things in some jurisdictions) this is the way to go. Instead of explaining to each other how this isn't really such a big deal because it's only a signal, not verification, force the ones passing the laws to explain that themselves in response to "California bans Linux" articles. Then you put them in a position where you can follow up with "this is clearly just a pretext to make verification easier to mandate in the future, and/or could be used as such by a future administration with worse goals, so I don't mind you banning me over this."
As a bonus feature you help users get practice at ignoring oppressive laws (and they're not even liable anyways, so it's not a crime for them to ignore your disclaimer and download it).
It's the fact that developers (in some cases without proper community input) are choosing the compliance path over this *actually simpler-to-implement* path that's galling, especially if they say "this needs to be opposed but for now we'll comply" since they've chosen a harder path to compliance that undermines political opposition.