Fwd: On the need for a censorship API for legal compliance reasons in some countries and U.S. states
Adenix NPSP <[email protected]> Tue, 17 Mar 2026 16:58:32 -0500
| Newsgroups | gmane.linux.debian.devel.legal |
|---|---|
| Message-ID | <CAKiotKx5h=Ev=QsL3R4gdQ1_tupS095mD3FyAY1TmmytJ2OBVg@mail.gmail.com> |
--00000000000065c3a3064d3f70ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: Adenix NPSP <[email protected]> Date: Tue, Mar 17, 2026, 4:56=E2=80=AFPM Subject: Re: On the need for a censorship API for legal compliance reasons in some countries and U.S. states To: Jamie Null <[email protected]> What I'm trying to do is gather the info I need to prevent AdenosineOS 8 from being the first version with age verification. On Tue, Mar 17, 2026, 4:48=E2=80=AFPM Jamie Null <[email protected]> wrote= : > I'm going to hope that this is all satire. > > -- Jamie > > On 2026-03-17 14:00, Adenix NPSP wrote: > > Will there be a way for developers of "ageless" linux distros (linux > > distros without age verification) to handle such a plan while still bei= ng > > able to opt out of age verification? > > > > On Tue, Mar 17, 2026, 12:48=E2=80=AFPM Marco Trevisan < > [email protected]> > > wrote: > > > >> On decryption, I don't think we've to create another specific > >> implementation for this. > >> > >> What we all need (pretty desperately TBH, and for many things that > >> goes from authentication systems up to proper keyrings and password > >> managers) it's a proper secure enclave in the linux systems using > >> Virtualization-Based Security (VBS). > >> > >> There are already some implementations for the Linux kernel on which > >> both MS and Amazon are working, and I feel that we should ensure that > >> the ecosystem is ready for that. > >> > >> See: > >> > https://www.iinuwa.xyz/blog/linux-passkeys-update/#hardening-platform-aut= henticator-credential-access > >> > >> Cheers > >> > >> Il giorno dom 8 mar 2026 alle ore 16:21 Personal (disroot.org) via > >> ubuntu-devel <[email protected]> ha scritto: > >>> > >>> 4 Mar 2026 05:12:31 FloofyWolf <[email protected]>: > >>> > >>>> Recently, a proposal has been made to implement an API for a new > >>>> California censorship regulation, =E2=80=9COn the unfortunate need f= or an "age > >>>> verification" API for legal compliance reasons in some U.S. states= =E2=80=9D by > >>>> Aaron Rainbolt. I believe the approach outlined to be very > >>>> short-sighted, in that creating a bespoke API for each of the hundre= ds > >>>> of government censorship requirements that debian will presumably no= w > >>>> be following will result in much duplication of effort and an > >>>> unreliable user experience in which important censorship restriction= s > >>>> may be missed and not implemented. As such, with people now > supporting > >>>> the idea that debian should implement government censorship requests= , > >>>> even creating new standards if needed, I propose the creation of a > >>>> censorship framework to speed implementation of current and future > >>>> censorship regulations. > >>>> > >>>> On installation, the user will be required to enter their location. > >>>> This information may be pre-filled if device location (GPS) or other > >>>> sources of location data (IP geolocation, selected timezone, etc) ar= e > >>>> available. If the user enters a location that does not match any > >>>> gathered location data, this will be immediately stored and sent to > >>>> authorities in both the detected location and the entered location t= o > >>>> alert them of a citizen potentially trying to evade censorship > >>>> regulations. If the location entered requires further information, > >>>> such as whether an encryption license has been acquired, the user=E2= =80=99s > >>>> age, etc, it will be requested at this point. This process will als= o > >>>> be repeated every time a user account is created, and will require > >>>> implementation in both graphic and text-based account management > >>>> utilities, such as adduser. > >>>> > >>>> This location and user data will be managed by a new daemon, > >>>> systemd-censord, and stored in an encrypted form and otherwise > >>>> protected so as not to be readable or modifiable by any user on the > >>>> system. To ensure privacy, great care must be taken to prevent a us= er > >>>> from being able to access other users=E2=80=99 personal information,= and to > >>>> ensure compliance with censorship regulations, no user may be able t= o > >>>> change their location in any fashion which bypasses dedicated > >>>> utilities, which will perform the required location validation and > >>>> discrepancy authority notice functions when the user requests to > change > >>>> their location, such as for moving house or travel. > >>>> > >>>> Systemd units will be created for every desired censorship function, > >>>> and will be started based on the user=E2=80=99s location. For examp= le, a unit > >>>> for Kazakhstan will implement the government-required backdoor, a un= it > >>>> for China will implement keyword scans and web access blocks (more o= n > >>>> this later), a unit for Florida will ban all packages with =E2=80=9C= trans=E2=80=9D in > >>>> the name (201 packages in current stable distribution), a unit for > >>>> Oklahoma will ensure all educational software is compliant with the > >>>> Christian Holy Bible, a unit for the entire United States will preve= nt > >>>> installation of any program capable of decoding DVD or BluRay media, > >>>> and a unit for California will provide the user=E2=80=99s age to all > >>>> applications and all web sites from which applications may be > >>>> downloaded. As can be seen, multiple units may be started for a giv= en > >>>> location. > >>>> > >>>> All communication will be over D-Bus, with each application > proactively > >>>> asking systemd-censord for permission to perform any operations whic= h > >>>> may foreseeably be restricted anywhere in the world. A standardized > >>>> list of permissions will need to be developed, as well as standard > >>>> personal data fields, such as user age. Blobs for the storage of > media > >>>> player keys and digital rights management content could also be adde= d > >>>> as additional functionality. > >>>> > >>>> Since keyword scanning and web filtering are extremely common > >>>> government interests, a dedicated daemon for this function should be > >>>> created, with kernel hooks to allow inspection of all internal progr= am > >>>> structures as well as internet traffic. This daemon can then be > >>>> started with different filter configuration files for each systemd > unit > >>>> triggered by the user=E2=80=99s location. To comply with book bans = common in > >>>> many US states, such as those restricting access to books on > >>>> LGBTQ[[:alnum:]]* topics or having non-white characters, this module > >>>> should also automatically search the filesystem for prohibited ebook > >>>> files. > >>>> > >>>> Many packages will need to be altered to include specific > functionality > >>>> relevant to censorship, including dpkg. For example, installing tor > >>>> will be prohibited in many countries, and some packages, like > >>>> fortunes-off, will be restricted based on the user=E2=80=99s age, as= will most > >>>> games. Web browsers will have to be patched to send the user=E2=80= =99s age to > >>>> all websites hosting applications for download. Encryption packages > >>>> will have to check if a systemd unit limiting encryption strength is > >>>> running, and set their maximum key length, disable features, or send > >>>> private keys to a specified IP address determined by the unit. > >>>> > >>>> To prevent users from bypassing censorship requirements, debian will > >>>> need to switch to being a binary-only distribution with signed > >>>> binaries, signed kernel, and signed kernel modules, with mandatory > >>>> secureboot, and controls to prevent any non-signed software from bei= ng > >>>> installed, written, or compiled, as any foreign sources of software > may > >>>> fail to query systemd-censord or may fail to respect the permissions > it > >>>> returns. > >>>> > >>>> On the non-software side, the debian licenses will need to be modifi= ed > >>>> to disallow removal or alteration of any of these features by > >>>> derivative distributions =E2=80=93 for example, no distribution will= be > allowed > >>>> to ship without systemd because then systemd-censord may not work > >>>> correctly. In addition, the licenses for all packaged software will > >>>> need to be amended to disallow removal of censorship functionality. > >>>> > >>>> As I=E2=80=99m sure is obvious, if debian is going to comply with go= vernment > >>>> censorship regulations, a universal framework allowing easy addition > of > >>>> new rules will greatly reduce developer time over individual ad-hoc > >>>> implementations of each new freedom restriction. Complying with onl= y > >>>> one regulation, such as California=E2=80=99s attempts to prevent min= ors from > >>>> accessing unapproved information, makes no sense when there=E2=80=99= s hundreds > >>>> or thousands of other regulations not currently being complied with. > >>>> This framework should ensure all users get to experience their full > >>>> censorship regime no matter where they are in the world. > >>>> > >>>> Thanks for reading, and I hope we can work together to help Linux > >>>> implement as much censorship as possible! > >>>> --Floofy Wolf > >>> > >>> Nice work! > >>> > >>> I would agree with encrypting systemd-censord, but *how* to decrypt > it, I > >>> have an idea for. It requires /etc/machine-id, AppArmor or SELinux, > FDE, > >>> and a new *specially* compiled kernel module. Feel free to critique i= t > >>> and give me new ideas. > >>> > >>> Starting off, /etc/machine-id is generated upon new installations wit= h > >>> systemd-firstboot, and it is unique to all systems. This means it can > be > >>> used as a shared key along with a unique salt to prevent rainbow tabl= e > >>> attacks. This would be pretty bad for anyone to see publicly, so now = we > >>> have to come up with a solution. > >>> > >>> My solution to this is FDE with TPM2, a kernel module, and an MAC. > >>> Firstly, all systems must have FDE with TPM2 from hereon. Any system > that > >>> hasn't had it before is now an unsupported configuration. Secondly, t= he > >>> new kernel module is included in the initramfs so that it can start > >>> reading /etc/machine-id after root is mounted, but before any MAC can > do > >>> anything to prevent it from being seen. Finally, the kernel module > >>> decrypts systemd-censord using the machine-id and salt, runs it, and > >>> encrypts it again. For good measure, AppArmor or SELinux would hide > >>> systemd-censord and the kernel modules. > >>> > >>> This is not fully concrete, but I believe this is a starting point. I > am > >>> fully open to other ideas. > >>> > >>> Cheers, > >>> > >>> -- > >>> Artur Manuel > >>> amadaluzia > >>> > >>> -- > >>> ubuntu-devel mailing list > >>> [email protected] > >>> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > >> > >> > > > > -- > Jamie Null (They/Them) > E: [email protected] > > Attn: Key EC31 8C72 C7CB 900E A0FC is revoked as of 2026-01-29T08:30Z. > > "A person cannot be made to suffer a grossly disproportionate punishment > simply to send a message to discourage others from offending." =E2=80=94 = R v. > Nur, 2015 SCC 15, [2015] 1 S.C.R. 773, per McLachlin CJ, at para 45 > > --00000000000065c3a3064d3f70ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto"></div><br><div class=3D"gmail_quote"><d= iv dir=3D"ltr" class=3D"gmail_attr">---------- Forwarded message ---------<= br>From: <strong class=3D"gmail_sendername" dir=3D"auto">Adenix NPSP</stron= g> <span dir=3D"auto"><<a href=3D"mailto:[email protected]" target=3D= "_blank" rel=3D"noreferrer">[email protected]</a>></span><br>Date: Tu= e, Mar 17, 2026, 4:56=E2=80=AFPM<br>Subject: Re: On the need for a censorsh= ip API for legal compliance reasons in some countries and U.S. states<br>To= : Jamie Null <[email protected]><br></div><br><br><div dir=3D"auto">= What I'm trying to do is gather the info I need to prevent AdenosineOS = 8 from being the first version with age verification.</div><br><div class= =3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 17, 2026= , 4:48=E2=80=AFPM Jamie Null <[email protected]> wrote:<br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex">I'm going to hope that this is all satire.<= br> <br> -- Jamie<br> <br> On 2026-03-17 14:00, Adenix NPSP wrote:<br> > Will there be a way for developers of "ageless" linux distro= s (linux<br> > distros without age verification) to handle such a plan while still be= ing<br> > able to opt out of age verification?<br> > <br> > On Tue, Mar 17, 2026, 12:48=E2=80=AFPM Marco Trevisan <<a href=3D"m= ailto:[email protected]" rel=3D"noreferrer noreferrer noreferrer= " target=3D"_blank">[email protected]</a>><br> > wrote:<br> > <br> >> On decryption, I don't think we've to create another speci= fic<br> >> implementation for this.<br> >><br> >> What we all need (pretty desperately TBH, and for many things that= <br> >> goes from authentication systems up to proper keyrings and passwor= d<br> >> managers) it's a proper secure enclave in the linux systems us= ing<br> >> Virtualization-Based Security (VBS).<br> >><br> >> There are already some implementations for the Linux kernel on whi= ch<br> >> both MS and Amazon are working, and I feel that we should ensure t= hat<br> >> the ecosystem is ready for that.<br> >><br> >> See:<br> >> <a href=3D"https://www.iinuwa.xyz/blog/linux-passkeys-update/#hard= ening-platform-authenticator-credential-access" rel=3D"noreferrer noreferre= r noreferrer noreferrer" target=3D"_blank">https://www.iinuwa.xyz/blog/linu= x-passkeys-update/#hardening-platform-authenticator-credential-access</a><b= r> >><br> >> Cheers<br> >><br> >> Il giorno dom 8 mar 2026 alle ore 16:21 Personal (<a href=3D"http:= //disroot.org" rel=3D"noreferrer noreferrer noreferrer noreferrer" target= =3D"_blank">disroot.org</a>) via<br> >> ubuntu-devel <<a href=3D"mailto:[email protected]" = rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">ubuntu-devel@lis= ts.ubuntu.com</a>> ha scritto:<br> >>><br> >>> 4 Mar 2026 05:12:31 FloofyWolf <<a href=3D"mailto:debian-de= [email protected]" rel=3D"noreferrer noreferrer noreferrer" target=3D= "_blank">[email protected]</a>>:<br> >>><br> >>>> Recently, a proposal has been made to implement an API for= a new<br> >>>> California censorship regulation, =E2=80=9COn the unfortun= ate need for an "age<br> >>>> verification" API for legal compliance reasons in som= e U.S. states=E2=80=9D by<br> >>>> Aaron Rainbolt.=C2=A0 I believe the approach outlined to b= e very<br> >>>> short-sighted, in that creating a bespoke API for each of = the hundreds<br> >>>> of government censorship requirements that debian will pre= sumably now<br> >>>> be following will result in much duplication of effort and= an<br> >>>> unreliable user experience in which important censorship r= estrictions<br> >>>> may be missed and not implemented.=C2=A0 As such, with peo= ple now supporting<br> >>>> the idea that debian should implement government censorshi= p requests,<br> >>>> even creating new standards if needed, I propose the creat= ion of a<br> >>>> censorship framework to speed implementation of current an= d future<br> >>>> censorship regulations.<br> >>>><br> >>>> On installation, the user will be required to enter their = location.<br> >>>> This information may be pre-filled if device location (GPS= ) or other<br> >>>> sources of location data (IP geolocation, selected timezon= e, etc) are<br> >>>> available.=C2=A0 If the user enters a location that does n= ot match any<br> >>>> gathered location data, this will be immediately stored an= d sent to<br> >>>> authorities in both the detected location and the entered = location to<br> >>>> alert them of a citizen potentially trying to evade censor= ship<br> >>>> regulations.=C2=A0 If the location entered requires furthe= r information,<br> >>>> such as whether an encryption license has been acquired, t= he user=E2=80=99s<br> >>>> age, etc, it will be requested at this point.=C2=A0 This p= rocess will also<br> >>>> be repeated every time a user account is created, and will= require<br> >>>> implementation in both graphic and text-based account mana= gement<br> >>>> utilities, such as adduser.<br> >>>><br> >>>> This location and user data will be managed by a new daemo= n,<br> >>>> systemd-censord, and stored in an encrypted form and other= wise<br> >>>> protected so as not to be readable or modifiable by any us= er on the<br> >>>> system.=C2=A0 To ensure privacy, great care must be taken = to prevent a user<br> >>>> from being able to access other users=E2=80=99 personal in= formation, and to<br> >>>> ensure compliance with censorship regulations, no user may= be able to<br> >>>> change their location in any fashion which bypasses dedica= ted<br> >>>> utilities, which will perform the required location valida= tion and<br> >>>> discrepancy authority notice functions when the user reque= sts to change<br> >>>> their location, such as for moving house or travel.<br> >>>><br> >>>> Systemd units will be created for every desired censorship= function,<br> >>>> and will be started based on the user=E2=80=99s location.= =C2=A0 For example, a unit<br> >>>> for Kazakhstan will implement the government-required back= door, a unit<br> >>>> for China will implement keyword scans and web access bloc= ks (more on<br> >>>> this later), a unit for Florida will ban all packages with= =E2=80=9Ctrans=E2=80=9D in<br> >>>> the name (201 packages in current stable distribution), a = unit for<br> >>>> Oklahoma will ensure all educational software is compliant= with the<br> >>>> Christian Holy Bible, a unit for the entire United States = will prevent<br> >>>> installation of any program capable of decoding DVD or Blu= Ray media,<br> >>>> and a unit for California will provide the user=E2=80=99s = age to all<br> >>>> applications and all web sites from which applications may= be<br> >>>> downloaded.=C2=A0 As can be seen, multiple units may be st= arted for a given<br> >>>> location.<br> >>>><br> >>>> All communication will be over D-Bus, with each applicatio= n proactively<br> >>>> asking systemd-censord for permission to perform any opera= tions which<br> >>>> may foreseeably be restricted anywhere in the world.=C2=A0= A standardized<br> >>>> list of permissions will need to be developed, as well as = standard<br> >>>> personal data fields, such as user age.=C2=A0 Blobs for th= e storage of media<br> >>>> player keys and digital rights management content could al= so be added<br> >>>> as additional functionality.<br> >>>><br> >>>> Since keyword scanning and web filtering are extremely com= mon<br> >>>> government interests, a dedicated daemon for this function= should be<br> >>>> created, with kernel hooks to allow inspection of all inte= rnal program<br> >>>> structures as well as internet traffic.=C2=A0 This daemon = can then be<br> >>>> started with different filter configuration files for each= systemd unit<br> >>>> triggered by the user=E2=80=99s location.=C2=A0 To comply = with book bans common in<br> >>>> many US states, such as those restricting access to books = on<br> >>>> LGBTQ[[:alnum:]]* topics or having non-white characters, t= his module<br> >>>> should also automatically search the filesystem for prohib= ited ebook<br> >>>> files.<br> >>>><br> >>>> Many packages will need to be altered to include specific = functionality<br> >>>> relevant to censorship, including dpkg.=C2=A0 For example,= installing tor<br> >>>> will be prohibited in many countries, and some packages, l= ike<br> >>>> fortunes-off, will be restricted based on the user=E2=80= =99s age, as will most<br> >>>> games.=C2=A0 Web browsers will have to be patched to send = the user=E2=80=99s age to<br> >>>> all websites hosting applications for download.=C2=A0 Encr= yption packages<br> >>>> will have to check if a systemd unit limiting encryption s= trength is<br> >>>> running, and set their maximum key length, disable feature= s, or send<br> >>>> private keys to a specified IP address determined by the u= nit.<br> >>>><br> >>>> To prevent users from bypassing censorship requirements, d= ebian will<br> >>>> need to switch to being a binary-only distribution with si= gned<br> >>>> binaries, signed kernel, and signed kernel modules, with m= andatory<br> >>>> secureboot, and controls to prevent any non-signed softwar= e from being<br> >>>> installed, written, or compiled, as any foreign sources of= software may<br> >>>> fail to query systemd-censord or may fail to respect the p= ermissions it<br> >>>> returns.<br> >>>><br> >>>> On the non-software side, the debian licenses will need to= be modified<br> >>>> to disallow removal or alteration of any of these features= by<br> >>>> derivative distributions =E2=80=93 for example, no distrib= ution will be allowed<br> >>>> to ship without systemd because then systemd-censord may n= ot work<br> >>>> correctly.=C2=A0 In addition, the licenses for all package= d software will<br> >>>> need to be amended to disallow removal of censorship funct= ionality.<br> >>>><br> >>>> As I=E2=80=99m sure is obvious, if debian is going to comp= ly with government<br> >>>> censorship regulations, a universal framework allowing eas= y addition of<br> >>>> new rules will greatly reduce developer time over individu= al ad-hoc<br> >>>> implementations of each new freedom restriction.=C2=A0 Com= plying with only<br> >>>> one regulation, such as California=E2=80=99s attempts to p= revent minors from<br> >>>> accessing unapproved information, makes no sense when ther= e=E2=80=99s hundreds<br> >>>> or thousands of other regulations not currently being comp= lied with.<br> >>>> This framework should ensure all users get to experience t= heir full<br> >>>> censorship regime no matter where they are in the world.<b= r> >>>><br> >>>> Thanks for reading, and I hope we can work together to hel= p Linux<br> >>>> implement as much censorship as possible!<br> >>>> --Floofy Wolf<br> >>><br> >>> Nice work!<br> >>><br> >>> I would agree with encrypting systemd-censord, but *how* to de= crypt it, I<br> >>> have an idea for. It requires /etc/machine-id, AppArmor or SEL= inux, FDE,<br> >>> and a new *specially* compiled kernel module. Feel free to cri= tique it<br> >>> and give me new ideas.<br> >>><br> >>> Starting off, /etc/machine-id is generated upon new installati= ons with<br> >>> systemd-firstboot, and it is unique to all systems. This means= it can be<br> >>> used as a shared key along with a unique salt to prevent rainb= ow table<br> >>> attacks. This would be pretty bad for anyone to see publicly, = so now we<br> >>> have to come up with a solution.<br> >>><br> >>> My solution to this is FDE with TPM2, a kernel module, and an = MAC.<br> >>> Firstly, all systems must have FDE with TPM2 from hereon. Any = system that<br> >>> hasn't had it before is now an unsupported configuration. = Secondly, the<br> >>> new kernel module is included in the initramfs so that it can = start<br> >>> reading /etc/machine-id after root is mounted, but before any = MAC can do<br> >>> anything to prevent it from being seen. Finally, the kernel mo= dule<br> >>> decrypts systemd-censord using the machine-id and salt, runs i= t, and<br> >>> encrypts it again. For good measure, AppArmor or SELinux would= hide<br> >>> systemd-censord and the kernel modules.<br> >>><br> >>> This is not fully concrete, but I believe this is a starting p= oint. I am<br> >>> fully open to other ideas.<br> >>><br> >>> Cheers,<br> >>><br> >>> --<br> >>> Artur Manuel<br> >>> amadaluzia<br> >>><br> >>> --<br> >>> ubuntu-devel mailing list<br> >>> <a href=3D"mailto:[email protected]" rel=3D"norefe= rrer noreferrer noreferrer" target=3D"_blank">[email protected]= </a><br> >>> Modify settings or unsubscribe at:<br> >> <a href=3D"https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel"= rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">http= s://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><br> >><br> >><br> > <br> <br> -- <br> Jamie Null (They/Them)<br> E: [email protected]<br> <br> Attn: Key EC31 8C72 C7CB 900E A0FC is revoked as of 2026-01-29T08:30Z.<br> <br> "A person cannot be made to suffer a grossly disproportionate punishme= nt<br> simply to send a message to discourage others from offending." =E2=80= =94 R v.<br> Nur, 2015 SCC 15, [2015] 1 S.C.R. 773, per McLachlin CJ, at para 45<br> <br> </blockquote></div> </div></div> --00000000000065c3a3064d3f70ad--