An alternative approach suggested by KDE developer David Edmundson: route age data through xdg-desktop-portal, the existing permission-gated framework used by Flatpak and Snap applications.
Edmundson raised this as the preferred approach on the debian-devel thread (March 1, 2026). It was not developed into a formal spec and was rejected by the original D-Bus proposal's author.
David Edmundson argued on the debian-devel mailing list that age reporting should go through xdg-desktop-portal rather than a standalone D-Bus service. His rationale:
xdg-desktop-portal already solves the problem of giving sandboxed applications controlled access to system data. It handles file access, screen sharing, notifications, and other permission-gated operations. Age data is, functionally, another piece of permission-gated user information — it fits the portal model.
Flatpak and Snap applications already communicate with the host system through portals. A portal-based age interface would integrate naturally with the existing sandboxing model, rather than requiring sandboxed apps to additionally reach a separate D-Bus service.
Aaron Rainbolt (the D-Bus proposal's author) pushed back on the portal approach:
xdg-desktop-portal exposes more data than the law requires. Adding age data to the portal framework means sandboxed applications that already have portal access could query age information without explicit, separate user consent. The portal model groups permissions loosely — an app granted access to one portal capability could potentially access others.
A standalone D-Bus interface is more minimal: it does exactly one thing and nothing else. There's no ambient access from other portal permissions.
"Operating systems have a trillion other bits of information available." — David Edmundson, debian-devel, March 2026
Edmundson dismissed the data minimization concerns as "overblown." His argument: the operating system already exposes enormous amounts of user data — locale, timezone, display resolution, installed fonts, hardware identifiers. Adding age bracket to the portal's data set is a marginal increase in exposure on a system that already provides far more identifying information than an age bracket.
This is a reasonable technical argument. It is also, from the Ageless Linux perspective, an argument for why the entire portal framework is a removal target — not just the age interface.
If a distribution ships age reporting through xdg-desktop-portal:
Age data would be accessible through the portal API, likely at
org.freedesktop.portal.AgeVerification or a similar name under the portal
namespace. The portal backend would communicate with whatever system service stores the
actual age data.
Flatpak apps would gain access via the --talk-name permission or a dedicated
portal permission. The Flatpak manifest would need to declare this access, and the portal
could (in theory) prompt the user before sharing age data with each application.
Snap applications access portals through their confinement interfaces. A new
desktop-portal-age interface (or similar) would need to be defined in snapd.
Portal integration presents a broader attack surface than a standalone daemon. The portal framework is deeply integrated into the desktop — removing or modifying a single portal interface requires careful handling to avoid breaking unrelated portal functionality.
If a distribution ships age reporting through xdg-desktop-portal, Ageless Linux will provide portal configuration that blocks the age interface specifically while leaving other portal services intact. This likely involves modifying the portal backend configuration or replacing the age verification portal backend with a stub that returns empty data.
See the Short-Circuit section for our approach to stub services.