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:05:45 UTC