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

On 2026-03-01 16:08, Tomáš Zíma wrote:
> 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

(Not a lawyer, definitely not an US lawyer)

Unfortunately, with the Internet, jurisdiction is becoming more and more 
complex and uncertain, with legislatures attempting to take advantage of 
that uncertainty. There is a certain state in Europe presently arguing 
that their state has jurisdiction over all websites that are accessible 
from within their state.


To me, the main question with implementing this mechanism as required by 
the State of California is to answer what constitutes an "operating 
system".

The only reasonable conclusion I can reach in regards to what 
constitutes an operating system is a distribution (as a whole). It most 
certainly isn't the Kernel, desktop environment, or any component 
individually.

This also makes age-declaration APIs better suited as a separate package 
which a distribution can choose to incorporate, while allowing 
distributions that do not wish to incorporate an age declaration 
mechanism to simply omit that package, rather than having to patch 
Wayland (or something else hard to omit) to get rid of it.

I sent this to a different mailinglist earlier today outlining other 
considerations on why a separate package might be preferred over 
including this API in an existing component.

> The issue with building it into existing components is that while an "age verification" API might be required in some jurisdictions, there are others where providing this API could run afoul of privacy laws or is otherwise legally prohibited. Furthermore, should more jurisdictions decide to enact poorly-considered "age verification" laws with varying requirements as to what is disclosed, it would be easier to accommodate those jurisdictions' requirements this way. 

-- Jamie