Re: Proposal: Explicit "Get access to media" call

On 09/06/2013 06:20 PM, Jan-Ivar Bruaroey wrote:
> Have we considered returning a stream with muted tracks until
> permission is given instead?

We have considered it. The problem is that until permission is given,
the track does not have enough information to start negotiating
connections, and indeed to do much of anything with it - because we
can't negotiate the properties of the connection until we know something
about the stream that will be connected to it.

Instead of speeding things up, it would slow things down - because when
we finally know the properties of the device, we have to re-negotiate.

The parts we can do without knowing the device, such as getting
candidates assigned and initial DTLS handshakes out of the way, are the
same things we can do without adding a track to the connection at all.

> - Given that we'll need to mute tracks on/off in response to
> over-constrained situations caused by live constraint-changes anyways,
> this seems like a fit.
>
> This decoupling should speed up many calls by letting connections
> establish without blocking on the user answering the (somewhat
> unrelated) gUM permission prompt. (e.g. it would speed up all calls in
> Firefox because it doesn't implement persistent permissions, and all
> new calls in Chrome).
>
> With this "Assume Success" pattern, webpages that don't want the
> overhead (e.g. because listen-only is common) can of course initiate
> the call without gUM, and maybe (someday hopefully) addStream later
> during the call.
>
> With calls no longer blocked by permissions, bundling permission
> requests seems as easy as waiting a sub-second to aggregate tag-along
> requests.
>
> If we can work out the ramifications on the outgoing SDP, I see a
> design-win here:
>
> A decoupling avoids conflating the permission question with "start
> call", and seems to fit better with the experience users expect:
>
> The current conflation is unfortunate because it looks to users like
> permission is required to make any call at all, which is often untrue,
> but the choice to proceed without video is hidden! (when's the last
> time something fun happened after pressing "Deny"?)
>
> I know, lazy webpage, but I experienced this myself a few weeks ago
> when I tried to dogfood webrtc to dial into an IETF meeting... I
> balked at the gUM prompt and ended up instead using the less dangerous
> flash version which didn't ask anything of me (hey, it was 3 am, I was
> not appropriately dressed, and I was sleepy ok?)

That is an app/permissions interaction failure, in my opinion; if you
wanted to view the stream, not interact with the stream, the application
should not have opened your camera.

>
> .: Jan-Ivar :.
>
> On 8/29/13 2:24 PM, Rachel Blum wrote:
>> At some point the DAP WG was working on a unified permissions thingy
>> - http://dev.w3.org/2009/dap/perms/FeaturePermissions.html
>>
>> They discontinued it because there wasn't a clear use case outside of
>> notifications, but it might be worth looking at.
>>
>>  - rachel
>>
>>
>> On Thu, Aug 29, 2013 at 7:09 AM, Stefan Håkansson LK
>> <stefan.lk.hakansson@ericsson.com
>> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>>
>>     I think something along these lines could be the right thing to
>>     do. The
>>     dual role of getUserMedia is not ideal.
>>
>>     On 2013-08-29 14:38, Harald Alvestrand wrote:
>>     > One of the problems with the current method of getting access
>>     to media
>>     > is that it occurs as a side effect of a call done for other
>>     purposes
>>     > (GetUserMedia).
>>     >
>>     > The parameters for this aren't ideal to determine the full range of
>>     > permissions that a page would want - for instance, a page might
>>     first
>>     > open a video device, and later open an audio device separately;
>>     in our
>>     > current models, that would give 2 permissions prompts.
>>     >
>>     > Instead of doing it this way, we could make an explicit call:
>>     >
>>     > void GetMediaPermissions(Permissions permissions,
>>     >                              successCallback, errorCallback)
>>     >
>>     > Permissions = enum(
>>     >    "videoInputDevices",
>>     >    "audioInputDevices",
>>     >    // and maybe extend this to
>>     >    "deviceEnumeration",
>>     >    "screenCapture",
>>     >    "windowCapture",
>>     >    ....
>>     > )
>>     >
>>     > The UA could then use the list of permissions requested to
>>     construct an
>>     > appropriate UI element for asking permission from the user (or
>>     use a
>>     > stored permissions model to grant access immediately, if that's the
>>     > Right Thing).
>>     > In any case, all programs that know what class of permissions
>>     they want
>>     > can get those permissions with one call, one prompt, no matter
>>     what they
>>     > do later.
>>     >
>>     > For backwards compatibility, getUserMedia would be documented
>>     to have an
>>     > implicit call to GetMediaPermissions "behind the curtains".
>>     >
>>     > Does this make more sense?
>>     >
>>     > Harald
>>
>


-- 
Surveillance is pervasive. Go Dark.