> People tend to distrust websites. URLs are also an immutable ledger that guarantees you’re in the right spot.

Typosquatting would like to have a word with you.

I assumed Nintendo of America was top.

> Said differently: I don't want to configure the portal, I want to ~~break~~ mask it.

Since this is sd-userdbd we are talking about unless the used backend provides the value it is unset by default. And if you manage your home directory using sd-homed unless you explicitly set it it is also unset by default.

I am aware, I kind of want a louder signal than doing nothing [which is a great option, I admit]. I quote myself:

> It's entirely optional, I get that. I could 'just' not set anything.

Why? Telemetry, mainly. I'd rather attestation [or whatever intends to use this] fail and make it apparently deliberate.

Well, to get something to fail you need an implementation that can fail. And since nothing is using this so far there is nothing you can get to fail. In the end something that implements the actual communication would end up probably defaulting to "under 13" or whatever if it somehow fails to retrieve any value (or maybe not, who knows), so I wouldn't realistically see even without this, getting the attestation to "break" would end up unlikely.

Hypotheticals are truly exhausting! I had a wall of text and chopped most of it off. This started out as a joke and now it's dead, thanks.

The failure/assumption of under-13 or whatever, as a result of manipulation, is fine. I'm not actually trying to solution something though, jeez.

I find it more compelling to say, for instance, "x% of our users have chosen not to share their information"... rather than "y% have not set it". This category would almost surely be about as 'useful' (useless) as the 'do not track' header... and a concern for something other than systemd or even the portal (to a degree).

I think the loudest way you can protest is to use and support distros that do not have systemd. There are lots to choose from in 2026.

Probably never for package based distros. I could see it happening for image based distros, where systemd is slowly but surely providing all the building blocks for. It has had the option for `NoNewPrivileges=` in the `system.conf` since v239, so it isn't exactly difficult to disable for the entire system.

Though you'd be surprised how many binaries are suid binaries while they probably shouldn't be (passwd, mount, groupmems, ...), though alot can also work without being suid just more resticted in what they can do.

With https://github.com/thkukuk/account-utils (not the default yet), it's meanwhile possible to run openSUSE Tumbleweed (package based) with NoNewPrivileges= as usual.

> how many binaries are suid binaries while they probably shouldn't be (passwd

I would expect an unprivileged user to be able to change their own password. How else would that work?

Send a message to a socket-activated daemon running as a UID with write access to the password database.

Isn't the issue in this case caused not by suid, but by a daemon running as root reading files from a tmp dir? Seems like a socket-activated daemon wouldn't solve this specific case.

> How else would that work?

Windows way is to have a privileged service which the non-privileged user application talks to over sockets or similar.

systemd-homed stores most of the user specific information in the home directory `~/.identity`, but since the file contents have to be signed the changes need to be done though a daemon, which is talked to via IPC (homectl does the talking to systemd-homed).

> Linux does have something similar with $XDG_RUNTIME_DIR (generally /run/user/$UID/), but it's stored in memory only

On a lot (at this point I assume most) of systems /tmp is also just a tmpfs, so it also is just in memory. /var/tmp usually is storage backed though.

Recently systemd also added something similar for userspace (more specifically the desktop environment) to hook into: https://mastodon.social/@pid_eins/113441330932924520

> Torvalds has made it very clear, on several occasions, that breaking userspace is not acceptable.

Breakages to userspace happen somewhat regularly from what I get, but its more of a case of "If the tree falls in the forest and nobody complains it didn't happen". Though its more that one should at least make sure in some form or fashion that it won't at least affect anyone.

The thing is: they mostly do implement xdg-desktop-portal's screenshot API since that does also handle permission management.

In effect the modern desktop is wayland (window communication), pipewire (audio/video), and xdg-desktop-portal (compositor/environment requests) which all kinda have to be worked with for a desktop application.

I am p sure a lot of those that aren't for it aren't for it because of access to said ID is gated behind money (or unreasonably out of the way), which would need to be fixed first.

Without an ID, there's far more than just voting that they're not able to take advantage of. Yet I never hear of anyone having trouble living in this modern world that requires an ID for just about everything.

The earlierst I know of coming is the SpaceMit K3, which Sipeed will have dev boards for.