There has been a lot of chatter and drama about the addition or preparation of software capabilities related to age verification in the systemd project and the freedesktop.org project. These capabilities come in response to state laws introduced in Colorado and California, which mandate that operating systems must provide means for collecting the user's age/birth date and a separate interface for applications to query the age bracket the user belongs to.
A fair amount of the discussion is what I would consider healthy skepticism, but I have also seen a lot of hyperbole and slippery-slope, so I figured I would throw my hat into the ring and try to cover how these laws and the introduced mechanisms for complying work, along with some of the arguments I have seen along the way. Basically, my hope is that I can assist in grounding the discussion with the facts as they appear.
Do keep in mind though that all of this comes with the caveat that I am not a lawyer, so I will try to avoid doing very deep legal analysis and instead try to approach this from the perspective of taking the legalese at face-value.
The laws in question
In the case of California, the age verification law in question is Digital Age Assurance Act (AB-1043), which has already been signed into law and will take effect in January 1st 2027. The Colorado equivalent is Age Attestation on Computing Devices SB26-051, which is under consideration and not yet signed into law. Although both are obviously legalese to some degree, they are also fairly short bills, and therefore I recommend everyone to have a go at reading them by yourself. There are some parts that tripped me up on first reading, especially the Colorado bill's section on the definition of a "covered application store", but the general gist of the bills is not too difficult to discern.
Both of the bills are very similar (for which there is a reason, that we will get to eventually), and essentially mandate the following requirements for any "operating system provider":
- The operating system must have an account setup step that requires the device's user's age or birth date to be stored for age bracket signaling to applications.
- An API must be available for application developers to request the user's age bracket.
- The API must provide only the minimum amount of data to comply with the age verification bills. Both bills specify this as the age brackets of under 13, 13-16, 16-18 or above 18. Therefore, the age bracket signal should only contain that information and nothing else.
Further, the laws do specify some requirements for application developers, namely that the the data from the age verification signal may only be used for legal compliance, but may not request further data nor share the result of the age verification signal with third parties.
Like I mentioned, there are some tricky sections to these bills, but they are basically identical. The "operating system provider" covers seemingly any person or entity that somehow provides or controls the operating system on any general-purpose computing device. So, that means that companies like Google, Apple and Microsoft, but also every other operating system project, including Ubuntu, Debian, Fedora, Redhat and so on all the way to niche operating systems such as FreeDOS and Haiku and hobby operating systems. I think technically it might not apply to operating systems that provide no networking capabilities, as they would then be de facto unable to access any "covered application store", making the signal entirely pointless, but don't take that as gospel.
Secondly, that "covered application store" has a definition that I had trouble parsing, especially in terms of its relationship to the application. But it seems to imply that any service that provides downloadable, standalone third-party applications. The covered application store is seemingly named as one possible source of age bracket information to an application when an application is launched and the application requests age bracket information, but it seems like alternatively the operating system provider is responsible for that. All in all, this definition reads very clumsy to me and its purpose is a bit unclear, so if someone has been able to parse it and has come up with a clear English definition, I would happily hear it.
The key thing to keep in mind here is that the measures mandated by these bills are comparatively light, especially in contrast to the age verification measures that platforms like Discord have been implementing. The bills in their current form require no ID scans, no face scans and no linkage to a strong authentication source, such as a bank, internet service provider or a payment processor. The data also doesn't need to be available online, although with Google, Microsoft and Apple, the source of the age bracket data would likely be the respective account on their online services, linked to your personal device.
The compliance implementations
Compliance with the aforementioned bills has been started on at least two different levels in the Linux open source ecosystem. There has been a pull request merged to systemd-userdb, which adds a user record field that allows a birth date to be added for a user. Secondly, freedesktop.org introduced a draft for an XDG specification for a D-Bus interface providing the age verification signal, but that specification was then closed as it was deemed to be superceded by an equivalent draft to the xdg-desktop-portal.
For some context, it's valuable to have an idea of what these components even are that are being modified and how these implementations would actually work in practice.
Firstly, systemd-userdb is part of the systemd project, which provides access to user and
group record lookup. Some parts of the user records pre-date systemd-userdb, for example
you can most likely find the "real name" associated with your user by doing cat
/etc/passwd. What systemd-userdb does is it pulls the legacy user and group records and
also supplements them with its own records to provide a central source for user-related
information that is of system-wide concern. The systemd docs describe what sort of
additional data may be provided in the JSON User Records, but up until now it has included
things like email addresses, profile pictures, location, timezone and language.
Then there's freedesktop and specifically the xdg-desktop-portal. Freedesktop is a project that aims to provide software and specifications to facilitate desktop development on Linux. It produces software, such as drivers and various system components, but also specifications that aim to make different bits of software interoperable. You may have heard of the XDG Base Directory specification for instance, which specified directories into which applications should store their data and configuration files. The xdg-desktop-portal project in particular is a specification of APIs that allow applications to request additional capabilities. It's most typically used by Flatpak applications, which are often designed to be sandboxed and therefore not be given access to all resources ahead of time. Instead, the application will request these capabilities, which triggers a desktop-specific dialog window asking the user to provide access to a directory or screensharing or other capabilities that might be desirable to keep conditional.
The age verification specific change concerns the Account portal, which is intended to conditionally provide information about the user to applications. You can check out the documentatation of the Account portal on the Flatpak docs. The age verification functionality would complement that portal by providing a method to query a given list of age brackets, to which the portal would - when approved - provide the specific bracket into which the user falls. The change to xdg-desktop-portal does not declare how the age bracket of the user is determined, since xdg-desktop-portal is basically just the part that desktop-specific implementations would hook to. However, it is likely that the desktop-specific implementations would try to use a common source for the information to avoid having to deal with multiple fragmented sources. Therefore something like systemd-userdb would be a relatively likely candidate to target a large number of systems.
The criticisms
Now, I will try to outline the sorts of criticisms I have seen. I will also provide my own commentary on these as we go.
The init system should not know your birth date
This criticism basically ties back to the frequent flamewars that have been had about systemd doing "too many things for an init system" which kind of makes the assumption that systemd is a big monolithic init system that has swallowed a bunch of other services.
That's not really how systemd works and it's more helpful to think of the systemd project consisting of a number of services that are developed together. So, systemd-userdb isn't really systemd the init system. The question could be raised whether this particular service should be developed by the systemd project, but I honestly don't see how moving it or a roughly equivalent service onto a different maintainer would really help with the situation. If someone wanted, I think they could also develop their own implementation that implements the same interfaces to have their own fake systemd-userdb in case they don't want to carry any systemd services on their system. Some people might do this to in the name of init diversity, but at this point systemd is kind of a de facto standard on Linux, with alternative initds being quite niche. All in all, rejecting something just because it is associated with the systemd project is not very productive in my opinion and at least I find the flamewars very tiresome.
Another question might be raised, which is whether systemd-userdb should have the birth day field. Considering the other fields that are already there, I personally don't think it to be a major addition. If we are concerned about the sensitivity of birth date, I would imagine we'd be similarly concerned about the real name, email and location fields too, but at least I am not, since this is basically just data held locally for the benefit of the local system. Obviously I wouldn't want an application to go snooping and transmitting that data without my say so, but I wouldn't be opposed to controlled access to it.
We shouldn't comply in advance
I think the biggest problem with this is that the clock is already ticking at least on the California bill. It has a hard deadline of January 1st and to comply with it, a solution would need to be developed and disseminated by that date. Many Linux distros produce new feature releases once or twice a year, so unless exceptional measures are used, Fedora and Ubuntu would need to ship with the necessary functionality already in October at the latest. There is also still plenty of implementation, documentation and testing work that would likely need to be carried out by a fairly wide ecosystem, so doing the work now might be the only way to handle things. Some people are hoping for further amendments and exemptions, but at this point at least with the California bill, this is speculation and therefore risky.
This functionality is bad for user privacy
There are ways that the age verification signal could be abused to convert repeated age bracket requests into someone's birth day, assuming they fall into the lower brackets. However, I think this would be pretty obvious and clear abuse of the functionality and the party abusing the signal would probably not be very trustworthy in the first place.
A second possibility I can see is that this would be an introduction of yet another permission dialog, which may contribute to permission fatigue, where a user just starts mindlessly approving any permission dialog that pops up, so malicious applications might more easily gain access to things like microphones for instance if the dialog is too similar to the age verification dialog.
However, as it currently stands, I don't think that the requirements set by the age verification bills or the implementations designed to comply with them are themselves particularly scary. There are plenty of websites out there that pop up a dialog into which you need to input your birth date or they otherwise ask you to press a button to confirm you are 18 or above, and I don't see how the age verification signal is meaningfully different from that. I also haven't seen any complaints about those particular "confirm your age" banners, so I would guess people are generally fine with them. In fact, having a unified method might be a better user experience, as depending on the implementation it might allow skipping specific banners I would approve anyway. And parents that have set up computers for their kids may find it useful, as it would provide a lighter and more universal mechanism to do parental control of sites and apps the child is granted access to. Whether I think that's useful, I will touch upon later.
The age verification requirements will be ramped up to ID checks/face scans later
Although this is pretty much a definition of a slippery slope fallacy, I don't personally think it would be impossible for this to happen. There are parties that probably would have a business incentive to impose stronger age attestation mechanisms onto all users, which would mean guaranteed business for the few companies that offer that service.
But if we are sticking to what is happening now and what the implementations are actually doing, it's not ID checks or facial scans, and the mechanisms that are currently proposed are not in my opinion preposterous. It would also be possible to stand up against, and it would arguably be very important to do so, attempts to impose face scans and ID checks by law even if the mechanisms that have been mandated so far have been implemented.
These laws only affect specific US states, people outside of affected regions should not have this imposed on them
Although these laws are currently limited in scope, these things do have a nasty tendency to spread. I believe a few South American governments have taken up their own attempts to implement something similar. EU will most likely follow suit to some extent, although I do hope they will not.
Either way, the implementations themselves represent capability to comply, so distro projects are still able to decide whether they comply or not. Just because systemd-userdb has a field for a user's birth date doesn't mean it must be filled and just because the xdg-desktop-portal might have the ability to supply age bracket information doesn't mean that the implementation has to enable supplying that information.
In fact, Ageless Linux opts to intentionally not comply with the requirement. Other projects may or may not choose to follow the example by their own volition. But projects that choose to comply will be in a better place if the common mechanisms to do so are in place.
You should be a better parent instead of relying on age attestation
Firstly, I am not a parent, so I am not going to dictate to others how they should parent their children. However, I am personally of the belief that these age verification laws and mechanism do indeed not provide notable safety for children. I was personally raised in an environment where I was given considerable autonomy and trust when it came to my computer use and I personally think I came out alright and didn't abuse that trust much. So if I were a parent, I would probably try to take the same approach of light supervision and trust over technical limitations.
However, I do have to admit that the age check pop-ups I am familiar with are not obeyed by a decent chunk of kids and an operating system limitation would provide a barrier that would probably block some chunk of kids trying to access sites they shouldn't. On the other hand though, I remember our primary school computers having all sorts of access controls for websites and we figured out all sorts of bypasses for that up to and including finding out the admin password for the computers just so we could watch YouTube, so a bunch of kids would bypass these and most likely almost any other reasonable mechanisms. It's also entirely possible they will simply find dodgier sites if the ones that are more legitimate are not accessible, so there's that too.
I also think that it's worth keeping in mind that some parents have varying degrees to which they can maintain supervision of their kids. Some parents just cannot keep an eye on everything their kids are doing on their computers at all times, for no fault of their own, so calling them a bad parent for it is not entirely productive. For those parents, this sort of age bracketing tech would provide at least some means to try to prevent access to things kids maybe shouldn't be interacting with, even if it's not a perfect solution.
Age attestation's dubious parties and dark money problems
That isn't to say though that the push for this legislation is entirely well-intentioned of course. In fact, the way age attestation has been lobbied through seems pretty shady in general. The TBOTE Project apparently has tracked a bunch of funding from Meta and The Heritage Foundation that has been funneled through lobbying groups to enact these laws. Part of the motivation may be extended data and identity gathering, but there is also the secondary aspect of using age attestation as a censorship measure by first declaring specific categories of information, such as LGBTQ+ or sex-ed materials, as 18+ at which point age attestation provides the technical measure for access prevention. It's worth keeping in mind that providing access to such content may in fact help protect kids from harm more than preventing such access, but especially to the conservative forces that are behind such agendas, harm to kids isn't really the point. In general, it's a bit hard to take especially US law-making in this area seriously, considering a good chunk of the people behind these laws are probably implicated either directly or indirectly in the Epstein papers.
Conclusions
So, I think that covers a fair chunk of what has been going on. I think what I want to really say here is that skepticism about the intentions behind these laws are very much justified, but I think people have gone a bit overboard when it comes to what the technical implementors have actually implemented. I think the flak that the systemd project and freedesktop.org have received is not really proportional. In fact, the technical measures that have been written to law are not in my personal opinion all that crazy in the sense that I don't believe they interfere with user privacy much more than an age check banner might. And in general, attacking these projects is unlikely to help stop these laws and would only harm the ability for those that feel compelled to comply to be able to do so in a way that doesn't become a haphazard last-minute sprint.
However, the people that are pushing for this law in conjunction with ever stricter classifications of adult content are not really trustworthy in my opinion and such restrictions should be pushed back on actively. Instead of these laws regulating things that are harmful to children, they seem instead to be doing more to regulate children, which to me seems rather backwards and not entirely productive. And as we have seen in the case of the UK, poorly implemented regulations in the name of "protecting children" seem to just make everybody's lives more difficult and mainly serve to enrich VPN providers.