Re: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states

Agreed. Unless someone's living depends on it, it's definitely better to 
try to push back against this legislation.

More broadly, a good question to ask would be: To what degree could 
someone be held liable for passively distributing (by putting on the 
Internet for others to download, if they so wish) GPL-/BSD-/freeware 
licensed products, which are perfectly legal in their own jurisdiction, 
in a different jurisdiction? It's ridiculously difficult (practically 
impossible) to know all laws of one's own jurisdiction, let alone of all 
jurisdictions.

If the developers were liable, it would destroy FOSS as we know it. I'm 
hoping this isn't how it's commonly interpreted in the Western 
countries. After all, if that was the case, it would likely affect any 
Internet activity (not just publishing source codes or binaries, but 
anything in general), so an American exercising freedom of speech on the 
Internet while in the US could be later arrested in some EU country, 
which considers his speech illegal. To my knowledge, that's not commonly 
happening.

So if that's not the case, maybe FOSS projects that are not based in 
California actually don't have to do anything at all? Another 
interesting question is what would happen with mirrors, physically 
located in California, that share non-conforming FOSS operating systems.

It's hard to discuss a solution without knowing answers to these (and 
many other) questions first. We probably won't figure that out here, but 
OP had a good point of bringing this topic up, because some projects 
might be forced to comply whether they like it or not and this could at 
least coordinate their effort a bit. They could agree on some common API 
"just in case", it doesn't mean they have to proactively implement it 
now. ;-)

On 3/1/26 10:27 PM, Chance Rosenthal wrote:
> I would go so far as to suggest that the FOSS community should wait 
> for the inevitable lawsuits to shake out before we start implementing 
> anti-user policies, even if we do expect them to become law in such 
> large jurisdictions as California. Proactive compliance with horrible 
> policies is not in anyone's interests.
>
> On 3/1/26 1:08 PM, Aaron Rainbolt wrote:
>> On Sun, 1 Mar 2026 21:51:15 +0100
>> Tomáš Zíma <[email protected]> wrote:
>>
>>>>   A root-owned file won't be accessible to sandboxed applications
>>>> such as Firefox running under Flatpak.
>>> I would imagine something like this:
>>>
>>> 1. Extend adduser to ask for the user's date of birth. (GUI
>>> installers/tool would have to ask for this extra field too.) 2.
>>> Generate root-owned file containing the birth day, as suggested.
>> This would be somewhat problematic for custom implementations that want
>> to avoid storing the user's real date of birth and store only the age
>> bracket. Whonix would want to do this for anti-fingerprinting purposes.
>> I suppose the root-owned file could be generated with a static age
>> bracket and the date of birth field could be empty. Then the cron job
>> would simply skip updating the bracket if the date-of-birth field was
>> empty.
>>
>>> 3. Regenerate a root-owned, user-readable (non-writeable) file
>>> containing the user's "age bracket" once per day via cron. The path &
>>> its format (e.g. "UNDER_13") would be the API. Alternatively, to make
>>> it more portable, a script get-age-bracket could be provided. 4.
>>> Making the file/script available to sandboxes is a matter of
>>> configuration.
>>>
>>> I don't think XDG is a good place to implement this.
>> My main motivation for proposing that this be done in XDG is to make an
>> effort to make something that can be adopted more-or-less widely in the
>> end. It's definitely true that every OS could implement something
>> semi-bespoke like suggested here (or maybe this mechanism could end up
>> the standard). Personally I'd be perfectly happy with that solution,
>> but I don't think that's what the people who drafted the bill had in
>> mind when they wrote it, and I'd like for Whonix to not come under fire
>> for doing things "the wrong way". Even if ultimately no one wants a
>> standardized solution, we can say we tried.
>>
>> -- 
>> Aaron