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

--00000000000028134f064c0f3099
Content-Type: text/plain; charset="UTF-8"

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:

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.

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.

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).

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.

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.

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.

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.

Vanida Plamondon (Author/songwriter)

--00000000000028134f064c0f3099
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Here is the method(s) I think would need minimal code to i=
mplement to meet AB 1043&#39;s requirements without compromising anything i=
ntegral to open source software:<br><br>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 requi=
red for such a=C2=A0user. Various interfaces of account creation tools will=
 need to be modified to conform to AB 1043, prompting the user for their ag=
e when appropriate. Default value, as well as the value entered when settin=
g up someone else&#39;s user should be 0 which serves to denote a user &quo=
t;account&quot; that is not fully set up in respect to age verification.<br=
><br>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, de=
fault value of 0). An Extended Attribute seems like the best bet for maximu=
m compatibility across most filesystems (except those like UFS1 that do not=
 use them), but various tools throughout the toolchain such as cp and tar w=
ill need to be updated to preserve Extended Attributes, or at least the sys=
tem.age_min attribute.<br><br>At this point, it is up to the Linux Security=
 Module&#39;s implementation to conform to AB 1043 in respect to age authen=
tication. When a process attempts to access a file, the LSM checks if age v=
erification is required (system.age_min msb is equal to 0) and if so, if th=
e user&#39;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 equa=
l to or greater than system.age_min (AB 1043&#39;s requirements are now met=
).<br><br>Finally, package managers do the rest. When downloading a package=
, the package manager calls the LSM to call for access to download the pack=
age, and sets the appropriate system.age_min extended attributes for the pa=
ckage&#39;s files when installed.<br><br>While the LSM is already managing =
access to files and directories, a developer will need to have their applic=
ation call the LSM to check for access to start the application. This is co=
mpletely unnecessary for this scheme, and is only done to meet the requirem=
ents of AB 1043.<br><br>Once implemented, we gain a secondary benefit in th=
at files, directories, and resources, local or remote, can be seamlessly ag=
e authenticated, essentially allowing parental controls with resilient auth=
entication allowing a parent to set a child&#39;s age for their user that i=
s universally applied. A parent can even manually set age minimums to whate=
ver they want for any file, directory, and resource.<br><br>Unexpectedly, i=
f we use this minimalist approach, we actually create a framework for robus=
t parental controls that parental management software could draw and build =
upon. I think this would be the way to go, because it&#39;s simply building=
 upon and extending free software&#39;s existing Access Control, as opposed=
=C2=A0to making an API specifically to conform to a specific law or regulat=
ion, and ideally would be more future-proofed.<div><br></div><div>Vanida Pl=
amondon (Author/songwriter)</div></div>

--00000000000028134f064c0f3099--