[NTLUG:Discuss] [Discuss] age verification in systemd

Cornelius Keck dfwuug at keck.us
Tue Mar 24 11:50:37 PDT 2026


On a separate note, you might have gotten bounces from groups.io because 
dfwrpi at groups.io did not exist. Just created that group because. Not 
sure yet how to set up automated forwarding and all that. Stay tuned.

On 2026-03-24 12:06, Cornelius Keck via Discuss wrote:
> Isn't that the Microslime-affiliated dude who came up with that piece of 
> useless unwanted junk to begin with?
> 
> Why am I not surprised. Have to dig this up, but IIRC I've seen a FB 
> post where somebody forked that junk to remove that "feature".
> 
> This is what one gets if one lets induhvidials with little technical 
> understanding pass laws with dumb excuses.
> 
> On 2026-03-23 17:09, stuart yarus wrote:
>> Hi,
>>
>>> From distrowatch dot com / weekly.php?issue=20260323#news:
>>
>> "Last week we talked about age verification laws
>> <https://distrowatch.com/weekly.php?issue=20260316#qa>, what they are and
>> the issues surrounding these surveillance efforts. This week a new age
>> tracking feature was added to systemd
>> <https://github.com/systemd/systemd/pull/40954>: "[This change] stores 
>> the
>> user's birth date for age verification, as required by recent laws in
>> California (AB-1043), Colorado (SB26-051), Brazil (Lei 15.211/2025), etc.
>> The xdg-desktop-portal project is adding an age verification portal
>> <https://github.com/flatpak/xdg-desktop-portal/pull/1922> that needs a 
>> data
>> source for the user's age. userdb already stores personal metadata
>> (emailAddress, realName, location) so birthDate is a natural fit." The
>> birthdate field can be set by the administrator only, but can be read by
>> the user and the user's applications. "
>>
>> "Update: Following strong feedback from the community, an attempt was 
>> made
>> to revert the change <https://distrowatch.com/<a href=>. The attempted
>> reversal of the change includes a comment: "Introducing birth date 
>> storage
>> or age queries (even local-only) creates a new class of sensitive user 
>> data
>> in the OS that didn't exist before. It risks normalizing permission-like
>> checks inside the desktop session and could be extended to far more
>> invasive controls in the future." The reversal was denied by project 
>> leader
>> Pottering, who insists the tracking feature will remain. "
>>
>>
> 




More information about the Discuss mailing list