[UX] Mistake: Firefox has no global mic/camera/screen-sharing controls
Categories
(Firefox :: Site Permissions, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | disabled |
People
(Reporter: jib, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(4 files)
FirefoxTwoTabsScreensharing.png
A recent UX redesign of our camera, microphone and screen-sharing notifications panel available in Nightly seems to assume either that:
- Firefox has global camera, microphone and screen-sharing controls, or
- Only one tab may share camera, microphone or screen capture at any one time.
Neither is the case: Firefox lets any number of tabs share any combination of camera, microphone, and screen capture at the same time, and Firefox does not implement user agent (UA) mute.
Any UX redesign needs to fit this model of use in multiple tabs. Any new feature-request like UA mute (bug 1643027) should come from a problem statement.
Example problem of new UX:
- Share your screen in two tabs https://whereby.com/adsfgsdfgsdfg and https://jan-ivar.github.io/dummy/gdm.html
In Firefox this produces a single notification banner with no indication requests are from different tabs or which tabs [Stop sharing] applies to.
|
Reporter | |
Comment 1•4 years ago
|
||
Compare to Chrome where this produces two notifications bars, one for each tab, each with its own [Stop sharing] button.
|
||
Comment 2•4 years ago
|
||
Any new feature-request like UA mute (bug 1643027) should come from a problem statement.
Is this a sufficient problem statement?:
Users are currently missing the ability to fully control their microphone and camera sharing from a single, easy-to-find global access point. We are obliged to provide to our users this greater ability to control the streams that they share.
If not, why not?
|
|
Reporter | |
Comment 3•4 years ago
|
||
Also worth noting: Chrome does not interfere or compete with a site's own mute buttons.
Chrome avoids placing any chrome-UX in the crucial lower front-and-center location, except during screen-capture.
This works well since presentations tend to be modal: users leave the browser for a moment to interact with the chosen surface (which thanks to getDisplayMedia is pushed to front), and they conveniently click [Stop sharing] when they're done to return to the browser.
This produces a nice transition from a site's mute controls, to browser-controls only during presentation, and back to site-controls afterwards, all conveniently in the sameish lower front-and-center location, without any overlap or confusion.
|
|
Reporter | |
Comment 5•4 years ago
|
||
Is this a sufficient problem statement?:
Users are currently missing the ability to fully control their microphone and camera sharing from a single, easy-to-find global access point. We are obliged to provide to our users this greater ability to control the streams that they share.
If not, why not?
That sounds like a solution to a problem, not a statement describing a problem. What are users struggling to control today?
There is no such thing as a global access point to devices in Firefox or in any browser. All controls are per document.
|
|
||
Comment 6•4 years ago
|
||
There is no such thing as a global access point to devices in Firefox or in any browser. All controls are per document.
A very true point. Part of the intent of this project is to change that.
I'll run your concern by UX and Product and drive them to a design decision.
|
|
Reporter | |
Comment 7•4 years ago
|
||
UA mute/unmute controls implemented unilaterally may pose certain fingerprinting (time correlation) and privacy concerns, since sites entrusted with camera/mic permission may be able to infer the user is in another web conference by listening to mute and unmute events on camera or microphone tracks when document.hidden, and may even listen in/peek at the user's side of the conversation if implemented poorly.
|
|
||
Comment 8•4 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)
may even listen in/peek at the user's side of the conversation if implemented poorly.
This sounds particularly bad. Can you please elaborate on this?
|
|
Reporter | |
Comment 9•4 years ago
|
||
Can you please elaborate on this?
I illustrate an example in Bug 1643027 comment 11.
I think any global button controlling functionality in multiple tabs at once is going to have usability and privacy issues.
- Usability: users might not think beyond the page they're on ("Unmute cam/mic for all tabs, are you sure?")
- Privacy: firing events simultaneously on multiple tabs creates a time fingerprint that can be abused to correlate users across domains.
There may be mitigations we can do, if benefits outweigh these issues, it's just work.
Can we enumerate the benefits over the current model?
|
|
||
Comment 10•4 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #9)
Can you please elaborate on this?
I illustrate an example in Bug 1643027 comment 11.
Okay, I understand. Thank you. The example in that bug appears to essentially be "users do not understand that this is a global mute", or a variation on "users do not understand that there are multiple levels of mute".
Privacy: firing events simultaneously on multiple tabs creates a time fingerprint that can be abused to correlate users across domains.
Okay, I understand. I realize that WebRTC is being abused by some bad actors to fingerprint and identify users across domains. Simultaneously alerting all sites that the user has muted a device can be used correlate. Thanks for clearing that up.
|
||
Updated•4 years ago
|
|
||
Comment 11•3 years ago
|
||
Mike, is this still a valid issue? Is the fingerprinting issue addressed?
|
|
||
Comment 12•3 years ago
|
||
The global camera and microphone mutes are disabled by default, so this is currently not an issue. If we ever decide to turn them on by default, we'll want to revisit this.
Description
•