Firefox microphone overlay / Alert boxes are obtrusive and look strange

[Minimalist73]

Qubes OS version

4.1

Which testing repositories are you using, if any?

Testing repo enabled in dom0.
Testing repo enabled in all VMs

Are you providing feedback about a specific package or packages in testing?

Issue started when these packages were installed in dom0:

qubes-anaconda-addon-4.1.6-1.fc32.noarch
qubes-usb-proxy-dom0-1.1.0-1.fc32.noarch
qubes-menus-4.1.8-1.fc32.noarch
qubes-dom0-meta-packages-4.1.15-1.fc32.noarch
qubes-desktop-linux-manager-4.1.9-1.fc32.noarch
qubes-desktop-linux-common-4.1.8-1.fc32.noarch

Affected component(s) or functionality

Qubes desktop

---

Brief summary

Since I updated the dom0 packages I quoted before, the Firefox microphone overlay moved down a bit, just under the dom0 bar. Before, it was directly on it and was less intrusive than now since it's staying on every workspace.

How reproducible

100% reproducible

Steps to reproduce

Use Firefox with microphone enabled on a page

Expected behavior

The overlay should be standing at the same level as the VMs icons so you can move it to a place that don't disturb any workflow.

Actual behavior

Overlay is under dom0 bar, so it's very visible everywhere and can't be moved to a corner or somewhere that can make it less intrusive.

Solutions you've tried

Hide the overlay with userChrome.css (not really a solution since it's a security measure)

Additional context

It seems to do the same thing for alerts too, on my 4.0 qubes I can also have this strange behavior:

I then tried to do the same thing with a 4.1 StandaloneVM too (using testing repos):

2 first alerts are close then a gap appear.

---

Relevant documentation you've consulted

N/A

Related, non-duplicate issues

None found.

[DemiMarie]

This is due to QubesOS/qubes-gui-daemon#71, which prevents any qube-drawn window from overlaying the taskbar. Previously, a qube-drawn window could cover the taskbar and prevent it from being used. The GUI daemon now moves the window below the taskbar to prevent this.

That said, this is no excuse for a bad user experience. @ninavizz what would be a better approach? Perhaps making a notification for “some qube has non-muted access to the microphone”, and then suppressing the notification from Firefox?

[ninavizz]

I actually have noticed that all of the notifications on my own machine that are not the black dom0 generated ones, also pop-up over my task bar—which is a real problem.

Generally, the entire "notifications experience" across Qubes feels very in need of some love, to me. Split GPG, clipboard, dom0... everything is very disparate and obtrusive, or overwhelming. Yet, all of the core information also does need clear communication to users.

Yet Another Shoe That Is Beautiful, Needing A Polish. So, a UX project, in and of itself. :(

[ninavizz]

Thank you @Minimalist73 for capturing those screenshots and for filing this issue! This wonderfully encapsulates what I have also observed, grumbled about, but have never had the time/space to thoughtfully compose an issue for. :)

[ninavizz]

I poked into this specific user issue just a bit, and learned that the Firefox widget cited in this issue is a non-standard add-on to Firefox. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/getUserMedia and https://stackoverflow.com/questions/30852775/how-to-hide-firefox-camera-icon-overlay-in-windows

So, more broadly, the problem is how to manage notifications from app widgets that are spawned from outside standard windows, if I understand this correctly.

@Minimalist73 I am curious why, in Qubes OS, you're choosing to additionally use this feature of Firefox's? It seems like device permissions management can be most easily done at the qube level, through device access to different qubes and restricting use of different apps in different qubes to security/privacy needs—but I could also see how that as a forced workflow could feel imposing.

@DemiMarie More broadly, though, based on my own experiences with the SecureDrop client and its windows/dialogs, window management as a general thing feels like it could be refined some. I bigger problem I don't have specific answers for, as it's more of a technical challenge... but experientially, it's been a challenge for me to resolve just in my work on managing that one app's experience.

[Minimalist73]

@Minimalist73 I am curious why, in Qubes OS, you're choosing to additionally use this feature of Firefox's? It seems like device permissions management can be most easily done at the qube level, through device access to different qubes and restricting use of different apps in different qubes to security/privacy needs—but I could also see how that as a forced workflow could feel imposing.

@ninavizz I didn't know this overlay was deprecated, I've always seen it before and it's active by default (at least on the templates I tested Firefox on). From the second link, I can successfully get rid of it so it's a good solution, the "legacy" part of the about:config option confirm it's something that's going to go away but for some reason it's still on "true" on every Firefox profile. I don't know if this is possible to turn that option off without pre-generating a Firefox configuration with it turned to "false". It needs some investigation on that side since It can successfully be securely managed with Qubes microphone option.

For example, even on the latest Firefox version downloaded from the official website, it's still there and option on "true":

For now, I'm going to disable this option manually on all qube where I use the microphone on Firefox, thanks for the information again!

[deeplow]

Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached.

The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute.

[DemiMarie]

Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached.

The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute.

This already exists in pavucontrol! That doesn’t mean it is a good UI, though.

[ninavizz]

I'd a

Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached.
The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute.

This already exists in pavucontrol! That doesn’t mean it is a good UI, though.

I'd argue that anything "already in" a 3rd party utility a user would have to research and install on their own, is not a good user experience. If we could bundle this in and reference it in the docs, that'd be great.

[ninavizz]

Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached.

The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute.

What I'm not understanding in this proposal of yours @deeplow, is this: if you don't want the mic accessed by a VM, why attach it to the VM in the first place? Did you mean a per-app mute utility?

[brochard]

What I'm not understanding in this proposal of yours @deeplow, is this: if you don't want the mic accessed by a VM, why attach it to the VM in the first place? Did you mean a per-app mute utility?

It's useful when apps require a microphone or require a webcam, you still want one connected but not giving any signal. I think it's also useful if you want to quickly safely mute, you don't want to reconnect your new mic input to your app every time.

[unman]

On Fri, Jul 16, 2021 at 03:16:12PM -0700, Nina Eleanor Alter wrote: > > Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached. > > The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute. > > This already exists in pavucontrol! That doesn???t mean it is a good UI, though. I'd argue that anything "already in" a 3rd party utility a user would have to research and install on their own, is not a good user _experience_. If we could bundle this in and reference it in the docs, that'd be great.

It's not a case of installing anything. The feature already exists, and pavucontrol is installed, accessible from the tray icon. It allows for per-qube muting of input devices, as well as per-qube muting. Just a documentation issue?

[deeplow]

Just adding here an observation: although annoying this this may be a great idea to implement on a Qubes-level (separate issue probably). Having a per-vm accessible mute control when the microphone is attached.
The reason behind this is that if you use zoom and mute zoom, you need to trust zoom that it's doing the proper thing. Having a popover with a mute would lead to a safer way to mute.

What I'm not understanding in this proposal of yours @deeplow, is this: if you don't want the mic accessed by a VM, why attach it to the VM in the first place? Did you mean a per-app mute utility?

Use-case (without the per-vm mute feature)

1. You are on a work videoconference on work-conference qube
2. You attach your mic to work-conference
3. You start the meeting
4. Someone in your house interrupts you with for some urgent private conversation
5. You mute the mic in the app (because going to Qubes Devices » Microhone » work-conference to detach is too painful

In this scenario you are trusting your qube not be be compromised and your videoconference program (e.g. zoom) to respect "mute" button (they could keep on listening)

Use-case (with the per-vm mute feature)

1. You are on a work videoconference on work-conference qube
2. You attach your mic to work-conference
3. You start the meeting
4. Someone in your house interrupts you with for some urgent private conversation
5. You click the little mute button next to the videoconf window (that is dom0 controlled) and if easily and safely mutes the audio / video.

@ninavizz makes more sense?

[ilka-schulz]

I actually have noticed that all of the notifications on my own machine that are not the black dom0 generated ones, also pop-up over my task bar—which is a real problem.

not sure if this his helpful but it works for me: I put my taskbar to the left side of the screen instead of the top and I never had any problems with obtrusive alert boxes.

[DemiMarie]

This isn’t fixed, but I think it can’t be fixed without compromising security. @andrewdavidwong would this be appropriate for R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken. ?

[andrewdavidwong]

This isn’t fixed, but I think it can’t be fixed without compromising security. @andrewdavidwong would this be appropriate for R: declined Resolution: While a legitimate bug or proposal, it has been decided that no action will be taken. ?

Sounds appropriate to me.

[github-actions]

This issue has been closed as "declined." This means that the issue describes a legitimate bug (in the case of bug reports) or proposal (in the case of enhancements and tasks), and it is actionable, at least in principle. Nonetheless, it has been decided that no action will be taken on this issue. Here are some examples of reasons why an issue may be declined:

• No solution can be found.
• The proposed action is not possible.
• The proposed action would weaken security to an unacceptable degree.
• The proposed action would be too costly (in time, money, or other resources) relative to the benefits it would provide.
• The proposed action would make some things better while making other things worse, and the trade-off is not worthwhile.

These are just general examples. If the specific reason for this particular issue being declined has not already been provided, please feel free to leave a comment below asking for an explanation.

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "declined" is not accurate, please leave a comment below saying so, and the Qubes team will review this issue again. For more information, see How issues get closed.