Closed Bug 1127522 Opened 6 years ago Closed 4 years ago
Removal of screensharing whitelist
This reason the screensharing whitelist exists is the risk to the integrity of unrelated sites. In many ways, it gives a site access to something that only an add-on can get. So sharing Firefox is the baby brother of installing an add-on. The risk of sharing other applications is far more manageable. What I would like to see from the Firefox screensharing UX is the following: 1 - Firefox doesn't appear in the list by default 2 - Whole-desktop sharing doesn't appear in the list by default (it might contain a Firefox window) 3 - There is some special process for users to signal to Firefox that they want to share Firefox 4 - There is some way for a user to discover the above process when they are presented with the screen sharing doorhanger; the same discovery process is probably necessary to explain why Firefox isn't on the list Platform needs to help here by providing a way to filter Firefox from the list of windows based on whether this special signal has been created by the user. Doing just 1&2 alone removes a lot of the incentive to use the whitelist, but until we have 3&4, there is probably a case for retaining the list, solely for access to sharing Firefox.
Trying to understand: a whitelist would still required to allow users to share their browser? What would be the flow for an informed user who wishes to share their entire desktop?
It's been 8 months without resolution here. I understand the security risks, but I worry we're seeing a closed whitelist as "good enough" for the time being.
I share that concern. I believe that the resolution is blocked on UX resources. I will re-raise this with the security team, who are working with UX on new permissions flows.
In the mean time is it possible for you guys to approve some of the white listing requests that are currently requested? I raised Bug 1201832 for whitelisting of our service www.circuit.com about a month ago. I don't want to have to delay firefox support because we don't have this in place.
Does anyone own the Screen Sharing Whitelist component? There are about 20 unconfirmed bugs , all of which appear to have come from the Bugzilla template  provided on the Mozilla wiki  (and possibly elsewhere).  https://bugzilla.mozilla.org/buglist.cgi?component=Screen%20Sharing%20Whitelist&product=Firefox&bug_status=__open__  https://bugzilla.mozilla.org/form.screen.share.whitelist  https://wiki.mozilla.org/Screensharing
Since this is still open, could someone take a look a our whitelisting request, too? We're eager to get FF support implemented, and happy to answer any questions you may have. Here's the ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1240199.
Hi there -- bumping this thread again to see if someone can review our whitelist request? Would be much appreciated! https://bugzilla.mozilla.org/show_bug.cgi?id=1240199
I strongly urge you to not approve any more whitelist-addition requests. Every single entry in the whitelist is a punch in the face of the open web and creates the next walled garden after privileged app in Firefox OS.
Whiteboard: [ux][DevRel:P1] → [ux][DevRel:P1][fxprivacy][triage]
(In reply to paul.leo.steinberg from comment #10) > I strongly urge you to not approve any more whitelist-addition requests. > Every single entry in the whitelist is a punch in the face of the open web > and creates the next walled garden after privileged app in Firefox OS. As much as I'd prefer not to have a whitelist, right now it is the only method available to us (having users edit about:config isn't really practical for the average user). We reported bug 1244765 over 5 months ago to whitelist www.groupworld.net, but it is still UNCONFIRMED.
Whiteboard: [ux][DevRel:P1][fxprivacy][triage] → [ux][DevRel:P1][fxprivacy][tracking]
4 years ago
Depends on: 1315737
FIXED for 52 by the work that went into bugs this depends on.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 52
You need to log in before you can comment on or make changes to this bug.