Most of these are covered. We don’t need to worry about org.gnome.ControlCenter for this (that’s just for some error handling around the XDG Background portal), but the application does need to talk with org.gnome.Mutter.IdleMonitor. That’s an interface provided by Mutter that allows an application to see the session’s current idle time. It doesn’t look like there’s an existing snap interface I can use to talk with that dbus interface, and judging by the docs it looks like I should ask about that here, so here I am
Here’s the complete error message when the application tries to use the idle monitor interface:
** (gnome-break-timer-daemon:52189): WARNING **: 16:02:10.090: MutterActivityMonitorBackend.vala:78: Error adding mutter idle watch: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.138" (uid=1000 pid=52189 comm="gnome-break-timer-daemon " label="snap.gnome-break-timer.daemon (enforce)") interface="org.gnome.Mutter.IdleMonitor" member="AddIdleWatch" error name="(unset)" requested_reply="0" destination="org.gnome.Mutter.IdleMonitor" (uid=1000 pid=42370 comm="/usr/bin/gnome-shell " label="unconfined")
Note that org.gnome.Mutter.IdleMonitor is one of many dbus names owned by GNOME Shell, so there are several other dbus objects related to it. Probably makes sense to be fine-grained with what this snap interface relates to, as I assume we’re doing with the screen-inhibit-control interface.
Maybe it would be worth trying to get a safe interface for this included in xdg-desktop-portal? It seems like the kind of thing that could fit as an extension of the existing org.freedesktop.portal.Inhibit.CreateMonitor method call, which delivers signals on session state changes. At the moment, it covers session close and screensaver activate/deactivate. Adding idle notification might fit in as another type of activity to monitor.
Some thought would need to be taken to ensure it doesn’t provide too fine grained information that could be used as a side channel.
Heh, that’s a charming feature :b Kudos for being on the look-out for these kinds of things! Incidentally, do you know if there is a bug report for that? (It’s concerning since there are dozens of apps on Flathub talking to GNOME Shell-attached dbus names). When you put it that way, it definitely makes sense to put that interface in a portal. I was wanting a less oddly specific name to talk to anyway.
The Flatpak --talk-name directives in the first post in the thread would grant access to all of the shell APIs. Even if it was just --talk-name=org.gnome.Mutter.IdleMonitor, this would be the case because gnome-shell exports everything over a single D-Bus connection.
I’m still of the opinion that it’d be better to address this through an xdg-desktop-portal API. Most of the gnome-shell APIs haven’t been written with untrusted clients in mind, and a portal interface has the possibility of supporting non-GNOME desktops.