Centralized Tray Notifications

[marmarek]

Reported by joanna on 18 Aug 2014 14:59 UTC
A simple qubes.TrayNotification service in Dom0/GUI domain that would be trigerable by agents in each VM (which would register as default tray notifcator). The protocol should be trivial -- just a fixed-size string, sanitized by the server in the usual way (same as we do for Windows titles, etc).

Migrated-From: https://wiki.qubes-os.org/ticket/889

Historical information about contributors

Community Dev: @v6ak, @nastaziya, @fepitre
Partial PoC: https://groups.google.com/d/msg/qubes-devel/1Lzv9SQCzFc/4gKx06iKRD4J
Discussion: https://groups.google.com/d/topic/qubes-devel/1Lzv9SQCzFc/discussion

[marmarek]

Related discussion: https://groups.google.com/forum/#!searchin/qubes-devel/libnotify/qubes-devel/1Lzv9SQCzFc/2Jk5bPzF9tcJ

[adrelanos]

Milestone justification:
This feature is important for Whonix usability. (See #1267.)

[adrelanos]

Likely a follow up issue:
One passive popup blocks another one. Example:
kdialog --passivepopup test1 ; kdialog --passivepopup test2
I.e. as long as the user does not click the first passive popup to make it go away, the second one will not be shown. So by not clicking the first one, the second passive popup will be lost unseen. A usability issue.
I am saying this, because until this ticket is implemented, I cannot implement what we planned for Whonix. (Which is "No more Tor bootstrap progress bar. + "Tor bootstrap in progress." passive poupup + "Tor bootstrap done." passive popup.) @bnvk @mfc

[marmarek]

On Thu, Oct 08, 2015 at 08:22:34AM -0700, Patrick Schleizer wrote:

Likely a follow up issue:

I think this one is orthogonal to the ticket main topic. See below.

One passive popup blocks another one. Example:
kdialog --passivepopup test1 ; kdialog --passivepopup test2
I.e. as long as the user does not click the first passive popup to make it go away, the second one will not be shown. So by not clicking the first one, the second passive popup will be lost unseen. A usability issue.

So... use something that doesn't have this behaviour. kdialog --passivepopup is some KDE specific mechanism, not using any standard
API (especially not freedesktop notification protocol). So even if we
implement "Centralized Tray Notifications", this wont affect kdialog
behaviour. Try notify-send.

Note that some notification daemons have some limits on simultaneous
notifications (like gnome-notification-daemon - 21, currently we use
mate-notification-daemon, which AFAIR have much larger limit). What
happens with additional notifications is implementation specific, but in
most cases are lost, not queued.

One additional thing - maybe useful here - freedesktop notification
protocol supports retracting notifications (independent of setting some
timeout). So if one message, like "Connecting..." is no longer relevant,
it can be retracted (CloseNotification dbus method) and/or replaced
(another Notify with replaces_id set) with another one.
AFAIR not all implementations support this feature. Also not sure if our
"Centralized Tray Notifications" will pass such messages.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

• kdialog looks nice in plain Debian jessie. Nicely integrated into systray. Looks weird in Qubes. Not sure that's worth an issue.
• Posted a related issue, notify-send parameter --expire-time broken in Qubes (notify-send parameter --expire-time broken in Qubes #1297).
• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

[marmarek]

On Thu, Oct 08, 2015 at 10:44:05AM -0700, Patrick Schleizer wrote:

• Looks like notify-send will do for Qubes-Whonix until this ticket gets implemented. Thanks you, Marek!

Not "until" - something needs to sent those notifications either to some
notification daemon, or to our "Centralized Tray Notifications".
kdialog apparently doesn't do that, notify-send (or other tools like
this) does.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

BTW check if notify-send would also work on plain debian - AFAIR KDE
notification service also listens on that standard protocol.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

[adrelanos]

One additional thing - maybe useful here - freedesktop notification protocol supports retracting notifications (independent of setting some timeout). So if one message, like "Connecting..." is no longer relevant, it can be retracted (CloseNotification dbus method) and/or replaced (another Notify with replaces_id set) with another one. AFAIR not all implementations support this feature. Also not sure if our "Centralized Tray Notifications" will pass such messages.

Yes. Very useful. I would very much like to implement this. But I can't.
notify-send(1) can't replace an existing notification:
https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135

[marmarek]

On Thu, Oct 08, 2015 at 10:51:47AM -0700, Patrick Schleizer wrote:

BTW check if notify-send would also work on plain debian - AFAIR KDE notification service also listens on that standard protocol.

notify-send works on Debian jessie KDE, but it looks weird.

Hmm, just checked and here (Qubes dom0 with KDE) it looks exactly like
the other KDE notifications. For that to work, "Notifications" widget
needs to be added to panel. Anyway probably not worth further
investigation.

Not "until" - something needs to sent those notifications either to some notification daemon, or to our "Centralized Tray Notifications". kdialog apparently doesn't do that, notify-send (or other tools like this) does.

Not sure I understand. So once "Centralized Tray Notifications" is implemented, you'll be providing a tool that Whonix should start using? In that case, easy from Whonix side.

We plan to implement it transparently to the VM applications. It will
look like any other notification daemon, so for example notify-send (and
any other application using standard API) would just work.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Just doing a routine check: Is it still correct that @rootkovska is assigned to this issue?

[marmarek]

No.

[marmarek]

Also, there is a PoC written by @v6ak, linked and described in that qubes-devel thread

[andrewdavidwong]

Thanks. Updated.

[ninavizz]

For ActionInvoked the app might not be informed that the user clicked somewhere on the notification. Buttons are uncommon in notifications and I've never seen any, so I dismiss that impact.

Interesting! I know that on mobile, buttons on notifications (such as “reply to message”) are extremely common, so I was surprised that they are rare on desktop.

My desktop GMail notifications, I believe include a "Reply" button. Likewise, I've seen buttons included in updater messages. The option to "Bug me later" vs to outright "Dismiss" an update notification, also feels very important for an OS like Qubes.

Buttons imply richer interactivity options that most of Qubes OS currently has. Qubes is special because of the many things it simply makes possible short of running a dozen physically-airgapped devices, at once. For "notifications" that do include buttons, I see the Qubes "Question" window as basically fulfilling that goal—but with the workaround of being a small dialog box.

I'd much prefer those eventually become notification bubbles spawned by dedicated widgets for Split-GPG and Inter-Qube activities. I'll put that on my list for "Things Nina Wants When Millions Of Dollars Fall From The Sky."

[unman]

On Fri, Jul 09, 2021 at 02:55:22PM -0700, Nina Eleanor Alter wrote: > > For `ActionInvoked` the app might not be informed that the user clicked somewhere on the notification. Buttons are uncommon in notifications and I've never seen any, so I dismiss that impact. > > Interesting! I know that on mobile, buttons on notifications (such as ???reply to message???) are _extremely_ common, so I was surprised that they are rare on desktop. My desktop GMail notifications, I believe include a "Reply" button. Likewise, I've seen buttons included in updater messages. The option to "Bug me later" vs to outright "Dismiss" an update notification, also feels very important for an OS like Qubes. Buttons imply richer interactivity options that most of Qubes OS currently has. Qubes is special because of the many things it simply _makes possible_ short of running a dozen physically-airgapped devices, at once. For "notifications" that do include buttons, I see the Qubes "Question" window as basically fulfilling that goal???but with the workaround of being a small dialog box. I'd much prefer those eventually become notification bubbles spawned by dedicated widgets for Split-GPG and Inter-Qube activities. I'll put that on my list for "Things Nina Wants When Millions Of Dollars Fall From The Sky."

NM notifications have a "Don't tell me about this again" option. I would like to see similar on the "qube starting" and "qube shutting down" notifications, or a mechanism to mute them. The dialog box not only asks the question, but also provides interaction (in selecting a target qube) - I don't see how a bubble could provide that, and users are likely used to such dialog boxes in any case.

[3hhh]

Most of the aforementioned examples ("Bug Me later", "Dismiss", "Don't show this again", ...) are matters of the notification server implementation in the target VM (aka the fancy stuff with potentially 1k bugs I mentioned earlier). A good overview can be found at the arch wiki.

Only this "Reply to e-mail" button would require a working ActionInvoked implementation, i.e. a backchannel. If that's really required, I'd suggest to set ask or deny as RPC default to avoid a bidirectional default communication channel between all VMs and their notification server VM. One could still change it for dedicated VMs.

Alternatively, one could just handle such notifications via the locally running notification server, i.e. fall back to the decentralized architecture for those.

[3hhh]

After looking into dbus details a bit, I think it would be possible to intercept notifications as man-in-the-middle on the bus and selectively forward the ones that one wants to a different VM via qrexec.

This would have the advantage that one could keep the local desktop notification server running (i.e. remain backwards compatible) and show notifications locally when there are e.g. buttons inside of them.

It would however require the running daemon to locally close notifications that were forwarded unless one wants them to be displayed both locally and in the other VM.

Here's a rough code sample that works on older dbus versions (non-Fedora). Fedora apparently requires the newer BecomeMonitor method.

[3hhh]

After looking into dbus details a bit, I think it would be possible to intercept notifications as man-in-the-middle on the bus and selectively forward the ones that one wants to a different VM via qrexec.

This would have the advantage that one could keep the local desktop notification server running (i.e. remain backwards compatible) and show notifications locally when there are e.g. buttons inside of them.

It would however require the running daemon to locally close notifications that were forwarded unless one wants them to be displayed both locally and in the other VM.

Here's a rough code sample that works on older dbus versions (non-Fedora). Fedora apparently requires the newer BecomeMonitor method.

I tested this approach with Firefox.

Unfortunately the race condition when closing the local notification results in the notification being displayed locally for ~1s. So this is not usable.
Strangely it works just fine with notify-send.

As an alternative xdg-dbus-proxy aims to fully proxy dbus, but appears to be rather broken and unmaintained.

It would be great to be able to handle some notifications locally (e.g. the ones with buttons), but dbus only allows one implementation to provide a service/interface at a time and it seems that you cannot directly call a previously registered implementation once you claim an interface for yourself.

So to make notification forwarding work with arbitrary applications Qubes has the following choices:

1. A full-fledged Desktop notification specification implementation, which is pretty hard (two-directional, binary icons, security considerations, make sure the dbus interface isn't claimed by gnome etc., ...) and unlikely provided by the community.
2. Fork another such implementation (currently used in debian: mate-notification-daemon), align on it for all VMs and insert some qrexec calls in it for the select group of messages that one wishes to forward.
3. Find an implementation that can be configured to call qrexec-client-vm for certain notifications instead of displaying them locally (e.g. dunst does this, but doesn't support buttons and icons itself).
4. Find some working way to intercept dbus messages (one could e.g. launch a dedicated dbus instance via dbus-launch for the local notification daemon beforehand and selectively forward messages to that bus).

[marmarek]

5. Write a simple notification server handling only simple messages (by calling qrexec-client-vm), and fallback to "full" notification server for complex calls via spawning separate dbus-daemon instance (on a different address) with just (real) notification server there.
6. (my favorite) Implement only the simple subset of the protocol (as the specification allows to both ignore unsupported parts, and announce supported capabilities). I'd consider optional (and guarded via qrexec policy) buttons support in this version, but no links, sounds(*), etc.

As for where the real notification server should run, GUI qube (which may be dom0) sounds like a logical choice, as some desktop environments have pretty tightly integrated notifications (AFAIR KDE has a built in widget that allows to review notification history too). Coincidentally, having a back channel (actions) from a GUI qube is less of an issue, as it already has a way to send data to any VM connected to it. Another qube could also be an option, especially if considering more complex features, but I don't like to put too much stuff (especially GUI related) to sys-firewall, as I'd like to make it as lightweight as possible (including possibility to use MirageOS-based one without GUI at all).

(*) Actually, sound could be handled locally, without sending it over to the notification VM.