New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 24 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocked on:
issue 326740
issue 416856

Sign in to add a comment

Issue 850536: Eliminate special-casing of Google Hangouts access to screen sharing

Reported by, Jun 7 2018 Project Member

Issue description

Microsoft edge and Mozilla Firefox ship the getDisplayMedia() API to enable websites to ask the user's permission to share their screen ( issue 326740 ).

The security / capability tradeoff here is obviously very difficult and hits on a fundamental question around the nature of the web. See  issue 416856  for some debate.

Chrome ships a pre-installed extension which gives only Google Hangouts this capability (  From a web platform perspective, this is not an acceptable long-term solution to the tradeoff - it's just a mitigation that relieves some of the motivation for tackling the fundamental challenge here.  If Google feels we need the web to have this capability, then we need to figure out how to provide it in Chrome in a way that sufficiently mitigates the security/privacy risk.  The only other self-consistent resolution is that Google believes this is a capability that is too dangerous for the web platform to have.

I'd like to see a plan to eliminate this special case one way or another.  That could be requiring hangouts users to manually install an extension in Chrome in order to get screen sharing (or switch to Firefox/Edge where no extension is required of course).  Or it could be some plan to get security approval to ship the same API as Firefox and Edge.  From recent discussion on blink-api-owners-discuss it sounds like the latter is plausible:!topic/blink-api-owners-discuss/yTtmVyIBpZg

I think it's on the WebRTC team to drive this debate, but I'm happy to help (eg. in arguing why the status quo is unacceptable from a platform perspective).

Comment 1 by, Jun 7 2018


Comment 2 by, Jun 7 2018


Comment 3 by, Jun 7 2018

Adding in some security people here, because the exact details of the chooser are the key detail that needs to be resolved, and that will require collaboration with and sign-off from security.

Comment 4 by, Jun 7 2018

Labels: Team-Security-UX
Summary: Eliminate special-casing of Google Hangouts access to screen sharing (was: Eliminate special-casing of Google hangouts access to screen sharing)
The existing chooser UX that the extension provides seems good to me, FWIW. But listen to Enamel team, not me.

Doesn't this bug affect Android, Chrome OS, and Fuchsia, too?

Comment 5 by, Jun 7 2018


Comment 6 by, Jun 8 2018


Comment 7 by, Jun 8 2018

Does anyone know the background why this was added as an extension? Any previous attempts that failed or inherent obstacles?

Comment 8 by, Jun 8 2018

The original decision to go with available-to-extensions was based on the idea that we could blacklist extensions that misbehaved. Many extensions have been published.
The decision to distribute the Hangouts extension with chrome rather than download as needed was, I believe, done independent of the screencast; way back when, the extension did many things - more than it does now.

Comment 9 by, Jun 8 2018 has some general thoughts back from the time the extensions were introduced.

What i've heard about hangouts (hearsay!) is that it would have been disruptive to users to change things from "it works" to "you need to install an extension" (which imo is not that disruptive, inline installation works very nicely).

Unfortunately the extension making things just work for * meant that just worked and despite a new UX did not have to use the extension way.

It might be worth restricting the domains in the manifest.json file to hangouts and meet in order to create friction for launching new stuff that relies on this.

Comment 10 by, Jun 8 2018

Labels: OS-Chrome
> Doesn't this bug affect Android, Chrome OS, and Fuchsia, too?

The special casing of hangouts (what this bug is about) is based on a component extension which I believe is desktop only.  That does include Chrome OS, but not Android.

If we go with  issue 326740 , then yes hopefully we'd expose that API on Android as well, but let's leave the details for that bug.

Comment 11 by, Jun 12 2018

The google groups discussion had a lot of questions about why the various extension functionality exists. rbyers@: if you'd like more background, can you start an internal email thread with me, saeedj@, efernandez@, rschriebman@, and tommi@? We can probably figure out answers to all the questions involved.

Comment 12 by, Jun 12 2018

I think this bug is a bit confusing. The main issue we should work on is making screen share more accessible to any web app. Hangouts should of course follow the changes we do, but it's not really the main priority since they are in a "good place" compared to other apps.

Comment 13 by, Jun 13 2018

Re #11 & #12: Yes, this bug is specifically about adding desktop-media (i.e. screen, window, tab, etc) sharing capabilities via getUserMedia(), where the general set of Hangouts extension capabilities is a separate discussion.

Comment 14 by, Jun 14 2018

Given that everyone else has just gotten a somewhat hard deadline of September 12th for switching to getDisplayMedia in  issue 326740 :

should hangouts be allowed to use the extension after September 12?
After all, if getDisplayMedia solves all the issues...

Comment 15 by, Jun 14 2018

#14 - it is unknown at the moment whether screen sharing is the only required missing feature that the extension provides. It also provides logging and perhaps some Native Client module with unknown (private?) features, so it is (unfortunately) unknown if it is necessarily redundant, even with getDisplayMedia (which did not get any deadline, only wishful thinking)

I doubt it will be ready for a September release, since the code must be committed by July 19th and seeing as it is a totally unplanned development without even a design (graphical as well as technical), it is unlikely to be ready, in my uneducated opinion.

Comment 16 by, Jun 15 2018


Comment 17 by, Jun 15 2018

Status: Available (was: Unconfirmed)

Sign in to add a comment