Project: webrtc Issues People Development process History Sign in
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 61 users
Status: Assigned
Owner:
Last visit 17 days ago
Cc:
Components:
OS: ----
Pri: 2
Type: Bug

Blocking:
issue chromium:118551
issue chromium:326740



Sign in to add a comment
Enable screen capture support in getUserMedia by default.
Reported by ri...@turtleyogi.com, May 10 2013 Back to list
What steps will reproduce the problem?
1. Download latest Chrome
2. goto chrome://flags
3. This flags is disabled by default " Enable screen capture support in getUserMedia()."

What is the expected result?
Would like to know when will this be enabled by default.

What do you see instead?
Would like to see the flag enabled by default.


 
Project Member Comment 1 by juberti@webrtc.org, May 10 2013
This is unlikely to happen until at least M30 due to security concerns.
Project Member Comment 2 by braveyao@webrtc.org, May 13 2013
Cc: braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: juberti@webrtc.org
So should we close this issue for now or leave it until M30?
Project Member Comment 3 by juberti@webrtc.org, May 16 2013
Leave it open for now, no mstone.
Can this be allowed through a chrome extension? There are plugins downloaded for screen sharing.
Project Member Comment 5 by juberti@webrtc.org, May 18 2013
Yes, apps and extensions will probably get access to this API before the drive-by web.

tabCapture is already exposed to extensions.
Any update on this?
Comment 7 by juberti@google.com, Oct 9 2013
Supported now via chrome extensions, but not exposed to the drive-by web.
Is there a way to check programmatically (in JS) that this is not available. AFAIK GUM error will not allow to differentiate between this case and several other potential reason it would fail (even thought latest specs improve the granularity).

I'm ok with this function being behind a flag, as long as I can detect that it is not available before trying to use it, and/or i'm able to see it's not working because it's not available.
Project Member Comment 9 by juberti@webrtc.org, Oct 23 2013
 Issue 2088  has been merged into this issue.
Project Member Comment 10 by juberti@webrtc.org, Oct 30 2013
Labels: Mstone-33
Status: Assigned
Current plan is to open up chrome.desktopCapture.chooseDesktopMedia to all apps in M33. For M32, it will available in the Chrome dev and beta channels.
Is that Apps and Extensions, or just Apps ?
Project Member Comment 12 by juberti@webrtc.org, Oct 30 2013
both.
Google's Chromecast extension seem to make use of this API, I suppose it's white-listed since it works in M31?
Project Member Comment 14 by juberti@webrtc.org, Oct 30 2013
Chromecast uses a different API to pick a tab; this API allows you to pick a desktop or particular window.
Google's cast extensions currently uses getUserMedia to capture the desktop. You need to click the little down arrow and switch to the "Cast entire screen (experimental)" option.
I guessed that Google's extension was whitelisted for that API since from what I understand it doesn't work for other extensions.
Project Member Comment 16 by juberti@webrtc.org, Oct 30 2013
Right, but what I am saying is that Chromecast doesn't use chrome.desktopCapture.chooseDesktopMedia, which is what is currently being discussed.
BTW: it would be nice if it was also possible to select the area to be shared rather than just the full screen or a window
Comment 18 Deleted
Project Member Comment 19 by juberti@webrtc.org, Nov 22 2013
Please create a separate enhancement request for region selection.
Blocking: chromium:326740
Project Member Comment 21 by juberti@webrtc.org, Jan 15 2014
Labels: -Mstone-33
Project Member Comment 22 by juberti@webrtc.org, Jan 15 2014
Labels: Area-GetUserMedia
Comment 23 by dk...@ivtweb.com, Jan 16 2014
Can you confirm if the roadmap calls for drive-by web to receive screen capture from getUserMedia, and for some variant of chooseDesktopMedia to be exposed as an API for drive-by web?
Screen capture will not be available to the drive-by web in v1. chooseDesktopMedia will be available if an extension is present.
But is there a plan to allow screensharing support for drive-by-web sometime this year? Or, waiting on the standardization process to agree on a security model?
Comment 26 by juberti@google.com, Jan 21 2014
Right now there aren't any detailed proposals on the table for exposing screensharing to the drive-by web. So I think it's unlikely it will be part of WebRTC 1.0. 

This topic continues to get a lot of attention and I hope that we can find a solution for future versions of WebRTC.
Comment 27 by aobe...@gmail.com, Mar 17 2014
could we have an update regarding when these APIs will hit stable? 33 is out now and i noticed its still not available.
Comment 28 by juberti@google.com, Mar 17 2014
chrome.desktopCapture.chooseDesktopMedia is available to beta in M33, and will be in M34 stable.
Is M34 stable still the plan for choosedesktopmedia?  crbug.com/347641  seems to have moved to M36.
It looks as if a Chrome app that does contentscript injection has to be tied to a certain set of websites, and inline installation has to also be tied to a particular set of sites.

I have been looking at using screensharing in local installations - either customers taking an SDK and building their own WebRTC interfaces or installing pre-packaged solutions within a site. Proof-of-concept worked beautifully with the flag. But if the app has to be tied to a particular domain this simply won't work any more, since we won't know what site the SDK is being used on. This would potentially mean that every single site would need an app in the app store, right?

Furthermore, some customer sites may not even have external web access. This appears to be blocking a significant set of possible users, especially given proof-of-concept works with the flag but (unless I'm missing something) will not with the requirement to go via an app.
Project Member Comment 31 by juberti@webrtc.org, May 8 2014
For deployment at sites without external web access, you can push an extension to users via Chrome corp policies.
Thanks Justin, but that was a side issue. What about sites built on a SDK? That's my biggest concern here - we don't know where users will deploy the sites, so can't publish extensions to cover all possibilities. And we can't expect users to build and upload extensions for every site they deploy?
Project Member Comment 33 by juberti@webrtc.org, May 8 2014
Can you give some specific examples?  We can discuss with our security team how you can best achieve your goals. Agree having 100 extensions that differ only by URL isn't ideal.
We're doing something similar to Alan: our web conferencing software is distributed to companies who run it on their websites or their internal networks. It doesn't really make sense to have to publish our entire app as an extension just so we can get screen sharing on chrome, and if the extension is tied to one domain that makes even less sense.

Ideally we would like a cross-platform screen sharing API that doesn't require extensions or the user having to fiddle with flags.

Regarding security: if you're worried about users giving permission to a webpage to share their screen and then forgetting about it (or not realising that it's grabbing their entire desktop), why not have a small 'preview' window showing exactly what is being shared?
Project Member Comment 35 by juberti@webrtc.org, May 23 2014
The concern isn't users forgetting. It's users being tricked into consenting, and then the attacking page grabbing everything they might want - email, bank info, anything you might happen to be logged into at the time.

We know from other clickjacking situations that users can be tricked in this way.
In that case I would suggest having a slightly more dire warning to the user. Rather than simply having a little box they click that says something like 'enable screen sharing' (I can't remember the exact wording), have a larger warning box explaining the risks.

Right now screen sharing is the only missing feature in html5 for web conferencing.
Project Member Comment 37 by juberti@webrtc.org, May 23 2014
Sadly, users often don't read dialog boxes. The browser still has to try to keep them safe from attackers nonetheless.

We don't have anything more to say on this now other than what I said in #24, but this issue is an ongoing discussion both internally and in standards organizations.
> It doesn't really make sense to have to publish our entire app as an extension

You don't have to do this, the extension can be a small helper application (~50 lines of code) that calls chooseDesktopMedia and then returns the window id to the page js. http://hancke.name/webrtc/screensharing tries to explain the whole process.

Sites will still have to upload their own extension in the store which is a less than ideal situation from the operational perspective. But the user experience has improved.
Philipp - that URL 404s
Comment 40 by aobe...@gmail.com, May 23 2014
Thanks phillipp, that URL worked for me.

I'm pretty surprised that the extension just needs to grab an ID and pass it back to the host page.  This means that the MediaStream object still lives on the host page. Reading into the posted security risks section, the host page is still what controls the content on screen, so this doesn't seem to resolve all the concerns that come from the Same Origin Policy (read: http://www.ietf.org/mail-archive/web/rtcweb/current/msg06755.html). But it does make the implementation of a screensharing service much easier :)

It does feel a little bit arbitrary to allow drive by web applications to use the screen as long as they upload this package to Google's store and the user is cool with downloading it (requires user to sign in and share data with Google). These applications end up with just as much control and with just as much of a loophole for malicious use. The user sees one extra prompt which isn't very transparent about the risks at all (the prompt to install an extension shows a description written by the application author, an icon uploaded by the author, and a public 'star' rating).

I think we should aim to do better. Better by the developers who want to use this functionality, and better by the users who want to use it while also knowing the browser has taken care of certain risks for them.
>Sites will still have to upload their own extension in the store which is a less than ideal situation from the operational perspective. But the user experience has improved.

But the problem here for me, and the comment in #34, is that we do not know _where_ users will deploy the site so we cannot publish an extension specifically for it.

Prior to locking down extensions to only the Chrome Store (or enterprise policy), we could have auto-generated .crx files so the functionality was locked to the site once we knew where it had been installed. But this is no longer possible, so the only way I can see of achieving what we need is a global-match extension, which seems to be going against the purpose of making this an extension in the first place.
I'd like an approach not unlike CORS to be considered as a solution. But that's up to the standard to specify.
Comment 43 by juberti@google.com, Oct 17 2014
Cc: juberti@webrtc.org
Owner: jiayl@webrtc.org
Jiayang is looking into what can be done about the origin policy.
Is it possible to get ID for the tab and stream the tab instead of window/screen?
Comment 45 by rob@robwu.nl, Mar 17 2015
#44
Use the tabCapture API - https://developer.chrome.com/extensions/tabCapture
Project Member Comment 46 by tommi@webrtc.org, Apr 20 2015
Labels: EngTriaged
Project Member Comment 47 by juberti@webrtc.org, Nov 11 2015
Owner: juberti@webrtc.org
Project Member Comment 48 by jansson@webrtc.org, Jul 8 2016
juberti@ any updates on this?
I'd also like to know where this issue stands. Seems like a frequent request.
Blocking: chromium:118551
For what it's worth, Firefox just removed the screensharing whitelist which was requiring shipping custom extensions too: https://bugzilla.mozilla.org/show_bug.cgi?id=1127522
Comment 52 Deleted
Sign in to add a comment