Re: Minimal Implementation AB 1043 (California's Age Verification Bill)
Vanida Plamondon <[email protected]> Mon, 2 Mar 2026 20:06:10 -0700
| Newsgroups | gmane.linux.xdg.devel |
|---|---|
| Message-ID | <CAMm9xBwXuGaAnC0GmOp0PCMh6mg=LEOQTr8W4D0wFK1TeAjbdA@mail.gmail.com> |
--000000000000f8643f064c15fcae Content-Type: text/plain; charset="UTF-8" My proposed method has nothing to do with application stores, as the developers of such software are responsible for implementing a solution that conforms to the law's requirements. All software, including OS distributions including free software distributions, and every bit of software used by such distributions, or that is available on such distributions, fall under the scope of this kind of law. In other words, every single piece of free software in the world falls under the scope of this kind of law. If you make software, even if it's only in source code form, and it's publicly available, your software falls under the scope of this kind of law. The problem is that these kinds of laws could kill free software, because it is essentially impossible for any particular software developer to conform to the law. Software that conforms to the law on an individual basis, is trivial to bypass and therefore does not truly conform to the law. The only way that software can be distributed without incurring liability is under an application store type of scheme that conforms to this law. If you release software in any other way that is available to Californians, you incur liability. The point of my method is that in recognizing this reality, we can simply extend the way that certain features used by free software, such as authentication, are designed and make such a standard in respect to how access control is implemented in free software such as operating systems. Remember, if the operating system conforms to the law, then software made available through the operating system conforms to the law. The other reason for my method is that to turn the operating system into what is effectively an application store will effectively involve way more compromises than free software developers are likely to be willing to make. My method instead flips the problem on its head by instead incorporating actual effective parental controls encompassing the operating system and the entirety of all its resources. The side effect of doing this is that every free software such as operating systems that use free software access control methods now conform to the law. This should be somewhat future proof since we are implementing parental controls, not the letter of the law. Any legal attack that uses parental controls as a vector to kill free software will be unable to overcome actually implementing parental controls. Also, free software will then be the only widely available software that effectively and transparently implements parental controls that does not interfere with the normal operation of one's software. On Mon, 2 Mar 2026 at 17:49, Aaron Rainbolt <[email protected]> wrote: > 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: > > > > 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) > > 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 > --000000000000f8643f064c15fcae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">My proposed method has nothing to do with application stor= es, as the developers of such software are responsible for implementing a s= olution that conforms to the law's requirements.<br><br>All software, i= ncluding OS distributions including free software distributions, and every = bit of software used by such distributions, or that is available on such di= stributions, fall under the scope of this kind of law. In other words, ever= y single piece of free software in the world falls under the scope of this = kind of law. If you make software, even if it's only in source code for= m, and it's publicly available, your software falls under the scope of = this kind of law.<br><br>The problem is that these kinds of laws could kill= free software, because it is essentially impossible for any particular sof= tware developer to conform to the law.<br><br>Software that conforms to the= law on an individual basis, is trivial to bypass and therefore does not tr= uly conform to the law. The only way that software can be distributed witho= ut incurring liability is under an application store type of scheme that co= nforms to this law. If you release software in any other way that is availa= ble to Californians, you incur liability.<br><br>The point of my method is = that in recognizing this reality, we can simply extend the way that certain= features used by free software, such as authentication, are designed and m= ake such a standard in respect to how access control is implemented in free= software such as operating systems. Remember, if the operating system conf= orms to the law, then software made available through the operating system = conforms to the law.<br><br>The other reason for my method is that to turn = the operating system into what is effectively an application store will eff= ectively involve way more compromises than free software developers are lik= ely to be willing to make. <br><br>My method instead flips the problem on i= ts head by instead incorporating actual effective parental controls encompa= ssing the operating system and the entirety of all its resources. The side = effect of doing this is that every free software such as operating systems = that use free software access control methods now conform to the law.<br><b= r>This should be somewhat future proof since we are implementing parental c= ontrols, not the letter of the law. Any legal attack that uses parental con= trols as a vector to kill free software will be unable to overcome actually= implementing parental controls. Also, free software will then be the only = widely available software that effectively and transparently implements par= ental controls that does not interfere with the normal operation of one'= ;s software.</div><br><div class=3D"gmail_quote gmail_quote_container"><div= dir=3D"ltr" class=3D"gmail_attr">On Mon, 2 Mar 2026 at 17:49, Aaron Rainbo= lt <<a href=3D"mailto:[email protected]">[email protected]</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, = 2 Mar 2026 11:59:24 -0700<br> Vanida Plamondon <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br> <br> > Here is the method(s) I think would need minimal code to implement to<= br> > meet AB 1043's requirements without compromising anything integral= to<br> > open source software:<br> > <br> > An AGE_ID field can be added to the user database as a new field or<br= > > as an entry in the GECOS field. Discussion will be had as to which<br> > way is ideal. Non-human users will simply have the most significant<br= > > bit set to 1 to denote that age verification is not required for such<= br> > a user. Various interfaces of account creation tools will need to be<b= r> > modified to conform to AB 1043, prompting the user for their age when<= br> > appropriate. Default value, as well as the value entered when setting<= br> > up someone else's user should be 0 which serves to denote a user<b= r> > "account" that is not fully set up in respect to age verific= ation.<br> > <br> > An I_AID field is added as a new entry to the inode table (which does<= br> > not seem like a good idea), or as an Extended Attribute<br> > (system.age_min, default value of 0). An Extended Attribute seems<br> > like the best bet for maximum compatibility across most filesystems<br= > > (except those like UFS1 that do not use them), but various tools<br> > throughout the toolchain such as cp and tar will need to be updated<br= > > to preserve Extended Attributes, or at least the system.age_min<br> > attribute.<br> > <br> > At this point, it is up to the Linux Security Module's implementat= ion<br> > to conform to AB 1043 in respect to age authentication. When a process= <br> > attempts to access a file, the LSM checks if age verification is<br> > required (system.age_min msb is equal to 0) and if so, if the user'= ;s<br> > AGE_ID is 0 or not. 0 means make a system call to prompt user for<br> > their age, and any other value means block access if AGE_ID is not<br> > equal to or greater than system.age_min (AB 1043's requirements ar= e<br> > now met).<br> > <br> > Finally, package managers do the rest. When downloading a package, the= <br> > package manager calls the LSM to call for access to download the<br> > package, and sets the appropriate system.age_min extended attributes<b= r> > for the package's files when installed.<br> > <br> > While the LSM is already managing access to files and directories, a<b= r> > developer will need to have their application call the LSM to check<br= > > for access to start the application. This is completely unnecessary<br= > > for this scheme, and is only done to meet the requirements of AB 1043.= <br> > <br> > Once implemented, we gain a secondary benefit in that files,<br> > directories, and resources, local or remote, can be seamlessly age<br> > authenticated, essentially allowing parental controls with resilient<b= r> > authentication allowing a parent to set a child's age for their us= er<br> > that is universally applied. A parent can even manually set age<br> > minimums to whatever they want for any file, directory, and resource.<= br> > <br> > Unexpectedly, if we use this minimalist approach, we actually create a= <br> > framework for robust parental controls that parental management<br> > software could draw and build upon. I think this would be the way to<b= r> > go, because it's simply building upon and extending free software&= #39;s<br> > existing Access Control, as opposed to making an API specifically to<b= r> > conform to a specific law or regulation, and ideally would be more<br> > future-proofed.<br> > <br> > Vanida Plamondon (Author/songwriter)<br> <br> I don't think this covers the need for websites that act as application= <br> stores to be able to request information about the user's age bracket.<= br> The LSM idea, while potentially useful in other contexts, sounds<br> overkill to me. I don't think the law requires invasive control over<br= > what the user can and cannot execute or open.<br> <br> --<br> Aaron<br> </blockquote></div> --000000000000f8643f064c15fcae--