Re: Age Verification laws
"Henry Miller" <[email protected]> Mon, 02 Mar 2026 20:54:08 -0600
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Mar 2, 2026, at 18:46, Aaron Rainbolt wrote: > On Mon, 2 Mar 2026 11:25:06 -0500 > Lucas Holt <luke@foolishgames.. > > While it's possible some states may require giving a date of birth, do > they require *storing* it? The original design I proposed provided the > APIs but left storage up to the individual implementation (this is of > critical importance to Whonix, which cannot store a date of birth on > disk due to fingerprinting concerns). If the only information that > needs to be returned from the API is an age bracket, is it enough to > accept a date, turn it into an age bracket, and then store only that? kids have birthdays. My 12 year old will soon change age group (depending on when the group starts, but 13 is a common start of a new group). > Some users in the thread have claimed that an age verification API such > as this would be illegal under other laws even though it's required by > some, so it may be essential to allow the feature to be turned off in > some manner (probably not as obvious as a "turn this off" button, but > others have suggested asking the user where they are located). > The law passed by California doesn't explicitly mention age-gating > content that I can see, it does explicitly mention exposing the user's > age bracket to developers so they can refrain from collecting data they > aren't legally permitted to collect. This is the primary reason I > proposed something based on D-Bus; it's probably the easiest thing for > web browsers to integrate with given that they already integrate with > other D-Bus services. Mediating access through a file on disk or a > bespoke daemon could be problematic for sandboxed applications (one > user in the thread mentioned that files can be passed through to > sandboxed apps, but to me that sounds very clunky and like it may go > wrong or expose more data than should be exposed). I don't know what > MidnightBSD's sandboxing situation looks like, so maybe this isn't a > concern for you. this is the important question. What are we stopping? if it is just tracking then I'm 3 years old (don't ask how I can have a 12 year old). However if this is stopping looking at other adult content I may or may not want a more realistic answer. The other question is how accurates we need to be. My 12 year old is perfectly able to install linux on a raspberry pi. I suspect half his classmates know the password to the family computer to change their age - and the rest will find a zero-day and bypass it (these spread very fast, one kid finds one they all know it in days). If there is concern about accuracy then forget it, only a cryptographic signature traceable to someone legally liable for the data can work. (very few people are enough of a cryptologist to design this - I'm not one) > I do like the idea of taking inspiration from Apple's implementation. > They seem like they're the most likely people to get it right. what is right? Apple meets the letter of the law in probably the best way we could. but the spirit I don't think any os can do it: we need the cyptographic system and that needs more than can be done this year. > Apologies if a lot of what i just said makes no sense in the context of > BSD, I'm not much of a BSD user.