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, “On the unfortunate need for an "age
verification" API for legal compliance reasons in some U.S. states” 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 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’s
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 user
from being able to access other users’ 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 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’s location. For example, 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 “trans” 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 prevent
installation of any program capable of decoding DVD or BluRay media,
and a unit for California will provide the user’s 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 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 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 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’s 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’s age, as will most
games. Web browsers will have to be patched to send the user’s 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 being
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 modified
to disallow removal or alteration of any of these features by
derivative distributions – 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’m sure is obvious, if debian is going to comply with government
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’s attempts to prevent minors from
accessing unapproved information, makes no sense when there’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 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 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 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, 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 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
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
