Re: Age Verification laws

--Sig_/mpi2bX00SuhFyS0SmQLQn3k
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 3 Mar 2026 11:17:32 -0500
Lucas Holt <[email protected]> wrote:

> On 3/2/26 7:46 PM, Aaron Rainbolt wrote:
> > On Mon, 2 Mar 2026 11:25:06 -0500
> > Lucas Holt<[email protected]> wrote:
> > I'm curious why you believe it needs to be implemented in adduser.
> > AFAICT, it likely does need to be present on systems even without a
> > GUI (or with a non-standard GUI), but D-Bus can work in non-GUI
> > environments.
> >
> > While it's possible some states may require giving a date of birth,
> > do they require *storing* it? =20
>=20
> regarding adduser:
>=20
>=20
>             1798.501.
>=20
>  =C2=A0(a)=C2=A0An operating system provider shall do all of the followin=
g:
> (1)=C2=A0Provide an accessible interface at account setup that requires a=
n=20
> account holder to indicate the birth date, age, or both, of the user
> of that device for the purpose of providing a signal regarding the
> user=E2=80=99s age bracket to applications available in a covered applica=
tion
> store.
>=20
> Account setup for a MidnightBSD installation is going to happen when
> the OS is installed or after it's installed.=C2=A0 During install, the
> adduser flow is used. Thus, we need it added there. The law doesn't
> say it only applies to GUIs.=C2=A0 In fact it defines as " =E2=80=9CAppli=
cation=E2=80=9D
> means a software application that may be run or directed by a user on
> a computer, a mobile device, or any other general purpose computing
> device that can access a covered application store or download an
> application."=C2=A0 I can download an app in lynx on a system console.=C2=
=A0 I
> can download an app using mport package manager (or apt, yum, pacman
> or whatever on linux) On linux, package managers are shared by
> several distros so folks in that ecosystem need to agree on how that
> is handled.=C2=A0 On MidnightBSD, we have our own package manager as well
> as Ravenports.=C2=A0 Then there's the question if it applies to npm, pip,
> cargo, ...
>=20
>  From my perspective as an OS provider, I need to comply with setting=20
> the age on account creation, the "covered app store" likely would
> apply to package installation with repositories thus my package
> manager needs changes, and then the application level. On this list,
> folks are focused on the application level and that's fine.

What you're saying makes a lot of sense. It is worth noting though that
"account setup" doesn't seem to be well-defined, and what it looks like
will look very different for each OS. Kicksecure, for instance, doesn't
ever create its main user at installation time, the main user is
hardcoded into our ISO and VM images and is simply copied to the OS
hard drive. Therefore, "account setup" for us has to mean some time
after the actual "adduser" call, since that call happens at image build
time way before the end-user ever sees the system. One could argue that
"account setup" means "things you have to do to use your account after
you've created it". That being said, if adduser is where it works for
MidnightBSD, great. It just isn't where it will work for everyone.

Whether a package manager counts as an app store is debatable, and a
debate I'm trying to distance myself from to some degree. Under Debian,
all of the packages in the 'main' archive make up "the operating
system", and you can download the "whole OS" onto a storage device (or
several) and install every package (kinda) in the archive into your
system at the same time during OS installation time. The package
manager just lets you omit OS components you don't want and the
networked aspects keeps you from having to lug around a couple hundred
gigabytes of software all the time. That being said, Debian might
choose to consider the package repository an application store because
they think that it's legally safer to do so, and in such a case apt
would need to be able to use this API. (Some packages in the Debian
archive may be considered inappropriate for children, namely those
labelled "offensive", and arguing that those things are operating
system components may not be easy or safe. Did I mention I'm not a
laywer yet? I should mention it again for those who are reading
this without prior context.) Maybe D-Bus is an awkward thing to ask a
package manager to access, so perhaps the API needs to have multiple
"points of entry" for various use cases.

> My assumption is that different operating systems are going to
> implement this in different ways and provide some mechanism for
> checking it.=C2=A0 That variation is then going to be exposed with some
> "common" library or software such as dbus or whatever that makes it
> generic for web browsers to use.=C2=A0 (at least I hope so)

Yes, that's my hope also.

> This law was clearly written around how Microsoft, Apple and Google=20
> manage downloads for phones or their systems.=C2=A0 They have apple id,=20
> microsoft accounts, etc to manage users. However, for most *NIX
> systems, we only have local accounts or ones managed by LDAP.=C2=A0 =C2=
=A0In
> order to comply, we must store it locally.
>=20
> The missing parts are that california has another related law that=20
> defines the content pieces and that other states have suggested that
> DOB should be stored, although I don't think that's law yet. (Texas i=20
> believe)=C2=A0 =C2=A0California and Colorado are asking for age or DOB as=
 input=20
> and providing ranges as output.=C2=A0 Technically I don't think we need t=
o=20
> retain the age to comply but we do need to be able to provide range=20
> checks.=C2=A0 The issue is what other horrible law gets passed next.=C2=
=A0 We
> may need to know the DOB or age for that.

So far Apple seems to consider it safe to provide age ranges, which
seems like something that can be done reliably into the future without
needing to store an exact DOB or age, so long as one errs on the side
of reporting a user as younger than they are rather than older. If a
user is 18 and the API says that they're younger than that, I don't
expect that anyone will complain except perhaps for end-users (and
those end-users that are frustrated by that can switch to a different
implementation that stores their exact date of birth theoretically).
Even Apple doesn't return accurate age ranges when asked, even when
they could, for the sake of the user's privacy (their documentation
states that they don't return updated age brackets to apps until the
anniversary of when the user initially granted an application the
ability to read age bracket data).

> I'm not a lawyer and I don't know how privacy laws in other regions=20
> would apply to storing DOB or age.=C2=A0 Combined with a user account
> which make have a name on it, it would be PII in my book. That should
> put up a red flag for any developer.

Indeed.

--
Aaron

> Had I written this law, I would have specified it was for consumer=20
> devices only and clearly defined app store.=C2=A0 The intent is likely to=
=20
> just block downloads of adult titles, violent games and so on from
> kids as well as for web browsers to provide to sites.=C2=A0 It's not
> scoped that way.

--Sig_/mpi2bX00SuhFyS0SmQLQn3k
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQS8QsiCjFi4DcDBX+Q5rdye4jrrCAUCaaeCwAAKCRA5rdye4jrr
CA+aAP4l0R2c7LbE9I7Qe5J5wczox72CsAxnEjZ5aADqUvX8FgEA6/q+Wlb5cZJ1
jdWeyD0ysejw3NLAeWXgzGSq3WmT4Ag=
=ytdz
-----END PGP SIGNATURE-----

--Sig_/mpi2bX00SuhFyS0SmQLQn3k--