Re: 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:00:54 -0500
| Newsgroups | gmane.linux.debian.devel.legal |
|---|---|
| Message-ID | <CAKiotKz7v01D9QcpfEWERJ1o+gpbe2q-4UDNvpRO8oRDaYo4Eg@mail.gmail.com> |
--000000000000460e79064d3ea2a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Will there be a way for developers of "ageless" linux distros (linux distros without age verification) to handle such a plan while still being able to opt out of age verification? On Tue, Mar 17, 2026, 12:48=E2=80=AFPM Marco Trevisan <marco.trevisan@canon= ical.com> 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 fo= r 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 hundred= s > > > of government censorship requirements that debian will presumably now > > > be following will result in much duplication of effort and an > > > unreliable user experience in which important censorship restrictions > > > may be missed and not implemented. As such, with people now supporti= ng > > > 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) are > > > 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 to > > > 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 also > > > 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 use= r > > > from being able to access other users=E2=80=99 personal information, = and to > > > ensure compliance with censorship regulations, no user may be able to > > > 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 chan= ge > > > 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 exampl= e, a unit > > > for Kazakhstan will implement the government-required backdoor, a uni= t > > > for China will implement keyword scans and web access blocks (more on > > > this later), a unit for Florida will ban all packages with =E2=80=9Ct= rans=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 preven= t > > > 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 give= n > > > location. > > > > > > All communication will be over D-Bus, with each application proactive= ly > > > asking systemd-censord for permission to perform any operations which > > > 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 med= ia > > > player keys and digital rights management content could also be added > > > 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 progra= m > > > structures as well as internet traffic. This daemon can then be > > > started with different filter configuration files for each systemd un= it > > > triggered by the user=E2=80=99s location. To comply with book bans c= ommon 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 functionali= ty > > > 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 bein= g > > > installed, written, or compiled, as any foreign sources of software m= ay > > > 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 modifie= d > > > 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 gov= ernment > > > 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 only > > > one regulation, such as California=E2=80=99s attempts to prevent mino= rs from > > > accessing unapproved information, makes no sense when there=E2=80=99s= 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 it > > and give me new ideas. > > > > Starting off, /etc/machine-id is generated upon new installations with > > systemd-firstboot, and it is unique to all systems. This means it can b= e > > used as a shared key along with a unique salt to prevent rainbow table > > 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 th= at > > hasn't had it before is now an unsupported configuration. Secondly, the > > 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 d= o > > 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 a= m > > 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 > > --000000000000460e79064d3ea2a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Will there be a way for developers of "ageless"= linux distros (linux distros without age verification) to handle such a pl= an while still being able to opt out of age verification?=C2=A0</div><br><d= iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar = 17, 2026, 12:48=E2=80=AFPM Marco Trevisan <<a href=3D"mailto:marco.trevi= [email protected]" target=3D"_blank" rel=3D"noreferrer">marco.trevisan@cano= nical.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On decry= ption, I don't think we've to create another specific<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 password<br> managers) it's a proper secure enclave in the linux systems using<br> Virtualization-Based Security (VBS).<br> <br> There are already some implementations for the Linux kernel on which<br> both MS and Amazon are working, and I feel that we should ensure that<br> the ecosystem is ready for that.<br> <br> See: <a href=3D"https://www.iinuwa.xyz/blog/linux-passkeys-update/#hardenin= g-platform-authenticator-credential-access" rel=3D"noreferrer noreferrer no= referrer" target=3D"_blank">https://www.iinuwa.xyz/blog/linux-passkeys-upda= te/#hardening-platform-authenticator-credential-access</a><br> <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" target=3D"_blank">disroot.or= g</a>) via<br> ubuntu-devel <<a href=3D"mailto:[email protected]" rel=3D"no= referrer noreferrer" target=3D"_blank">[email protected]</a>>= ; ha scritto:<br> ><br> > 4 Mar 2026 05:12:31 FloofyWolf <<a href=3D"mailto:debian-devel-list= @floofywolf.net" rel=3D"noreferrer noreferrer" target=3D"_blank">debian-dev= [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 unfortunate nee= d for an "age<br> > > verification" API for legal compliance reasons in some U.S. = states=E2=80=9D by<br> > > Aaron Rainbolt.=C2=A0 I believe the approach outlined to be very<= br> > > short-sighted, in that creating a bespoke API for each of the hun= dreds<br> > > of government censorship requirements that debian will presumably= now<br> > > be following will result in much duplication of effort and an<br> > > unreliable user experience in which important censorship restrict= ions<br> > > may be missed and not implemented.=C2=A0 As such, with people now= supporting<br> > > the idea that debian should implement government censorship reque= sts,<br> > > even creating new standards if needed, I propose the creation of = a<br> > > censorship framework to speed implementation of current and futur= e<br> > > censorship regulations.<br> > ><br> > > On installation, the user will be required to enter their locatio= n.<br> > > This information may be pre-filled if device location (GPS) or ot= her<br> > > sources of location data (IP geolocation, selected timezone, etc)= are<br> > > available.=C2=A0 If the user enters a location that does not matc= h any<br> > > gathered location data, this will be immediately stored and sent = to<br> > > authorities in both the detected location and the entered locatio= n to<br> > > alert them of a citizen potentially trying to evade censorship<br= > > > regulations.=C2=A0 If the location entered requires further infor= mation,<br> > > such as whether an encryption license has been acquired, the user= =E2=80=99s<br> > > age, etc, it will be requested at this point.=C2=A0 This process = will also<br> > > be repeated every time a user account is created, and will requir= e<br> > > implementation in both graphic and text-based account management<= br> > > utilities, such as adduser.<br> > ><br> > > This location and user data will be managed by a new daemon,<br> > > systemd-censord, and stored in an encrypted form and otherwise<br= > > > protected so as not to be readable or modifiable by any user on t= he<br> > > system.=C2=A0 To ensure privacy, great care must be taken to prev= ent a user<br> > > from being able to access other users=E2=80=99 personal informati= on, and to<br> > > ensure compliance with censorship regulations, no user may be abl= e to<br> > > change their location in any fashion which bypasses dedicated<br> > > utilities, which will perform the required location validation an= d<br> > > discrepancy authority notice functions when the user requests to = change<br> > > their location, such as for moving house or travel.<br> > ><br> > > Systemd units will be created for every desired censorship functi= on,<br> > > and will be started based on the user=E2=80=99s location.=C2=A0 F= or example, a unit<br> > > for Kazakhstan will implement the government-required backdoor, a= unit<br> > > for China will implement keyword scans and web access blocks (mor= e 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 fo= r<br> > > Oklahoma will ensure all educational software is compliant with t= he<br> > > Christian Holy Bible, a unit for the entire United States will pr= event<br> > > installation of any program capable of decoding DVD or BluRay med= ia,<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 started f= or a given<br> > > location.<br> > ><br> > > All communication will be over D-Bus, with each application proac= tively<br> > > asking systemd-censord for permission to perform any operations w= hich<br> > > may foreseeably be restricted anywhere in the world.=C2=A0 A stan= dardized<br> > > list of permissions will need to be developed, as well as standar= d<br> > > personal data fields, such as user age.=C2=A0 Blobs for the stora= ge of media<br> > > player keys and digital rights management content could also be a= dded<br> > > as additional functionality.<br> > ><br> > > Since keyword scanning and web filtering are extremely common<br> > > government interests, a dedicated daemon for this function should= be<br> > > created, with kernel hooks to allow inspection of all internal pr= ogram<br> > > structures as well as internet traffic.=C2=A0 This daemon can the= n be<br> > > started with different filter configuration files for each system= d unit<br> > > triggered by the user=E2=80=99s location.=C2=A0 To comply with bo= ok bans common in<br> > > many US states, such as those restricting access to books on<br> > > LGBTQ[[:alnum:]]* topics or having non-white characters, this mod= ule<br> > > should also automatically search the filesystem for prohibited eb= ook<br> > > files.<br> > ><br> > > Many packages will need to be altered to include specific functio= nality<br> > > relevant to censorship, including dpkg.=C2=A0 For example, instal= ling tor<br> > > will be prohibited in many countries, and some packages, like<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 use= r=E2=80=99s age to<br> > > all websites hosting applications for download.=C2=A0 Encryption = packages<br> > > will have to check if a systemd unit limiting encryption strength= is<br> > > running, and set their maximum key length, disable features, or s= end<br> > > private keys to a specified IP address determined by the unit.<br= > > ><br> > > To prevent users from bypassing censorship requirements, debian w= ill<br> > > need to switch to being a binary-only distribution with signed<br= > > > binaries, signed kernel, and signed kernel modules, with mandator= y<br> > > secureboot, and controls to prevent any non-signed software from = being<br> > > installed, written, or compiled, as any foreign sources of softwa= re may<br> > > fail to query systemd-censord or may fail to respect the permissi= ons it<br> > > returns.<br> > ><br> > > On the non-software side, the debian licenses will need to be mod= ified<br> > > to disallow removal or alteration of any of these features by<br> > > derivative distributions =E2=80=93 for example, no distribution w= ill be allowed<br> > > to ship without systemd because then systemd-censord may not work= <br> > > correctly.=C2=A0 In addition, the licenses for all packaged softw= are will<br> > > need to be amended to disallow removal of censorship functionalit= y.<br> > ><br> > > As I=E2=80=99m sure is obvious, if debian is going to comply with= government<br> > > censorship regulations, a universal framework allowing easy addit= ion of<br> > > new rules will greatly reduce developer time over individual ad-h= oc<br> > > implementations of each new freedom restriction.=C2=A0 Complying = with only<br> > > one regulation, such as California=E2=80=99s attempts to prevent = minors from<br> > > accessing unapproved information, makes no sense when there=E2=80= =99s hundreds<br> > > or thousands of other regulations not currently being complied wi= th.<br> > > This framework should ensure all users get to experience their fu= ll<br> > > censorship regime no matter where they are in the world.<br> > ><br> > > Thanks for reading, and I hope we can work together to help 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 decrypt it= , I<br> > have an idea for. It requires /etc/machine-id, AppArmor or SELinux, FD= E,<br> > and a new *specially* compiled kernel module. Feel free to critique it= <br> > and give me new ideas.<br> ><br> > Starting off, /etc/machine-id is generated upon new installations 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 rainbow table= <br> > attacks. This would be pretty bad for anyone to see publicly, so now w= e<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 t= hat<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 module<br> > decrypts systemd-censord using the machine-id and salt, runs it, and<b= r> > 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 point. 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"noreferrer nor= eferrer" target=3D"_blank">[email protected]</a><br> > Modify settings or unsubscribe at: <a href=3D"https://lists.ubuntu.com= /mailman/listinfo/ubuntu-devel" rel=3D"noreferrer noreferrer noreferrer" ta= rget=3D"_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a><= br> <br> </blockquote></div> --000000000000460e79064d3ea2a0--