Re: On the unfortunate need for an "age verification" API for legal compliance reasons in some U.S. states
Christopher Warner <[email protected]> Sun, 01 Mar 2026 16:46:20 -0500
| Newsgroups | gmane.linux.xdg.devel,gmane.linux.debian.devel.general,gmane.linux.redhat.fedora.devel,gmane.linux.ubuntu.devel,gmane.linux.debian.devel.legal,gmane.linux.redhat.fedora.legal |
|---|---|
| Message-ID | <[email protected]> |
--=-qjwo49RqFmywhUmN+x16 Content-Type: multipart/alternative; boundary="=-i6L18/zp6Q7gH0E5mFLU" --=-i6L18/zp6Q7gH0E5mFLU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2026-03-01 at 16:08 -0500, Aaron Rainbolt wrote: > On Sun, 1 Mar 2026 21:51:15 +0100 > Tom=C3=A1=C5=A1 Z=C3=ADma <[email protected]> wrote: >=20 > > > =C2=A0A root-owned file won't be accessible to sandboxed applications > > > such as Firefox running under Flatpak.=C2=A0=20 > >=20 > > I would imagine something like this: > >=20 > > 1. Extend adduser=C2=A0to ask for the user's date of birth. (GUI > > installers/tool would have to ask for this extra field too.) 2. > > Generate root-owned file containing the birth day, as suggested. >=20 > This would be somewhat problematic for custom implementations that > want > to avoid storing the user's real date of birth and store only the age > bracket. Whonix would want to do this for anti-fingerprinting > purposes. > I suppose the root-owned file could be generated with a static age > bracket and the date of birth field could be empty. Then the cron job > would simply skip updating the bracket if the date-of-birth field was > empty. >=20 > > 3. Regenerate a root-owned, user-readable (non-writeable) file > > containing the user's "age bracket" once per day via cron. The path > > & > > its format (e.g. "UNDER_13") would be the API. Alternatively, to > > make > > it more portable, a script get-age-bracket could be provided. 4. > > Making the file/script available to sandboxes is a matter of > > configuration. > >=20 > > I don't think XDG is a good place to implement this. >=20 > My main motivation for proposing that this be done in XDG is to make > an > effort to make something that can be adopted more-or-less widely in > the > end. It's definitely true that every OS could implement something > semi-bespoke like suggested here (or maybe this mechanism could end > up > the standard). Personally I'd be perfectly happy with that solution, > but I don't think that's what the people who drafted the bill had in > mind when they wrote it, and I'd like for Whonix to not come under > fire > for doing things "the wrong way". Even if ultimately no one wants a > standardized solution, we can say we tried. >=20 > -- > Aaron I am also not a lawyer but the law seems like it could easily be challenged and likely run afoul of privacy laws here in the US. The technical ramifications and enforcement of them can't be implemented in a way that wouldn't run afoul of privacy related rights (yes, even children have privacy rights) and also present a security quagmire. Further it puts the onus all on the "developer" or OS vendor to essentially keep track and obey "signals", or be fined. The spirit of the laws existence is to protect children but the implementation of this or a path-forward almost seems farcical to discuss. It's very clear it's drafting and implementation had no one who understands how this works in the room, and if they were, they were summarily ignored. Getting ahead of it as you are, whatever solution, it won't matter, because every larger distro is likely to implement their own way-to-do and same with every smaller one, and of course there will be those that ignore this completely or stop distributing in California and states that adopt such a law. The law's spirit is in the right place, but it needs revision so it can be implemented appropriately. Christopher Warner --=-i6L18/zp6Q7gH0E5mFLU Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html><head><style>pre,code,address { margin: 0px; } h1,h2,h3,h4,h5,h6 { margin-top: 0.2em; margin-bottom: 0.2em; } ol,ul { margin-top: 0em; margin-bottom: 0em; } blockquote { margin-top: 0em; margin-bottom: 0em; } </style></head><body><div>On Sun, 2026-03-01 at 16:08 -0500, Aaron Rainbolt= wrote:</div><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-l= eft:2px #729fcf solid;padding-left:1ex"><div>On Sun, 1 Mar 2026 21:51:15 +0= 100<br></div><div>Tom=C3=A1=C5=A1 Z=C3=ADma <<a href=3D"mailto:tomas@tzi= ma.cz">[email protected]</a>> wrote:<br></div><div><br></div><blockquote ty= pe=3D"cite" style=3D"margin:0 0 0 .8ex; border-left:2px #729fcf solid;paddi= ng-left:1ex"><blockquote type=3D"cite" style=3D"margin:0 0 0 .8ex; border-l= eft:2px #729fcf solid;padding-left:1ex"><div> A root-owned file won't = be accessible to sandboxed applications<br></div><div>such as Firefox runni= ng under Flatpak. <br></div></blockquote><div><br></div><div>I would = imagine something like this:<br></div><div><br></div><div>1. Extend adduser= to ask for the user's date of birth. (GUI<br></div><div>installers/to= ol would have to ask for this extra field too.) 2.<br></div><div>Generate r= oot-owned file containing the birth day, as suggested.<br></div></blockquot= e><div><br></div><div>This would be somewhat problematic for custom impleme= ntations that want<br></div><div>to avoid storing the user's real date of b= irth and store only the age<br></div><div>bracket. Whonix would want to do = this for anti-fingerprinting purposes.<br></div><div>I suppose the root-own= ed file could be generated with a static age<br></div><div>bracket and the = date of birth field could be empty. Then the cron job<br></div><div>would s= imply skip updating the bracket if the date-of-birth field was<br></div><di= v>empty.<br></div><div><br></div><blockquote type=3D"cite" style=3D"margin:= 0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>3. Regener= ate a root-owned, user-readable (non-writeable) file<br></div><div>containi= ng the user's "age bracket" once per day via cron. The path &<br></div>= <div>its format (e.g. "UNDER_13") would be the API. Alternatively, to make<= br></div><div>it more portable, a script get-age-bracket could be provided.= 4.<br></div><div>Making the file/script available to sandboxes is a matter= of<br></div><div>configuration.<br></div><div><br></div><div>I don't think= XDG is a good place to implement this.<br></div></blockquote><div><br></di= v><div>My main motivation for proposing that this be done in XDG is to make= an<br></div><div>effort to make something that can be adopted more-or-less= widely in the<br></div><div>end. It's definitely true that every OS could = implement something<br></div><div>semi-bespoke like suggested here (or mayb= e this mechanism could end up<br></div><div>the standard). Personally I'd b= e perfectly happy with that solution,<br></div><div>but I don't think that'= s what the people who drafted the bill had in<br></div><div>mind when they = wrote it, and I'd like for Whonix to not come under fire<br></div><div>for = doing things "the wrong way". Even if ultimately no one wants a<br></div><d= iv>standardized solution, we can say we tried.<br></div><div><br></div><div= >--<br></div><div>Aaron<br></div></blockquote><div><br></div><div>I am also= not a lawyer but the law seems like it could easily be challenged and like= ly run afoul of privacy laws here in the US. The technical ramifications an= d enforcement of them can't be implemented in a way that wouldn't run afoul= of privacy related rights (yes, even children have privacy rights) and als= o present a security quagmire. Further it puts the onus all on the "develop= er" or OS vendor to essentially keep track and obey "signals", or be fined.= The spirit of the laws existence is to protect children but the implementa= tion of this or a path-forward almost seems farcical to discuss. It's very = clear it's drafting and implementation had no one who understands how this = works in the room, and if they were, they were summarily ignored. Getting a= head of it as you are, whatever solution, it won't matter, because every la= rger distro is likely to implement their own way-to-do and same with every = smaller one, and of course there will be those that ignore this completely = or stop distributing in California and states that adopt such a law. The la= w's spirit is in the right place, but it needs revision so it can be implem= ented appropriately.</div><div><br></div><div>Christopher Warner</div><div>= <span></span></div></body></html> --=-i6L18/zp6Q7gH0E5mFLU-- --=-qjwo49RqFmywhUmN+x16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iJUEABMJAB0WIQQ+F58QR5A+huBpLUjwXz63kF6WyAUCaaSzrAAKCRDwXz63kF6W yCMwAXwMXs6y0+o/qBqYlEv18A6woOR5QR+zGb7tPtlVX1mRPLXlJCrthIiN4y4f JWoiLoMBgPAlYpRlhDaEp56KjFVbxmkuQ7RCcBmEiDO54VBU153noehkvP4wAb1R cIlCJVV55g== =5UBz -----END PGP SIGNATURE----- --=-qjwo49RqFmywhUmN+x16--