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

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 PM 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-authenticator-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, “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
>>>
>>> --
>>> 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." — R v.
Nur, 2015 SCC 15, [2015] 1 S.C.R. 773, per McLachlin CJ, at para 45