Portal-Based Age Signals

Layer 1: Data Storage — systemd userdb

Merged

systemd PR #40954 added a birthDate field (YYYY-MM-DD) to JSON user records managed by systemd-userdbd. The field stores the user's full date of birth — not a bracket, not a year, an exact date. It is set via homectl for systemd-homed users or via drop-in records in /etc/userdb/.

The field is readable by any process that can query userdb. Only administrators can write it. Lennart Poettering (systemd maintainer) argued that sandboxing — not field-level access control — should handle data exposure.

The PR explicitly cites AB 1043, CO SB 26-051, and Brazil Lei 15.211 as motivation. It coordinates with AccountsService MR #176 and xdg-desktop-portal PR #1922.

Ageless Linux response: become-ageless.sh already neutralizes this field. Regular mode sets all users to 1970-01-01. Flagrant mode sets it to null. The --persistent flag installs agelessd, a systemd timer that re-neutralizes every 24 hours.

Layer 2: Application API — xdg-desktop-portal

Open PR

PR #1922 adds an age range portal. Applications submit age thresholds (e.g., [9, 13, 16]) and receive a response indicating which range the user occupies (e.g., [13, 16] for a 14-year-old). The portal backend reads from the data layer (systemd userdb, AccountsService, or a distro-specific store) and returns only the applicable range — not the exact date.

Applications require a static manifest permission to call the portal. Rate limiting is discussed to prevent bisection attacks (querying with progressively narrower gates to determine exact age).

Layer 3: Desktop Integration

Future

Desktop environments (GNOME, KDE, etc.) would implement the portal backend and provide UI for entering birth date data during account setup. The portal spec defines the API; each desktop implements its own backend. GNOME might read from AccountsService; KDE might read from systemd userdb directly.

How It Works

An application provides an array of age thresholds. The portal returns the lower and upper bounds of the range the user falls within:

Application sends:  gates = [9, 13, 16]

User is 12:   response = [9, 13]    (older than 9, younger than 13)
User is 17:   response = [16, -1]   (older than 16, no upper bound)
User is 8:    response = [-1, 9]    (younger than 9, no lower bound)

The design is intentionally coarser than returning an exact age. The application learns only which bracket the user occupies relative to thresholds the application itself chose. Different applications can submit different gate arrays — a social media app might use [13, 16, 18] while a gambling app uses [18, 21].

Existing Infrastructure

xdg-desktop-portal already handles permission-gated access to system data for sandboxed applications — file access, screen sharing, notifications, and other controlled operations. Age data fits naturally into this model as another piece of permission-gated user information.

Sandboxing Integration

Flatpak and Snap applications communicate with the host system through portals. A portal-based age interface integrates with existing sandboxing rather than requiring apps to additionally reach a separate D-Bus service.

Backend Flexibility

The portal spec separates the API (what apps see) from the backend (what the desktop implements). Different desktops can read age data from different sources — systemd userdb, AccountsService, a flat file — without changing the application-facing interface.

Preliminary Approaches

If the portal is accepted and desktop environments begin shipping backends, potential short-circuit strategies include:

These are preliminary. We will finalize our approach when the portal specification and at least one desktop backend are concrete enough to test against.