On Sun, 8 Mar 2026 at 20:45, Alex North-Keys <[email protected]> wrote:
> > Sadly, most of this is unwise with respect to a mandate controlled by > politicians instead of developers. > > * This abomination absolutely should NOT be integrated into any existing > service, since that makes it both harder to disable and harder to update > when the laws are patchwork-wise changed and likely made worse. > > * Putting it in a separate (cursed) system daemon, ideally written in a > popular interpreted language instead of a compiled one, eases the > process of both centralized and per-site development of the service for > logging and other reasons. > > * The separate package for this (cursed) system daemon also makes > it trivial to remove in places that have not been caught up in this > type of legislation. > > * Given the high likelihood that an authoritarian administration will > expand the "age signal" to be an opaque data chunk, one per user, > obtained from the government through a website or some other mechanism > ... it would be unwise to place any built-in limits on the potentially > opaque payload in terms of ASCII limitations or size. > > Before anyone protests that these "age signals" are Good, pay attention > to the fact that these create a NEW MECHANISM through which your > computer (or other devices) expose information about you (and children) > to anyone, including hostile actors that queries for, currently, an "age > signal". > > The safest child on the Internet is an anonymous child, not one who's been > put forward as a victim for targeted advertising or worse. Not one who's > had that young age combined with a physical address through dataset > accumulation and sales between data vendors on the Internet. > > Don't even get me started on how incredibly vague, expansive, and > ambiguous these laws and bills are. By their failure to define basic > terms, it's impossible to tell if the bills apply to nearly every computer > (that down download anything) or to none (the exemption for use of > a physical device). > > My opinion is that the extreme lack of care in making these somehow > both brief yet profoundly vague laws clear exposes the real purpose: > creating a new mechanism, that can be subverted by authoritarian > actors. > > So I recommend any implementation be fully segregated from all other > services, the easier to be monitored, removed, etc, as the case might > demand. > > -- > Alex. North-Keys, Talisman.Org, Spatial Environments Research > url "http://www.talisman.org/~erlkonig/"; > voice 512.249.7121, cell 512.404.3344, pager url + "contact/" > This should not be treated as an implementation discussion. The most serious mistake in this thread is not a particular choice of daemon, D-Bus interface, storage format, or packaging strategy. The mistake is accepting the premise that Debian should be discussing how to build an OS-level surveillance and control apparatus, an authoritarian surveillance mechanism disguised as “age verification” or “age signaling”, into a general-purpose free operating system at all. It should not. What is being proposed here is not a normal compliance feature, and it is not redeemed by describing it as “minimal”, “limited”, “just an age bracket”, or “good faith”. It is an attempt to insert a standardized user-classification and disclosure mechanism into the operating system layer for third-party applications and services, under legal pressure and under an emotional pretext. That has no place in Debian. The “age bracket only” framing does not solve the real problem. An OS-level age signal is still an OS-level identity attribute. Once exposed through a standard API, it becomes a fingerprinting primitive, a gating mechanism, and a compliance wedge for future expansion. The issue is not merely how many bits are disclosed. The issue is that the operating system is being pushed into the role of a policy-enforcement endpoint. That should be rejected outright. Aaron’s proposal is presented as a practical response to legal pressure. Alex’s reply is presented as a containment strategy that would make the mechanism easier to remove, patch, monitor, and adapt if the law worsens. I understand the reasoning in both cases. But both approaches remain inside the same mistaken frame. They are still discussing how Debian and the wider free software ecosystem should design the plumbing for something that does not belong here in the first place. That is the trap. Once the discussion shifts from “should this exist at all?” to “where should it live?” or “how should it be packaged?”, too much has already been conceded. At that point, Debian is no longer defending its boundary. It is helping translate coercive law into technical architecture. Debian should not do that. This is also not an isolated issue. We are seeing the same broader pattern elsewhere, including in the “Chat Control” debate in Europe and in other pushes for device-side inspection and "lawful-access" mechanisms. Child-safety rhetoric is invoked, urgency is manufactured, emotional pressure is applied, and then technical or civil-liberties objections are treated as though they were morally suspect. That is not sound policy-making. It is coercive framing. It is moral blackmail used to launder surveillance mechanisms into ordinary infrastructure. No. Protecting children is a serious obligation. But that obligation does not justify turning a general-purpose operating system into an authoritarian surveillance and classification layer. It does not justify building what is, in substance, a surveillance mechanism into the platform under softer terminology. It does not justify asking Debian to help construct the technical substrate for categorizing, filtering, and controlling users. A general-purpose free operating system must not be turned into a state-aligned surveillance or policy-enforcement apparatus. So, to be explicit, Debian should reject this entire category of functionality. Not in AccountsService. Not in xdg-desktop-portal. Not in a standalone daemon. Not in a removable package. Not as a minimal age bracket. Not as a future opaque token. Not as a jurisdiction-specific compromise. Not as a temporary measure. Not in any form. No implementation path is acceptable here. Making such a mechanism modular, removable, or easier to patch does not make it acceptable. It only changes how the wrong thing is packaged. The first concrete implementation step in this direction would already be a red line crossed. The first interface, the first package, the first standardization effort, the first integration point, the first line of code intended to support OS-level age signaling would already be too much. And I want to be clear about what that means for me personally. If Debian or Ubuntu crosses that line and begins implementing any of this, I will treat that as a matter of principle, protest, and basic decency. I would support, build, or help lead a fork with that functionality removed. That is not a threat or an ultimatum. It is simply the consequence of refusing to collaborate in building this kind of apparatus. But Debian should not force that point to be tested. Debian should refuse now, before one line is written. Refusal must also not take the form of geo-fencing human beings out of free software. Debian must remain accessible to everyone on this planet. A free operating system should not be turned into a territorially fragmented compliance product, and users should not be abandoned because of where they live. Neither implementation nor geo-fencing is acceptable. Debian should say, clearly, that it will not standardize, ship, modularize, package, or otherwise facilitate OS-level age verification, age signaling, or related APIs. Not now. Not later. Not under softer terminology. Not because politicians used vague and reckless language. Not because the pressure was dressed up as urgency. Not because a “good faith effort” clause tries to recruit technical communities into implementing what they should reject on principle. No law is above morality or scrutiny. Debian is under no moral obligation to help construct infrastructure for surveillance, classification, filtering, and control at the operating-system level. Debian should refuse this absolutely.
