I'm going to be completely honest. While following California's laws may sound like a smart idea, and it might be a smart idea, it's really difficult when a lot of jurisdictions in the world want their share of the pie while simultaneous proscribing the implementations of other jurisdictions.
Here's a summary that I have compiled based on my readings of various bills. CA = California (Passed) CO = Colorado (Not yet passed) NY = New York (Not yet passed) == Age range == CA: Under 13, 13-16, 16-18, >18 CO: Under 13, 13-16, 16-18, >18 NY: Under 13, 13-16, 16-18, >18 == Availability == CA: All software CO: All software NY: All software == Verification method == CA: Declaration CO: Declaration NY: Actual verification (how?, Contrast: CA CO Prohibited) == Liability for tampering/incorrect input == CA: Restricted liability CO: Semi-reduced liability NY: Much less reduced liability == Other weird requirements == NY: Encryption (??), Retroactively requesting info, anticircumvention CA: Retroactively requesting info CO: Retroactively requesting info == Prohibited practises == CA: Collecting additional information (Contrast: NY Verification) CO: Collecting additional information (Contrast: NY Verification) While some parts of existing bills do not contradict the bills of other jurisdictions, other parts do, making implementation difficult. A single implementation cannot accommodate both New York and CA/CO. Also, how would an open source project implement this to NY requirements if anyone can, I don't know, ``<packagemanager> remove <ageverificationpackage>, or just rebuild their OS without whatever script that does the age verification? Let's take this into hypotheticals for a second. Now, imagine legislatures worldwide wanted to implement this because it is "Such a Great Idea!". For example, if British Columbia, where the age of majority is 19, implemented something like this, we would have a new age category of >19. However, CA and CO law would both prohibit sharing the >19 indicator, and if it was to be required, Alberta would like to have a word with you because having the >19 category is discriminatory to 18-year-old users, which is prohibited by law. I've said this before and I will say it again. Right now, here are the only three ways that I can think of which would solve the conflict of laws: - Not comply. If China required all operating systems to scan a shenfenzheng, it's unlikely we would implement that as a part of the core system. Maybe as a package, but definitely not a required component. - Require users, at package selection, to install the correct "age verification" package for their jurisdiction and deal with New York some other way. - Put "Not for use in CA, CO, NY, or where prohibited by law" on the download page (or add a clickthrough for the installer. -- Jamie On 2026-03-01 11:48, Aaron Rainbolt wrote: > Given that this is related to legal stuff, I should preface this by > saying I am not a lawyer. > > Recently, a new law was passed in California that requires OS vendors > to provide some limited info about a user's age via an API that > application distribution websites and application stores can use. [1] > Colorado seems to be working on a similar law. [2] The law will go into > effect January 1, 2027, it is no longer a draft. I do quite a bit of > work with an OS vendor (working with the Kicksecure [3] and Whonix [4] > projects), and we aren't particularly interested in blocking everyone > in California and Colorado from using our OSes, so we're currently > looking into how to implement an API that will comply with the laws > while also not being a privacy disaster. Given that other distributions > are also investigating what to do with this, and the law requires us to > make a "good faith effort to comply with [the] title, taking into > consideration available technology", I figured it would be a good idea > to bring the issue here. > > At its core, the law seems to require that an "operating system" > (I'm guessing this would correspond to a Linux distribution, not an OS > kernel or userland) request the user's age or date of birth at "account > setup". The OS is also expected to allow users to set the user's age if > they didn't already provide it (because the OS was installed before the > law went into effect), and it needs to provide an API somewhere so that > app stores and application distribution websites can ask the OS "what > age bracket does this user fall into?" Four age brackets are defined, > "< 13", ">= 13 and < 16", ">= 16 and < 18", and ">= 18". It looks like > the API also needs to not provide more information than just the age > bracket data. A bunch of stuff is left unclear (how to handle servers > and other CLI-only installs, how to handle VMs, whether the law is even > applicable if the primary user is over 18 since the law ridiculously > defines a user as "a child" while also defining "a child" as anyone > under the age of 18, etc.), but that's what we're given to deal with. > > The most intuitive place to put this functionality would be, IMO, > AccountsService. The main issue with that is that stable-release > distributions, and distributions based upon them, would be faced with > the issue of how to get an updated version of AccountsService integrated > into their software repositories, or how to backport the appropriate > code. The law goes into effect on January 1, 2027, Debian Bookworm is > going to be supported by ELTS until July 30, 2033, and we don't yet > know if Debian will care enough about California's laws to want to > backport a new feature in AccountsService into Debian Bookworm (or even > Trixie). Distributions based on Debian (such as Kicksecure and Whonix) > may still want to comply with the law though, so something using > AccountsService-specific APIs would be frustrating. Requiring a whole > separate daemon for the foreseeable future just for an age verification > API would also be annoying. > > Another place the functionality could go is xdg-desktop-portal. This > one is a bit non-ideal for a couple of reasons; for one, the easiest > place to put the call would be in the Account portal, which returns > more information than the account's age bracket. This could potentially > be considered non-compliant with the law, as it states that the > operating system shall "[s]end only the minimum amount of information > necessary to comply with this title". This also comes with the > backporting disadvantages of an AccountsService-based implementation. > > For this reason, I'd like to propose a "hybrid" approach; introduce a > new standard D-Bus interface, `org.freedesktop.AgeVerification1`, that > can be implemented by arbitrary applications as a distro sees fit. > AccountsService could implement this API so that newer versions > of distros will get the relevant features for free, while distros with > an AccountsService too old to contain the feature can implement it > themselves as a stop-gap solution. > > Taking inspiration from the File Manager D-Bus interface [5], I think > something like the following might work: > > <!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection > 1.0//EN" > "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd";> > <node name="/org/freedesktop/AgeVerification1"> > <interface name="org.freedesktop.AgeVerification1"> > <method name="SetAge"> > <arg type="s" name="User" direction="in"/> > <arg type="u" name="YearsOfAge" direction="in"/> > </method> > <method name="SetDateOfBirth"> > <arg type="s" name="User" direction="in"/> > <arg type="s" name="Date" direction="in"/> > </method> > <method name='GetAgeBracket'> > <arg type="s" name="User" direction="in"/> > <arg type="u" name="AgeBracket" direction="out"/> > </method> > </interface> > </node> > > * The 'User' argument would, in all instances, be expected to be the > UNIX account username of the user in question. This user account must > not be a system account (i.e. its UID must fall between UID_MIN and > UID_MAX as defined by /etc/login.defs). If a user is specified that > does not exist or whose UID is out of range, these methods will > return the error 'org.freedesktop.AgeVerification1.Error.NoSuchUser'. > If the specified user is not the same as the user making the method > call, and the user making the method call is not root, these methods > will return the error > 'org.freedesktop.AgeVerification1.Error.PermissionDenied'. > * The 'YearsOfAge' argument of the 'SetAge' method should be an > unsigned integer specifying the age of the user in years at the time > of the method call. (The law specifically allows providing simply an > age value rather than a birth date if desired.) > * The 'Date' argument of the 'SetDateOfBirth' method should be a string > in ISO8601 format (i.e. YYYY-MM-DD) indicating the day on which the > user was born. If the argument is invalid, the method will return the > error 'org.freedesktop.AgeVerification1.Error.InvalidDate'. > * The 'AgeBracket' output argument of the 'GetAgeBracket' method will be > an unsigned integer between 1 and 4 inclusive, where 1 indicates that > the user is under 13 years old, 2 indicates that the user is at least > 13 and under 16 years old, 3 indicates that the user is at least 16 > and under 18 years old, and 4 indicates that the user is 18 years old > or older. If no age has been configured for the user yet, the method > will return the error > 'org.freedesktop.AgeVerification1.Error.AgeUndefined'. > > I propose that the exact way in which age information is stored by the > daemon should be left implementation-defined. For Kicksecure, the way > we implement it will almost certainly store only the age bracket and > require users to explicitly reconfigure their age once they are old > enough to move from one age bracket to another. Other implementations > may choose to store the date of birth or the age and date on which the > age was set so that they can automatically update the age bracket as > time passes. This interface will be provided *on the system bus* (NOT > the session bus!), and the D-Bus service that provides these services > should run as root. The file containing the user-to-age mappings should > be owned by root and should not be world-readable, to prevent leaking > the user's specific age to malicious applications. > > Some things I did think about when writing the above but ultimately > decided to not propose: > > * Detailed permission gating for the 'GetAgeBracket' method. The only > reason to do this would be for additional privacy, and > privacy-conscious users can simply lie about their age or the age of > the intended user. There isn't anything in the law (that I can tell) > that prevents the user from just saying "I'm 18" when the prompt > appears and going with it. This would also be really difficult to > implement outside of the context of xdg-desktop-portal, and would > probably only work with sandboxed apps if it was implemented that way. > * UX for actually requesting the age from the user. IMO this is out of > scope for FreeDesktop; individual distros should see to it that they > prompt for the user's age or birth date at "account setup" (whatever > that happens to be defined as for the distro in question), nudge the > user to provide the information later on for existing installations, > etc. Furthermore, this mechanism needs to work even on CLI-only > installs and maybe even on server installs, depending on how one > defines "general purpose computing device" (as specified by the law > in question), so defining any specific UX is likely infeasible. (If > this is required on servers, end-users will probably want to > auto-provision the age information somehow, and specifying how to do > that in a distribution-agnostic way is impossible given that Ubuntu > uses cloud-init, Fedora uses Kickstart and Ignition, etc.) > * Omitting the 'SetDateOfBirth' method. It can be lived without > legally, but without the method, it becomes difficult for software > that already records the user's date of birth to accurately implement > automatic age bracket adjustment as time passes. This isn't a feature > Kicksecure would use, but it's a feature some projects might be > interested in. > > Thanks for taking a look at this. > > -- > Aaron > > [1] > https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260AB1043 > [2] https://leg.colorado.gov/bill_files/110990/download > [3] https://www.kicksecure.com/ > [4] https://www.whonix.org/ > [5] https://www.freedesktop.org/wiki/Specifications/file-manager-interface/ -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
