RE: An alternate approach to enumerating devices

It may just be that the format is odd on my system, but is 'facing' available if the app is not trusted?

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, March 21, 2013 3:05 PM
To: Harald Alvestrand
Cc: public-media-capture@w3.org
Subject: Re: An alternate approach to enumerating devices

This is good.

The addition of label needs more work though.  What do you do to distinguish an application/site as being "trusted" or not such that you can expose the label?

On 21 March 2013 11:46, Harald Alvestrand <harald@alvestrand.no> wrote:
> That was too weird - trying again, without formatting....
>
>
> The WebRTC GetUserMedia spec released on March 20 has this device 
> enumeration API on the VideoStreamTrack and AudioStreamTrack:
>
> -------------------------------------
>
>
> interface VideoStreamTrack : MediaStreamTrack { static 
> sequence<DOMString> getSourceIds (); ....
> };
>
> Explanation:
>
> getSourceIds, static
> Returns an array of application-unique source identifiers. This list 
> will be populated only with local sources whose sourceType is "camera" 
> or "photo-camera" [and if allowed by the user-agent, "readonly" 
> variants of the former two types]. The video source ids returned in 
> the list constitute those sources that the user agent can identify at 
> the time the API is called (the list can grow/shrink over time as 
> sources may be added or removed). As a static method, getSourceIds can 
> be queried without instantiating any VideoStreamTrack objects or without calling getUserMedia().
>
> ISSUE 1
> Issue: This information deliberately adds to the fingerprinting 
> surface of the UA. However, this information will not be identifiable 
> outside the scope of this application and could also be obtained via 
> other round-about techniques using getUserMedia().
> (end quote)
>
> --------------------------
>
>
>
> I suggest this is a bit limited, and we should instead offer:
>
> <proposal begins>
>
> interface MediaStreamTrack {
> static sequence<SourceInfo> getSourceInfos() }
>
> dictionary SourceInfo {
> DOMString id; // same as “sourceid” in previous proposal DOMString 
> kind; // “video” or “audio”
> DOMString label; // only present if authorized VideoFacingModeEnum 
> facing; // only for video sources }
>
> with the additional text:
>
> If the application is authorized to get info from one or more sources, 
> the “label” attribute will be filled in for those sources, with 
> exactly the same value as one would have had if the application had 
> done getUserMedia with a constraint specifying that camera ID.
>
> <proposal ends>
>
> The interface is on MediaStreamTrack, which allows video and audio 
> sources to be retrieved in a single call, and also allows additional 
> types of source with no API change, if that ever becomes needed. It’s 
> also easily extensible to allow other kinds of information to be returned, if desired.
>
> For reference, here’s the description of “label” from the 
> MediaStreamTrack
> section:
>
> label of type DOMString, readonly
> User agents may label audio and video sources (e.g., "Internal microphone"
> or "External USB Webcam"). The MediaStreamTrack.label attribute must 
> return the label of the object’s corresponding track, if any. If the 
> corresponding track has or had no label, the attribute must instead 
> return the empty string.
>
> )
>
> (Note - section 3 of this spec version has some discussion on when the 
> source is released to the application. This proposal only says that 
> this also releases the label to view.)
>
> This extension will allow:
> - Untrusted applications to quickly determine whether a camera is 
> present or not (satisfies the “does it make sense to offer video 
> calling” requirement)
> - Trusted applications to create in-app UI that presents a sensible 
> list of devices for the user to choose between
> - A clear definition of going from “untrusted” to “trusted”
>
> Note: It may make sense to have the in-chrome user permission prompt 
> give
> alternatives:
> - “give access to all my cameras”
> - “give access to one specific camera”
> - “deny access”
> It’s an UI design decision whether or not all these need to be 
> offered; this shouldn’t be in the spec.
>
>
>
>

Received on Thursday, 21 March 2013 19:24:24 UTC