PSA: enable-usermedia-screen-capture will be removed from about://flags

[Jiayang Liu]

We are planning to remove the enable-usermedia-screen-capture flag from Chrome about:://flags (Chrome issue tracker link: https://code.google.com/p/chromium/issues/detail?id=347641).

This is planned to happen in Chrome M36, which is expected to reach stable around mid July.

After the change, there will be no way to persistently enable the flag through the Chrome UI.

For testing or experimenting, the feature can still be enabled through the command line switch, e.g.

"chrome --enable-usermedia-screen-capturing".

Applications using the screen capture feature should use the chrome.desktopCapture API instead. The API is available in the current stable Chrome (i.e. M34). Here is an example.

[SProgrammer]

Thanks for sharing. 

- i have been using it 

- i hope it also fix the quality issue i had in Linux? 

(in my early posts if you check you will find that i had quality problem which was not resolved, 

the issue was: where if you have more then 1 screen and higher resolutions

also have multiple Video screens like Video WALL and then use this feature it does not do quality captures)

thanks

Best regards

Shamun

[SProgrammer]

How could a normal user Peer 1 me telling my friend Peer 2 on the fly to enable this feature?

> my friend is age 70 to 95 years and he do not know anything about IT all he knows Google Chrome to open and close

for that type of person doing following is a nightmare. Are you saying that everybody has to do this to use the screen share feature? 

$ chrome --enable-usermedia-screen-capturing

Why can we not enable it as default? 

Why can we not enable the option via Javascript?

Why does it has to be explicitly declared via command line?

Why does not not possible to have it activate when HTTPS is used?

Why do we need command line only way to activate it?

Reg

Shamun

On Wednesday, April 30, 2014 1:14:42 AM UTC+2, Jiayang Liu wrote:

[Philipp Hancke]

On Wed, Apr 30, 2014 at 12:05 PM, SProgrammer <sha...@companysocia.com> wrote:

How could a normal user Peer 1 me telling my friend Peer 2 on the fly to enable this feature?

You're not supposed to use the "old" screensharing anymore.

 

> my friend is age 70 to 95 years and he do not know anything about IT all he knows Google Chrome to open and close

for that type of person doing following is a nightmare. Are you saying that everybody has to do this to use the screen share feature? 

Have you checked the way the new API and the extension approach works? See https://meet.jit.si or https://talky.io for examples of sites using it.

While this requires installing an extension and a page reload (the first time it is used), doing inline-installs can be controlled by javascript very nicely.

Which imo is alot easier than explaining users to search for and enable something on chrome://flags.

[Alexandre GOUAILLARD]

Hi SProgrammer, 

long time no see.

Here is the discussion that will answer all your questions in details:

http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0100.html

It's 73 e-mails long, so don't hold your breath.

Some people where abusing the screen sharing flag supposed to be used by developers only without understanding the security implication:

"""Justin Uberti

Shared publicly on G+  -  Feb 27, 2014
Yikes! http://same.io asks users to manually enable the WebRTC
screenshare flag, which turns it on for all sites. There are a bunch
of potential security concerns here, summarized at
http://tools.ietf.org/html/draft-ietf-rtcweb-security-06#section-4.1.1.
Please use chooseDesktopMedia
(https://developer.chrome.com/extensions/desktopCapture#method-chooseDesktopMedia)
instead.

"""

Making this flag available for developers only (i.e. in chrome beta and canary only and not in chrome stable) is very difficult because of chrome implementation details (static table of flags common to all releases).

The last solution to make it available to testers and dev without endangering the global community was twofold:

- put it as a command line option

- make it available as a privilege API (i.e. for extensions), which in turn enable further API to capture any desktop windows.

HTH,

alex.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[SProgrammer]

Thank you. Please Explain this:

1) I have VIDEO WALL 10 people connecting Bla-1, Bla-2, Bla-3 Bla0, Bla1, Bla2, Bla3....

shown in 40" screen

2) My friend TV station has VIDEO WALL 10 people connecting Bla-1, Bla-2, Bla-3 Bla0, Bla1, Bla2, Bla3....

shown in 40" screen

3) Now me and my friend we bridge all those tunnel between 1 and 2 to make 10, 20, 100 WALLS of live persons

On the fly we share screen from all users (they are not IT people). 

How we are going to do that in next release? all our users has to must learn command line now????

Our users are normal browser users they visit site > pincode done. 

They do not need to learn what is command line arugments (we have written a book for that already) or they have to now????

Great, why you guys did not think of it in begin but after version 33 realized it!! Anyway this is a nigtmare for me, i need to have the feature available default like ALLOW or DENY when HTTPS 

Reg

Shamun

[SProgrammer]

My 2cent: Take it easy, keep it simple do not make it complicated for end users

Judge this vs Screen share:

1 - Camera is hardware, Microphone is hardware, in those case we use ALLOW, DENY, world accepted it

2 - Now screen share is not a rocket science or hardwares for rocket, its same concept its also a Hardware 

Can we just not make it same like ALLOW / DENY same we do for camera, mic capture? 

Or camera, mic has to be also require command line in some other releases? such as:

$ chrome --enable-camera-mic-we-are-screwed-we-donot-know-what-we-are-doing

Thanks a lot

Reg

shamun

[PhistucK]

By the way, why bother keeping the command line flag at all?

The feature does not seem to be getting standardized soon (I assume, I did not participate in or read the discussions) and the extension API is available for all.

☆PhistucK

--

[Justin Uberti]

We are keeping the command line flag to allow for simple testing without the extension. Similar to the other flags for generating fake video sources, etc.

[Justin Uberti]

It's not the same. Please read http://tools.ietf.org/html/draft-ietf-rtcweb-security-06#section-4.1.1.

[SProgrammer]

http://tools.ietf.org/html/draft-ietf-rtcweb-security-06#section-4.1.1

4.1.1.  Threats from Screen Sharing

   In addition to camera and microphone access, there has been demand
   for screen and/or application sharing functionality.  Unfortunately,
   the security implications of this functionality are much harder for
   users to intuitively analyze than for camera and microphone access.
   (See
   http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html
   for a full analysis.)

   The most obvious threats are simply those of "oversharing".  I.e.,
   the user may believe they are sharing a window when in fact they are
   sharing an application, or may forget they are sharing their whole
   screen, icons, notifications, and all.  This is already an issue with
   existing screen sharing technologies and is made somewhat worse if a
   partially trusted site is responsible for asking for the resource to
   be shared rather than having the user propose it.

   A less obvious threat involves the impact of screen sharing on the
   Web security model.  A key part of the Same Origin Policy is that
   HTML or JS from site A can reference content from site B and cause
   the browser to load it, but (unless explicitly permitted) cannot see
   the result.  However, if a web application from a site is screen
   sharing the browser, then this violates that invariant, with serious
   security consequences.  For example, an attacker site might request
   screen sharing and then briefly open up a new Window to the user's
   bank or webmail account, using screen sharing to read the resulting
   displayed content.  A more sophisticated attack would be open up a
   source view window to a site and use the screen sharing result to
   view anti cross-site request forgery tokens.

   These threats suggest that screen/application sharing might need a
   higher level of user consent than access to the camera or microphone.

> Here in draft no-where mention that it has to be only: 

0) "chrome --enable-usermedia-screen-capturing"

1) Google Chrome has to shutdown screen sharing module? 

2) Its a threat to the users not to the whole existing module how it was prepared so far? which can stay as it is unless you have enabled it!!

3) If an user enable the module he/she is still responsible + he/she still they can deactivate it as it is right now

4) i still do not see what is the main reason that webRTC team has to come into a final decision like shutting it down? 

The way it was, was fine? this decision is like breaking your own legs (screen sharing is a very important part, even it requires more friendly way to enable/disable)

5) the whole world is not only BANK users, there are also users who accept it as it is and for BANK's they can use "Google-Secured-Browser-Made-For-BANKS-only.exe" ? 

Why would Google Chrome stable change the root modules for this.

To me it looks like WebRTC - EVIL decision.

I still do not see any reason of even touching this module, it was perfect as it is.

its already secured cause user has to enable/disable it, later anytime still they can disable it if its unsafe for BANK!!

Reg

Shamun

[Philipp Hancke]

just gave a talk yesterday which compared both the new and the old way. Slides are available from http://hancke.name/webrtc/screenshare/

I'll probably update them next week to explain the whole webpage->content script -> background script -> choosedesktopmedia path a little more, until then checkout the sample extension at at https://github.com/henrikjoreteg/getscreenmedia

Heck, webstore inline installation is alot easier for users than going to chrome://flags and then ...

[Philipp Hancke]

For testing or experimenting, the feature can still be enabled through the command line switch, e.g.

"chrome --enable-usermedia-screen-capturing".

I expected this to work with http://kurtextrem.github.io/ChromiumFlags/#use-fake-ui-for-media-stream to automatically allow permission -- which does not seem to be the case however.

This would be really useful for automated tests.

[Jiayang Liu]

Philipp,

please file a separate bug for your request.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/TPQVKZnsF5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Jiayang Liu]

Update: the change was landed yesterday (https://codereview.chromium.org/270353002/) and will be in Chrome M37.

[Miguel Castillo]

Hi, thank you for being transparent about this.  Really seems to make things easier in many ways.  But I am still unclear about enabling the chrome.desktopCapture. Is the only way to install the extension?

Someone below states

"While this requires installing an extension and a page reload (the first time it is used), doing inline-installs can be controlled by javascript very nicely.

Which imo is alot easier than explaining users to search for and enable something on chrome://flags."

In other words, what are my options to enable the new API without having to install the extension?

Thanks in advance!

[Alexandre GOUAILLARD]

At this stage, You need to install an extension, period.

The installation can be made very easy (inline installs), but you still need an extension.

HTH

Alex.

--

---

You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Leighton Carr]

There was some indication the new desktopCapture API would work with HTTP (Phillip's slides for example) - is this still to come / not intended?

Cheers,

Leighton.

[Jiayang Liu]

You can use a command line flag --allow-http-screen-capture to make desktopCapture work with http, but it's intended for testing only.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/TPQVKZnsF5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Leighton Carr]

Hi Jiayang,

That doesn't seem to work for me in the current Chrome.  

chrome.desktopCapture.chooseDesktopMedia(['screen'], my.tab, onAccess);

calls onAccess with an undefined source ID, even with the command line flag set.

As a side note - this whole process is awful compared to chrome://flags.  Especially for developing WebRTC apps for an intranet where inline-install isn't available.  I'm going to have to talk users on the other side of the world through adding command line flags (if it works) and manually turning on developer options and installing an extension I have emailed them.

A real step backwards if you guys ever wanted screen sharing to become 'main stream'.

Cheers,

Leighton.

[Philipp Hancke]

2014-08-07 8:32 GMT+02:00 Leighton Carr <leight...@gmail.com>:

[...]

A real step backwards if you guys ever wanted screen sharing to become 'main stream'.

On talky.io, screen sharing usage has tripled when we started using an extension for this back in April.

[Leighton Carr]

So? Nobody uses a site *because* they require an extension, they use it in spite of the requirement. The user base for drive-by will always be much higher.

Not that desktopCapture is even an extension - it's a single API call that happens to be hidden in the extension sandbox because of "security reasons" despite both webcam and data webrtc being exposed to drive-by.

[Justin Uberti]

While I understand that the extension creates an extra hurdle, this is what we felt comfortable deploying for v1. If you are not convinced by the security considerations, I invite you to read the rtcweb security documents that explain the concerns, which are just the tip of the iceberg for this situation.

The flag was problematic because websites were asking users to enable this flag in chrome://flags, without any discussion of the security implications of enabling this (or other) flags.

We of course do want to find a way to safely bring this feature to the drive-by web, but it's a hard problem and will take some time. In the short term, we are looking at making using an extension easier.

On Thu, Aug 7, 2014 at 3:53 PM, Leighton Carr <leight...@gmail.com> wrote:

So? Nobody uses a site *because* they require an extension, they use it in spite of the requirement. The user base for drive-by will always be much higher.

Not that desktopCapture is even an extension - it's a single API call that happens to be hidden in the extension sandbox because of "security reasons" despite both webcam and data webrtc being exposed to drive-by.

[Alexandre GOUAILLARD]

hi justin,

just a side question, martin and eric mentioned they wanted screen sharing in V1, as part of the standard. I remember that we decided to have a separated document for that which I don t seem to be able to find anymore. Martin would have drafted it if i remember correctly.

Did we decide anything on how this would be accessible? or did the mozilla team mentioned how they were planning to make it accessible?

Alex.

[Philipp Hancke]

2014-08-13 10:34 GMT+02:00 Alexandre GOUAILLARD <agoua...@gmail.com>:

hi justin,

just a side question, martin and eric mentioned they wanted screen sharing in V1, as part of the standard. I remember that we decided to have a separated document for that which I don t seem to be able to find anymore. Martin would have drafted it if i remember correctly.

Is https://github.com/fluffy/w3c-screen-share what you're looking for?

[Enda Mannion]

Am I right in saying the command line flag  --enable-usermedia-screen-capturing    is not supported anymore in any Chrome release?

[Vikas]

Hi,

The command line option should still be available. See this link.

/Vikas

[Enda Mannion]

Sorry, your right, its still working, thanks.

[changb...@intel.com]

Hi Jiayang, 

Then how about its behavior on Android? Will '--enable-usermedia-screen-capturing' work on Chrome Android?  Is there any chance for developer to share screen on Android? 
Thanks!

[Sandra Andonov]

Hi,

I'm using Chrome v. 39 and at this line, when trying to use the new desktopCapture api:

chrome.desktopCapture.chooseDesktopMedia(["screen"], null, function(streamId) {

            alert(streamId);

 });

desktopCapture is not defined !?

What am I missing?

Thanks,

S.

[PhistucK]

Where are you trying to use it? It is a Chrome extension or Chrome application API, not an API exposed to web pages. Since Chrome for Android does not support Chrome extensions or Chrome applications (you have to use Cordoba or cca for that, which is separate from Chrome), it is indeed rightfully undefined.

☆PhistucK

--

[Sandra Andonov]

Ok. I wasn't aware of that. I'm kind of new here. Thanks.

 

 Sincerely, 

 Sandra Andonov,

 Development Team Lead, Inovatika DOO

Mobile phone:       Web:                 Skype:

                        +389 78 246 224       www.inovatika.net     gorgieva_sandra

                            

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/TPQVKZnsF5g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[PhistucK]

Generally, anything under chrome in JavaScript (chrome.x) is nonstandard and not exposed to web pages. There are very few exceptions, but they mostly do not provide significant functionality (like load timings, which window.performance.timing generally provides).

☆PhistucK