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 18:09:34 -0500
| Newsgroups | gmane.linux.debian.devel.legal |
|---|---|
| Message-ID | <CAKiotKyoLvHkp9dubonLef=-oGVxOFn-3rTb2n6UaoyyMMyGkQ@mail.gmail.com> |
--0000000000006d959e064d406ed7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As long as the API doesn't get as much encryption as Fort Knox, I should be able to find a way to disable it. On Tue, Mar 17, 2026, 5:02=E2=80=AFPM Jamie Null <[email protected]> wrote= : > Fair enough. I would assume you can patch out all the age verification > stuff. > > To be honest I would be damned if the Projects actually end up > implementing age verification because three jurisdictions asked them to > do so. It would also establish some sort of precedence for non-western > countries known for mass surveillance (such as China or the DPRK) to > make similar demands. > > -- Jamie > > On 2026-03-17 14:56, Adenix NPSP wrote: > > 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]> w= rote: > > > >> 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 > being > >>> 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 tha= t > >>>> 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= for 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 > hundreds > >>>>>> 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 > >> 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 oth= er > >>>>>> 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 t= o > >>>>>> 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 th= e > >>>>>> system. To ensure privacy, great care must be taken to prevent a > user > >>>>>> from being able to access other users=E2=80=99 personal informatio= n, 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 > >> change > >>>>>> their location, such as for moving house or travel. > >>>>>> > >>>>>> Systemd units will be created for every desired censorship functio= n, > >>>>>> and will be started based on the user=E2=80=99s location. For exa= mple, a > unit > >>>>>> for Kazakhstan will implement the government-required backdoor, a > unit > >>>>>> 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= =9Ctrans=E2=80=9D > in > >>>>>> the name (201 packages in current stable distribution), a unit for > >>>>>> Oklahoma will ensure all educational software is compliant with th= e > >>>>>> Christian Holy Bible, a unit for the entire United States will > prevent > >>>>>> installation of any program capable of decoding DVD or BluRay medi= a, > >>>>>> and a unit for California will provide the user=E2=80=99s age to a= ll > >>>>>> applications and all web sites from which applications may be > >>>>>> downloaded. As can be seen, multiple units may be started for a > given > >>>>>> location. > >>>>>> > >>>>>> All communication will be over D-Bus, with each application > >> proactively > >>>>>> asking systemd-censord for permission to perform any operations > which > >>>>>> may foreseeably be restricted anywhere in the world. A standardiz= ed > >>>>>> 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 > 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 > program > >>>>>> 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 ban= s common > in > >>>>>> many US states, such as those restricting access to books on > >>>>>> LGBTQ[[:alnum:]]* topics or having non-white characters, this modu= le > >>>>>> should also automatically search the filesystem for prohibited ebo= ok > >>>>>> files. > >>>>>> > >>>>>> Many packages will need to be altered to include specific > >> functionality > >>>>>> relevant to censorship, including dpkg. For example, installing t= or > >>>>>> 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 packag= es > >>>>>> will have to check if a systemd unit limiting encryption strength = is > >>>>>> running, and set their maximum key length, disable features, or se= nd > >>>>>> private keys to a specified IP address determined by the unit. > >>>>>> > >>>>>> To prevent users from bypassing censorship requirements, debian wi= ll > >>>>>> 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 > being > >>>>>> installed, written, or compiled, as any foreign sources of softwar= e > >> may > >>>>>> fail to query systemd-censord or may fail to respect the permissio= ns > >> it > >>>>>> returns. > >>>>>> > >>>>>> On the non-software side, the debian licenses will need to be > modified > >>>>>> to disallow removal or alteration of any of these features by > >>>>>> derivative distributions =E2=80=93 for example, no distribution wi= ll be > >> allowed > >>>>>> to ship without systemd because then systemd-censord may not work > >>>>>> correctly. In addition, the licenses for all packaged software wi= ll > >>>>>> 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 = government > >>>>>> censorship regulations, a universal framework allowing easy additi= on > >> of > >>>>>> new rules will greatly reduce developer time over individual ad-ho= c > >>>>>> implementations of each new freedom restriction. Complying with > only > >>>>>> one regulation, such as California=E2=80=99s attempts to prevent m= inors from > >>>>>> accessing unapproved information, makes no sense when there=E2=80= =99s > hundreds > >>>>>> or thousands of other regulations not currently being complied wit= h. > >>>>>> This framework should ensure all users get to experience their ful= l > >>>>>> 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 c= an > >> be > >>>>> 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 no= w > 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 syste= m > >> that > >>>>> 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 c= an > >> do > >>>>> anything to prevent it from being seen. Finally, the kernel module > >>>>> decrypts systemd-censord using the machine-id and salt, runs it, an= d > >>>>> 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 punishme= nt > >> 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 > >> > >> > > > > -- > Jamie Null (They/Them) > E: [email protected] > > Attn: Key EC31 8C72 C7CB 900E A0FC is revoked as of 2026-01-29T08:30Z. > > "Rule 1.03 defines plaintiff as 'a person who commences an action'. The > New Shorter Oxford English Dictionary defines person as 'an individual > human being'. [...] The entire basis of Mr. Joly's actions is that he is > a martian, not a human being. [...] I conclude therefore, that Mr. Joly, > on his pleading as drafted, has no status before the Court." =E2=80=94 Jo= ly v > Pelletier, [1999] OJ No 1728, 1999 CarswellOnt 1587, at para 11 > > --0000000000006d959e064d406ed7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">As long as the API doesn't get as much encryption as = Fort Knox, I should be able to find a way to disable it.</div><br><div clas= s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att= r">On Tue, Mar 17, 2026, 5:02=E2=80=AFPM Jamie Null <[email protected]&= gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex">Fair enough. I would ass= ume you can patch out all the age verification<br> stuff.<br> <br> To be honest I would be damned if the Projects actually end up<br> implementing age verification because three jurisdictions asked them to<br> do so. It would also establish some sort of precedence for non-western<br> countries known for mass surveillance (such as China or the DPRK) to<br> make similar demands.<br> <br> -- Jamie<br> <br> On 2026-03-17 14:56, Adenix NPSP wrote:<br> > What I'm trying to do is gather the info I need to prevent Adenosi= neOS 8<br> > from being the first version with age verification.<br> > <br> > On Tue, Mar 17, 2026, 4:48=E2=80=AFPM Jamie Null <[email protected]= h> wrote:<br> > <br> >> 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" linu= x distros (linux<br> >>> distros without age verification) to handle such a plan while = still being<br> >>> able to opt out of age verification?<br> >>><br> >>> On Tue, Mar 17, 2026, 12:48=E2=80=AFPM Marco Trevisan <<br> >> <a href=3D"mailto:[email protected]" target=3D"_blank" = rel=3D"noreferrer">[email protected]</a>><br> >>> wrote:<br> >>><br> >>>> On decryption, I don't think we've to create anoth= er specific<br> >>>> implementation for this.<br> >>>><br> >>>> What we all need (pretty desperately TBH, and for many thi= ngs that<br> >>>> goes from authentication systems up to proper keyrings and= password<br> >>>> managers) it's a proper secure enclave in the linux sy= stems using<br> >>>> Virtualization-Based Security (VBS).<br> >>>><br> >>>> There are already some implementations for the Linux kerne= l 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:<br> >>>><br> >> <a href=3D"https://www.iinuwa.xyz/blog/linux-passkeys-update/#hard= ening-platform-authenticator-credential-access" rel=3D"noreferrer noreferre= r" target=3D"_blank">https://www.iinuwa.xyz/blog/linux-passkeys-update/#har= dening-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" target=3D"_blank">dis= root.org</a>) via<br> >>>> ubuntu-devel <<a href=3D"mailto:[email protected]= tu.com" target=3D"_blank" rel=3D"noreferrer">[email protected]<= /a>> ha scritto:<br> >>>>><br> >>>>> 4 Mar 2026 05:12:31 FloofyWolf <<a href=3D"mailto:d= [email protected]" target=3D"_blank" rel=3D"noreferrer">debia= [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 need for an "age<br> >>>>>> verification" API for legal compliance reason= s in some U.S. states=E2=80=9D by<br> >>>>>> Aaron Rainbolt.=C2=A0 I believe the approach outli= ned to be very<br> >>>>>> short-sighted, in that creating a bespoke API for = each of the hundreds<br> >>>>>> of government censorship requirements that debian = will presumably now<br> >>>>>> be following will result in much duplication of ef= fort and an<br> >>>>>> unreliable user experience in which important cens= orship restrictions<br> >>>>>> may be missed and not implemented.=C2=A0 As such, = with people now<br> >> supporting<br> >>>>>> the idea that debian should implement government c= ensorship requests,<br> >>>>>> even creating new standards if needed, I propose t= he creation of a<br> >>>>>> censorship framework to speed implementation of cu= rrent and future<br> >>>>>> censorship regulations.<br> >>>>>><br> >>>>>> On installation, the user will be required to ente= r their location.<br> >>>>>> This information may be pre-filled if device locat= ion (GPS) or other<br> >>>>>> sources of location data (IP geolocation, selected= timezone, etc) are<br> >>>>>> available.=C2=A0 If the user enters a location tha= t does not match any<br> >>>>>> gathered location data, this will be immediately s= tored and sent to<br> >>>>>> authorities in both the detected location and the = entered location to<br> >>>>>> alert them of a citizen potentially trying to evad= e censorship<br> >>>>>> regulations.=C2=A0 If the location entered require= s further information,<br> >>>>>> such as whether an encryption license has been acq= uired, 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 require<br> >>>>>> implementation in both graphic and text-based acco= unt management<br> >>>>>> utilities, such as adduser.<br> >>>>>><br> >>>>>> This location and user data will be managed by a n= ew daemon,<br> >>>>>> systemd-censord, and stored in an encrypted form a= nd otherwise<br> >>>>>> protected so as not to be readable or modifiable b= y any user on the<br> >>>>>> system.=C2=A0 To ensure privacy, great care must b= e taken to prevent a user<br> >>>>>> from being able to access other users=E2=80=99 per= sonal information, and to<br> >>>>>> ensure compliance with censorship regulations, no = user may be able to<br> >>>>>> change their location in any fashion which bypasse= s dedicated<br> >>>>>> utilities, which will perform the required locatio= n validation and<br> >>>>>> discrepancy authority notice functions when the us= er requests to<br> >> change<br> >>>>>> their location, such as for moving house or travel= .<br> >>>>>><br> >>>>>> Systemd units will be created for every desired ce= nsorship function,<br> >>>>>> and will be started based on the user=E2=80=99s lo= cation.=C2=A0 For example, a unit<br> >>>>>> for Kazakhstan will implement the government-requi= red backdoor, a unit<br> >>>>>> for China will implement keyword scans and web acc= ess blocks (more on<br> >>>>>> this later), a unit for Florida will ban all packa= ges with =E2=80=9Ctrans=E2=80=9D in<br> >>>>>> the name (201 packages in current stable distribut= ion), a unit for<br> >>>>>> Oklahoma will ensure all educational software is c= ompliant with the<br> >>>>>> Christian Holy Bible, a unit for the entire United= States will prevent<br> >>>>>> installation of any program capable of decoding DV= D or BluRay 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 applicat= ions may be<br> >>>>>> downloaded.=C2=A0 As can be seen, multiple units m= ay be started for a given<br> >>>>>> location.<br> >>>>>><br> >>>>>> All communication will be over D-Bus, with each ap= plication<br> >> proactively<br> >>>>>> asking systemd-censord for permission to perform a= ny operations which<br> >>>>>> may foreseeably be restricted anywhere in the worl= d.=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 Blob= s for the storage of<br> >> media<br> >>>>>> player keys and digital rights management content = could also be added<br> >>>>>> as additional functionality.<br> >>>>>><br> >>>>>> Since keyword scanning and web filtering are extre= mely common<br> >>>>>> government interests, a dedicated daemon for this = function should be<br> >>>>>> created, with kernel hooks to allow inspection of = all internal 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<br> >> 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 t= o books on<br> >>>>>> LGBTQ[[:alnum:]]* topics or having non-white chara= cters, this module<br> >>>>>> should also automatically search the filesystem fo= r prohibited ebook<br> >>>>>> files.<br> >>>>>><br> >>>>>> Many packages will need to be altered to include s= pecific<br> >> functionality<br> >>>>>> relevant to censorship, including dpkg.=C2=A0 For = example, installing tor<br> >>>>>> will be prohibited in many countries, and some pac= kages, 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 user=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 encr= yption strength is<br> >>>>>> running, and set their maximum key length, disable= features, or send<br> >>>>>> private keys to a specified IP address determined = by the unit.<br> >>>>>><br> >>>>>> To prevent users from bypassing censorship require= ments, debian will<br> >>>>>> need to switch to being a binary-only distribution= with signed<br> >>>>>> binaries, signed kernel, and signed kernel modules= , with mandatory<br> >>>>>> secureboot, and controls to prevent any non-signed= software from being<br> >>>>>> installed, written, or compiled, as any foreign so= urces of software<br> >> may<br> >>>>>> fail to query systemd-censord or may fail to respe= ct the permissions<br> >> 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= distribution will be<br> >> allowed<br> >>>>>> to ship without systemd because then systemd-censo= rd may not work<br> >>>>>> correctly.=C2=A0 In addition, the licenses for all= packaged software will<br> >>>>>> need to be amended to disallow removal of censorsh= ip functionality.<br> >>>>>><br> >>>>>> As I=E2=80=99m sure is obvious, if debian is going= to comply with government<br> >>>>>> censorship regulations, a universal framework allo= wing easy addition<br> >> of<br> >>>>>> new rules will greatly reduce developer time over = individual ad-hoc<br> >>>>>> implementations of each new freedom restriction.= =C2=A0 Complying with only<br> >>>>>> one regulation, such as California=E2=80=99s attem= pts to prevent minors from<br> >>>>>> accessing unapproved information, makes no sense w= hen there=E2=80=99s hundreds<br> >>>>>> or thousands of other regulations not currently be= ing complied with.<br> >>>>>> This framework should ensure all users get to expe= rience their full<br> >>>>>> censorship regime no matter where they are in the = world.<br> >>>>>><br> >>>>>> Thanks for reading, and I hope we can work togethe= r 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 *ho= w* to decrypt<br> >> it, I<br> >>>>> have an idea for. It requires /etc/machine-id, AppArmo= r or SELinux,<br> >> FDE,<br> >>>>> and a new *specially* compiled kernel module. Feel fre= e to critique it<br> >>>>> and give me new ideas.<br> >>>>><br> >>>>> Starting off, /etc/machine-id is generated upon new in= stallations with<br> >>>>> systemd-firstboot, and it is unique to all systems. Th= is means it can<br> >> be<br> >>>>> used as a shared key along with a unique salt to preve= nt rainbow table<br> >>>>> attacks. This would be pretty bad for anyone to see pu= blicly, 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 here= on. Any system<br> >> that<br> >>>>> hasn't had it before is now an unsupported configu= ration. 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 bef= ore any MAC can<br> >> do<br> >>>>> anything to prevent it from being seen. Finally, the k= ernel module<br> >>>>> decrypts systemd-censord using the machine-id and salt= , runs it, and<br> >>>>> encrypts it again. For good measure, AppArmor or SELin= ux would hide<br> >>>>> systemd-censord and the kernel modules.<br> >>>>><br> >>>>> This is not fully concrete, but I believe this is a st= arting point. I<br> >> 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]" targe= t=3D"_blank" rel=3D"noreferrer">[email protected]</a><br> >>>>> Modify settings or unsubscribe at:<br> >>>> <a href=3D"https://lists.ubuntu.com/mailman/listinfo/ubunt= u-devel" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.ubun= tu.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= punishment<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 4= 5<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> "Rule 1.03 defines plaintiff as 'a person who commences an action&= #39;. The<br> New Shorter Oxford English Dictionary defines person as 'an individual<= br> human being'. [...] The entire basis of Mr. Joly's actions is that = he is<br> a martian, not a human being. [...] I conclude therefore, that Mr. Joly,<br= > on his pleading as drafted, has no status before the Court." =E2=80=94= Joly v<br> Pelletier, [1999] OJ No 1728, 1999 CarswellOnt 1587, at para 11<br> <br> </blockquote></div> --0000000000006d959e064d406ed7--