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 10 users
Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Populate labels only if permitted in MediaStreamTrack.getSources()
Project Member Reported by vrk@chromium.org, Aug 2 2013 Back to list
What steps will reproduce the problem?
1. Call MediaStreamTrack.getSources() on a webpage whose camera and mic permissions are set to "Ask"
2. Examine labels

What is the expected output?
Labels should be empty strings

What do you see instead?
Labels are populated
 
Comment 1 by vrk@chromium.org, Aug 2 2013
Already have CL out to fix: https://codereview.chromium.org/20848002/ likely to land Monday.
Comment 2 by vrk@chromium.org, Aug 7 2013
Status: Fixed
Hi, the fix for this issues doesn't make sense to me (and others on the web RTC group).  What is the point of being able to get the available sources if you need to first call GUM for every source?  This way, there is no way to present the available sources to a user and let them select which to use.  I assume that this is the intended functionality of the getSources functionality, so I think that this change should be undone.
Comment 4 by vrk@chromium.org, Aug 7 2013
#3: Great question :) In short, this is done for privacy reasons. 

Here is the spec description for SourceInfo.label:
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#widl-SourceInfo-label

The description of label reads:
"If the application is authorized to get info from this source, the label attribute will be filled in with exactly the same value as would have been returned from a call to getUserMedia() with a constraint specifying this source's sourceId."

Key point being, "If the application is authorized to get info from this source."

So what does it mean for an application to be "authorized"? This means getUserMedia() has been allowed for the origin at least once. Another way to put it is, labels will *not* be populated if you would still get the allow/deny bar in Chrome when calling getUserMedia(). If getUserMedia() has been allowed for this origin, such that getUserMedia() would not result in the allow/deny bar, then labels *will* be populated.

Note also that getUserMedia() permission is only saved between sessions when run over https...

So you should be running your code over https. The very first time a user loads your code, the JavaScript will not have access to the user's device labels. After this user has Allowed getUserMedia() once, from then on JS will able to see labels. This should persist between Chrome session indefinitely unless the user revokes permission for getUserMedia for that origin.

Hope that clarifies things.
Thanks for the details.  It does clarify why it was done, even if I don't agree with it.  Effectively, we are now in a spot where the system is going to ask the user "Can I use Camera A" before the user had the opportunity to select which camera to actually use. I would love for you to reconsider how it is implemented, but now that I know how it works I can work around it in a kind of clunky way.
Cc: braveyao@chromium.org vikasmarwaha@chromium.org
Comment 7 by vrk@chromium.org, Aug 7 2013
> Effectively, we are now in a spot where the system is going to ask the user "Can I use Camera A" before the user had the opportunity to select which camera to actually use. 

May I ask what you're trying to do that would make this problematic? Consider the most obvious use case for getSources(), which is a device selector. I can't think of many mic or webcam apps (web or otherwise) that prompt the user to choose which camera or mic to use before loading the app -- it makes more sense to just start the app assuming the user wants the default camera and mic. Then if the user notices that the app is using the wrong camera, they can fiddle with the settings to select the correct one. 

If you follow the above pattern with getUserMedia/getSources, you should have no problem getting the labels at the point in time when you'll actually want the labels because you will have requested the default devices first.
I'm looking to actually setup 3 separate cameras that the user will use. In my app, each cam would have its own unique purpose (and there is no good way to know which cam should go to which stream). So I wanted the user to select cams first and then start all at once.

one thing you mention that I was not clear on: will a single GUM call then allow access to all source labels? From the description it sounded like a GUM call would be needed for EACH cam before we would be able to get its label. 
Comment 9 by vrk@chromium.org, Aug 7 2013
> I'm looking to actually setup 3 separate cameras that the user will use. In my app, each cam would have its own unique purpose (and there is no good way to know which cam should go to which stream). So I wanted the user to select cams first and then start all at once.
I see. It seems like you would still want a <video> preview in your selection menus. For example, two logitech cameras plugged into a system will have labels like "Logitech Camera" and "Logictech Camera #2", so it doesn't really make sense to have your user choose between them without having a local preview. If you have a local preview, then this label policy is simply requiring you to populate the initial local preview <video> with the default camera.

> one thing you mention that I was not clear on: will a single GUM call then allow access to all source labels? 
Yes.

> From the description it sounded like a GUM call would be needed for EACH cam before we would be able to get its label. 
Nope, not needed for each camera. Permitting a single camera via gUM will give you access to all camera labels, and this permission persists after restarting Chrome (for https). Note that this is limited by origin, i.e. permissions granted for a.com don't apply to b.com. Camera permission is independent of mic permission as well, so if you call gUM for only camera access, that doesn't give you mic labels. (But if you called gUM asking for both mic+camera, you'd get all labels for all mic+camera devices.)
Alright, I think this answers all my questions (I don't entirely agree, but I'm not the one developing the functionality!) I can definitely accomplish what I am trying to do. Thanks for the timely responses. 
vrk: in my use case I have 3 video elements on the page and I have 3 cameras connected and each camera should always go to the same video element. I am running it over https so the user doesn't have to "Allow" every time - but I still have to pause between attaching each video, because the user has to pick a different camera. I just want to automate that for the user.

BTW: I also want to get rid of the "reload page" button after choosing a different camera. It's easy enough for the user to hit the reload page button - we don't need a second reload button to achieve that
I don't know if it was discussed, but the first getUserMedia only asks for permissions "to use your camera and microphone" and don't inform the user what device it will use, this isn't a worst behavior compared to the device label enumeration? And also if the user denies the permissions then is impossible to require new permissions.
I can understand why a manual input from the user is a security feature to give permissions to the script to access the device but I still don't understand the point of hiding the device label. 

In my use case I have connected 5 cameras. I need to obtain the camera label so that I can display the label next to the preview before granting a particular camera permission.

While using http connection, even before giving the permission to the devices, my script creates video tags for the preview and checkboxes, for all the connected cameras. I am able to see device id, a long alphanumeric string. The checkbox can trigger a call to use the particular device via device id. Each camera's vendor is unique and I know their physical location which is pertinent in my use case. So it would be more useful for me to "allow" only the particular camera whose label I could see even before allowing permission to access it. I don't want to call getUserMedia in the very beginning as it pulls up the permission request 5 times even when I only need to allow one or two particular cameras during a "browsing context". At another time, after reopening the browser, I may need to allow certain other cams but I don't want to go through the permission request 5 times over and over again.   

You might suggest using https which is going to take me a while to set up. This would still not address the issue that I close the browser and reopen it when required. More importantly, I'm still trying to understand how hiding the device label addresses a security or privacy concern. 

is this http://www.w3.org/TR/mediacapture-streams/#enumerating-devices the alternative? the link posed in #3 isn't working anymore so I wasn't able to read the possible reason for not populating the device labels. 
Comment 14 by Deleted ...@, Nov 17 2015
joe says: We are now in a spot where the system is going to ask the user "Can I use Camera A" before the user had the opportunity to select which camera to actually use.

samkha says: I can understand why manual input from the user is a security feature to access the device but I still don't understand the point of hiding the device label.

vrk says: If the user notices that the app is using the wrong camera, they can fiddle with the settings to select the correct one. 

Challenge:

Two of these beings are people.  One is a programmer.  Draw the Venn diagram.


Cc: -vikasmarwaha@chromium.org hta@chromium.org
To #14 and anyone else with open questions - could you either file a new bug or start a thread in the discuss-webrtc list (https://groups.google.com/forum/#!forum/discuss-webrtc)?

And for those of you with suggestions for improvements - could you file new bugs? Thanks!
Sign in to add a comment