Process Tracking Portal

[BrainBlasted]

One gap for flatpak app types is process tracking.You cannot ship apps that are built around tracking ongoing processes as a flatpak. These apps include things like system monitors or certain terminals. Some example apps:

• System Monitor
• Usage
• King's Cross

If we had a portal for process tracking, these apps would be more viable as flatpak applications.

[GeorgesStavracas]

I must say, I'm not convinced about this. Listing processes is a host system action that requires access to resources that simply cannot be exposed to a sandbox. I think neither of the 3 examples listed here are suitable for Flatpak, they're host system modules.

[BrainBlasted]

How about another example: Discord or other chat applications that show a "Now Playing" status? Or an app that tracks app usage for health reasons?

[GeorgesStavracas]

"Now Playing" status could be derived from MPRIS, no?

[BrainBlasted]

No - Discord's "Now Playing" isn't about music, but rather games or other software. For example, someone using Blender would show as "Playing Blender" or "Playing $GAME_NAME".

[swick]

That on the other hand could probably be added to the GameMode portal without having to list all processes. Games register with the GameMode portal and apps which want to know which game is being played can query that from another part of the GameMode portal.

[Obsessee]

That would work for games but Discord users also use "Rich Presence" (Now Playing) for more than just games. Querying a GameMode ran process might be too restrictive. I wouldn't want to turn on GameMode to show my contacts I'm using Blender, VSCode, or listening to something on a media player with Rich Presence. Also as outlined by BrainBlasted, an application that tracks how much time you spent per app could be too restricted to be useful if this is handled with GameMode.

[GeorgesStavracas]

Still doesn't sound like a good idea for a portal. In general, asking for portals that just dump information like this is bad API. Portals API are semantic and purposeful. "List all process" is neither of that; it doesn't communicate intention, which is what portals are operate with. People usually come with this mindset of "X does this in order to achieve Y, and so we need a portal to do exactly X too", and this is not how portals are engineered. This is inverting the order of the whole process here. It's starting with "what files it wants to read" instead of "what it's trying to achieve". So, as is, I don't think a request to generically list random process is feasible, maintanable, nor interesting from the perspective of API design.

The real question is, what are the use cases involved. Usage and System Monitor are vastly different apps to King's Cross which is also vastly different from Discord. As I mentioned, I don't think Usage and System Monitor are suitable for sandboxing. I tend to think terminal emulators are not suitable either. Discord should be sandboxable, and we should probably provide enough information for it to implement its features, but things have to operate differently in a sandboxed world.

There is no meaningful way for sandboxed apps to acquire any contextual information about processes. No portal can work around this. For example, even if we add a portal that gives sandboxed apps a list of processes, the app would receive:

[ 2212, 2928, 3982, 4098, 4123, ... ]

With this list, if the app tries to read any information from, say, /proc/<pid>, it will fail as these files are not present inside the sandbox At this point, people will be divided in two camps: (i) the "expose all processes into the sandbox" camp; and (ii) pass relevant data through the portal itself.

Giving apps access to /proc is a massive sandbox hole, even in read-only mode. It's also probably meaningless to sandboxed apps, given the pid remapping and whatnot. Passing relevant data through the portal is also somewhat useless, since (1) there's no way to predict which information apps actually want, (2) at some point we end up with paths which require remapping and maybe even roundtripping through the documents portal, and (3) may overflow D-Bus with too much data. But more importantly...

Neither would work.

Even if we implemented such portal, regardless of the approach, Discord still wouldn't be able to implement Rich Presence. In order to implement such feature, Discord would need to know which window is focused, which is totally not available under /proc. Window titles are also not available under /proc. I don't know if Discord maps process names using a hardcoded list, but I don't even know if that would work if the other process is also running under a sandbox.

Therefore, a Process Tracking portal is a reject from my side.

Of course, this Rich Presence use case is still up in the air. To move this forward, you'll need to think what information needs to be provided by the host system so that apps with some form of rich presence can derive their strings from.

[Obsessee]

As someone uneducated about systems programming and APIs, that seems like a reasonable conclusion. It seems complicated to narrow down what information an app would be allowed to gather out of an entire process list. It wouldn't work either to only list all sandboxed apps, because that would likely limit the portal to Flatpak apps only - even if an alternatively sandboxed or even unsandboxed app requests the process list. #304 would probably address this use case in a similar vain, while only requesting GUI apps with window titles.

I think that implementing at least open window tracking would be very useful. Such as allowing digital well-being apps access to necessary information if a host system app doesn't suffice.

Discord still wouldn't be able to implement Rich Presence. In order to implement such feature, Discord would need to know which window is focused, which is totally not available under /proc.

Afaik Discord doesn't use window focus for Rich Presence.

[orowith2os]

For Discord Rich Presence (which actually uses UNIX sockets for communication, specifically $XDG_RUNTIME_DIR/discord-ipc-*) I think it could be handled by making a portal for applications to register their (self-provided) metadata with, and when allowed by the user, other applications can view the metadata going over that socket.

This would work for Discord to access the portal to register as an app using that metadata, which then makes the socket I listed before on the host (ideally, but not required), and flatpak applications to talk to Discord for Rich Presence.

I think this could be expanded a bit too to be useful to more applications than Discord, though at that point I think it's more appropriate to call it a "Rich Presence" portal rather than "Process Tracking" portal; I think it's appropriate for flatpak to block access to /proc for that too, the apps that need that might be better suited on the host system.

I hope I'm understanding and communicating everything correctly, if not, please correct me.

[ssokolow]

The problem is that, if you make a "rich presence" portal along those lines, it doesn't solve two problems:

1. Last I checked, you could configure Discord to report "Now Playing ..." for any application you want, rich presence-enabled or not. (eg. I see people "Now Playing" things like Visual Studio Code or Vim sometimes.)
2. Given the need for something in this vein for things like time-tracking tools (something I, as someone with executive dysfunction issues, see as an assistive technology for a symptom of a legally recognized mental disability which currently keeps me on X11), implementing this won't stop the requests for a "monitor active window title" portal. (And it has to be the title, so such tools can distinguish YouTube from Google Docs, work.xlsx from coin_collection.ods, and sales_letter.docx from great_american_novel_draft.odt without requiring every application to explicitly support it... though rich presence extensions could be useful for enhancing such tooling if they were designed in a way where you could separately select the level of detail granted to each MxN combination of information producer and information consumer so page title access could be granted to a time-tracker but not to Discord while Discord could still receive rich info from games.)

In other words, sure... you could implement such a thing, but you'll still have calls to produce another portal with a lot of functional overlap. (And it has to be a portal because it's the most natural place to implement such functionality in a cross-DE portable way while still keeping the user in control of their privacy and security decisions in the Wayland era.)

[orowith2os]

Taking a different stance now, on process tracking... Rather than reading PIDs, what if the DE hooked into a portal for exchanging info about applications on the host like you want? This way it wouldn't read PIDs, but the DE would just track the appropriate applications (which is done via .desktop files afaik).

Depending on how many options this portal would have, it could track application titles similar to history for your shell.

I think I'll make a separate issue for a "Rich Presence" portal, as an enhancement to this portal, if this is accepted for how it could be done.

[ssokolow]

As someone who likes to make and run applications without actually installing them (eg. development via cd ~/src/my_pyqt_project; poetry run python3 ./whatever.py or cd ~/src/my_rust_project; cargo run), that "which is done via .desktop files afaik" makes me very wary.

I'm already effectively locked out of using the Canonical-designed taskbar button progress API that Plasma implemented because it indirects itself through .desktop files (the D-Bus API requires you to specify a .desktop file name and then Plasma looks it up among the installed applications).

...plus, people using Appimages wouldn't like being told that appimaged is now mandatory to access certain system functionality of greater consequence than just a taskbar progress display only implemented by a subset of taskbar/panel hosts. They're pretty big on that word "optional" and Appimages being fully functional when downloaded, chmod +x-ed, and double-clicked without needing any special package management infrastructure.

It's right in their sales pitch on the site:

Download an application, make it executable, and run! No need to install. No system libraries or system preferences are altered.

[GeorgesStavracas]

This might be a related use case: https://gitlab.gnome.org/World/boatswain/-/issues/64

[Obsessee]

This MR on the flatpak repo might seem of interest.