Re: On the need for a censorship API for legal compliance reasons in some countries and U.S. states

4 Mar 2026 05:12:31 FloofyWolf <[email protected]>:

> Recently, a proposal has been made to implement an API for a new=20
> California censorship regulation, =E2=80=9COn the unfortunate need for an=
 "age=20
> verification" API for legal compliance reasons in some U.S. states=E2=80=
=9D by=20
> Aaron Rainbolt.=C2=A0 I believe the approach outlined to be very=20
> short-sighted, in that creating a bespoke API for each of the hundreds=20
> of government censorship requirements that debian will presumably now=20
> be following will result in much duplication of effort and an=20
> unreliable user experience in which important censorship restrictions=20
> may be missed and not implemented.=C2=A0 As such, with people now support=
ing=20
> the idea that debian should implement government censorship requests,=20
> even creating new standards if needed, I propose the creation of a=20
> censorship framework to speed implementation of current and future=20
> censorship regulations.
>
> On installation, the user will be required to enter their location.=20
> This information may be pre-filled if device location (GPS) or other=20
> sources of location data (IP geolocation, selected timezone, etc) are=20
> available.=C2=A0 If the user enters a location that does not match any=20
> gathered location data, this will be immediately stored and sent to=20
> authorities in both the detected location and the entered location to=20
> alert them of a citizen potentially trying to evade censorship=20
> regulations.=C2=A0 If the location entered requires further information,=
=20
> such as whether an encryption license has been acquired, the user=E2=80=
=99s=20
> age, etc, it will be requested at this point.=C2=A0 This process will als=
o=20
> be repeated every time a user account is created, and will require=20
> implementation in both graphic and text-based account management=20
> utilities, such as adduser.
>
> This location and user data will be managed by a new daemon,=20
> systemd-censord, and stored in an encrypted form and otherwise=20
> protected so as not to be readable or modifiable by any user on the=20
> system.=C2=A0 To ensure privacy, great care must be taken to prevent a us=
er=20
> from being able to access other users=E2=80=99 personal information, and =
to=20
> ensure compliance with censorship regulations, no user may be able to=20
> change their location in any fashion which bypasses dedicated=20
> utilities, which will perform the required location validation and=20
> discrepancy authority notice functions when the user requests to change=
=20
> their location, such as for moving house or travel.
>
> Systemd units will be created for every desired censorship function,=20
> and will be started based on the user=E2=80=99s location.=C2=A0 For examp=
le, a unit=20
> for Kazakhstan will implement the government-required backdoor, a unit=20
> for China will implement keyword scans and web access blocks (more on=20
> this later), a unit for Florida will ban all packages with =E2=80=9Ctrans=
=E2=80=9D in=20
> the name (201 packages in current stable distribution), a unit for=20
> Oklahoma will ensure all educational software is compliant with the=20
> Christian Holy Bible, a unit for the entire United States will prevent=20
> installation of any program capable of decoding DVD or BluRay media,=20
> and a unit for California will provide the user=E2=80=99s age to all=20
> applications and all web sites from which applications may be=20
> downloaded.=C2=A0 As can be seen, multiple units may be started for a giv=
en=20
> location.
>
> All communication will be over D-Bus, with each application proactively=
=20
> asking systemd-censord for permission to perform any operations which=20
> may foreseeably be restricted anywhere in the world.=C2=A0 A standardized=
=20
> list of permissions will need to be developed, as well as standard=20
> personal data fields, such as user age.=C2=A0 Blobs for the storage of me=
dia=20
> player keys and digital rights management content could also be added=20
> as additional functionality.
>
> Since keyword scanning and web filtering are extremely common=20
> government interests, a dedicated daemon for this function should be=20
> created, with kernel hooks to allow inspection of all internal program=20
> structures as well as internet traffic.=C2=A0 This daemon can then be=20
> started with different filter configuration files for each systemd unit=
=20
> triggered by the user=E2=80=99s location.=C2=A0 To comply with book bans =
common in=20
> many US states, such as those restricting access to books on=20
> LGBTQ[[:alnum:]]* topics or having non-white characters, this module=20
> should also automatically search the filesystem for prohibited ebook=20
> files.
>
> Many packages will need to be altered to include specific functionality=
=20
> relevant to censorship, including dpkg.=C2=A0 For example, installing tor=
=20
> will be prohibited in many countries, and some packages, like=20
> fortunes-off, will be restricted based on the user=E2=80=99s age, as will=
 most=20
> games.=C2=A0 Web browsers will have to be patched to send the user=E2=80=
=99s age to=20
> all websites hosting applications for download.=C2=A0 Encryption packages=
=20
> will have to check if a systemd unit limiting encryption strength is=20
> running, and set their maximum key length, disable features, or send=20
> private keys to a specified IP address determined by the unit.
>
> To prevent users from bypassing censorship requirements, debian will=20
> need to switch to being a binary-only distribution with signed=20
> binaries, signed kernel, and signed kernel modules, with mandatory=20
> secureboot, and controls to prevent any non-signed software from being=20
> installed, written, or compiled, as any foreign sources of software may=
=20
> fail to query systemd-censord or may fail to respect the permissions it=
=20
> returns.
>
> On the non-software side, the debian licenses will need to be modified=20
> to disallow removal or alteration of any of these features by=20
> derivative distributions =E2=80=93 for example, no distribution will be a=
llowed=20
> to ship without systemd because then systemd-censord may not work=20
> correctly.=C2=A0 In addition, the licenses for all packaged software will=
=20
> 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 governm=
ent=20
> censorship regulations, a universal framework allowing easy addition of=
=20
> new rules will greatly reduce developer time over individual ad-hoc=20
> implementations of each new freedom restriction.=C2=A0 Complying with onl=
y=20
> one regulation, such as California=E2=80=99s attempts to prevent minors f=
rom=20
> accessing unapproved information, makes no sense when there=E2=80=99s hun=
dreds=20
> or thousands of other regulations not currently being complied with.=20
> This framework should ensure all users get to experience their full=20
> censorship regime no matter where they are in the world.
>
> Thanks for reading, and I hope we can work together to help Linux=20
> implement as much censorship as possible!
> --Floofy Wolf

Nice work!

I would agree with encrypting systemd-censord, but *how* to decrypt it, I=
=20
have an idea for. It requires /etc/machine-id, AppArmor or SELinux, FDE,=20
and a new *specially* compiled kernel module. Feel free to critique it=20
and give me new ideas.

Starting off, /etc/machine-id is generated upon new installations with=20
systemd-firstboot, and it is unique to all systems. This means it can be=20
used as a shared key along with a unique salt to prevent rainbow table=20
attacks. This would be pretty bad for anyone to see publicly, so now we=20
have to come up with a solution.

My solution to this is FDE with TPM2, a kernel module, and an MAC.=20
Firstly, all systems must have FDE with TPM2 from hereon. Any system that=
=20
hasn't had it before is now an unsupported configuration. Secondly, the=20
new kernel module is included in the initramfs so that it can start=20
reading /etc/machine-id after root is mounted, but before any MAC can do=20
anything to prevent it from being seen. Finally, the kernel module=20
decrypts systemd-censord using the machine-id and salt, runs it, and=20
encrypts it again. For good measure, AppArmor or SELinux would hide=20
systemd-censord and the kernel modules.

This is not fully concrete, but I believe this is a starting point. I am=20
fully open to other ideas.

Cheers,

--=20
Artur Manuel
amadaluzia