Re: Minimal Implementation AB 1043 (California's Age Verification Bill)

--Sig_/5J5qxqe4E+rYa4BPBegrJgt
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Mon, 2 Mar 2026 11:59:24 -0700
Vanida Plamondon <[email protected]> wrote:

> Here is the method(s) I think would need minimal code to implement to
> meet AB 1043's requirements without compromising anything integral to
> open source software:
>=20
> An AGE_ID field can be added to the user database as a new field or
> as an entry in the GECOS field. Discussion will be had as to which
> way is ideal. Non-human users will simply have the most significant
> bit set to 1 to denote that age verification is not required for such
> a user. Various interfaces of account creation tools will need to be
> modified to conform to AB 1043, prompting the user for their age when
> appropriate. Default value, as well as the value entered when setting
> up someone else's user should be 0 which serves to denote a user
> "account" that is not fully set up in respect to age verification.
>=20
> An I_AID field is added as a new entry to the inode table (which does
> not seem like a good idea), or as an Extended Attribute
> (system.age_min, default value of 0). An Extended Attribute seems
> like the best bet for maximum compatibility across most filesystems
> (except those like UFS1 that do not use them), but various tools
> throughout the toolchain such as cp and tar will need to be updated
> to preserve Extended Attributes, or at least the system.age_min
> attribute.
>=20
> At this point, it is up to the Linux Security Module's implementation
> to conform to AB 1043 in respect to age authentication. When a process
> attempts to access a file, the LSM checks if age verification is
> required (system.age_min msb is equal to 0) and if so, if the user's
> AGE_ID is 0 or not. 0 means make a system call to prompt user for
> their age, and any other value means block access if AGE_ID is not
> equal to or greater than system.age_min (AB 1043's requirements are
> now met).
>=20
> Finally, package managers do the rest. When downloading a package, the
> package manager calls the LSM to call for access to download the
> package, and sets the appropriate system.age_min extended attributes
> for the package's files when installed.
>=20
> While the LSM is already managing access to files and directories, a
> developer will need to have their application call the LSM to check
> for access to start the application. This is completely unnecessary
> for this scheme, and is only done to meet the requirements of AB 1043.
>=20
> Once implemented, we gain a secondary benefit in that files,
> directories, and resources, local or remote, can be seamlessly age
> authenticated, essentially allowing parental controls with resilient
> authentication allowing a parent to set a child's age for their user
> that is universally applied. A parent can even manually set age
> minimums to whatever they want for any file, directory, and resource.
>=20
> Unexpectedly, if we use this minimalist approach, we actually create a
> framework for robust parental controls that parental management
> software could draw and build upon. I think this would be the way to
> go, because it's simply building upon and extending free software's
> existing Access Control, as opposed to making an API specifically to
> conform to a specific law or regulation, and ideally would be more
> future-proofed.
>=20
> Vanida Plamondon (Author/songwriter)

I don't think this covers the need for websites that act as application
stores to be able to request information about the user's age bracket.
The LSM idea, while potentially useful in other contexts, sounds
overkill to me. I don't think the law requires invasive control over
what the user can and cannot execute or open.

--
Aaron

--Sig_/5J5qxqe4E+rYa4BPBegrJgt
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

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

iHUEARYKAB0WIQS8QsiCjFi4DcDBX+Q5rdye4jrrCAUCaaYwFgAKCRA5rdye4jrr
CDIbAP0R/KXG0quZiCmpJkvsgDcozi6NLIqgNIoeyI8lh1CBvQEA8JGnohg5qPDh
WyTKVZMSh61KwI1q86qsGsmgv8hlxgY=
=fvTq
-----END PGP SIGNATURE-----

--Sig_/5J5qxqe4E+rYa4BPBegrJgt--