Re: Proposed new text for noaccess

On 11/6/2013 4:43 AM, Stefan Håkansson LK wrote:
> On 05/11/13 22:36, Jan-Ivar Bruaroey wrote:
>> On 11/5/13 2:11 PM, Stefan Håkansson LK wrote:
>>> On 05/11/13 17:39, Jan-Ivar Bruaroey wrote:
>>>>            And this would depend on /browser settings/ and user comfort
>>>>            level (let browsers handle defaults here).
>>>>
>>>>     3. If stream is 'noaccess' then stay here. If app ever lifts
>>>>        'noaccess', goto 4.
>>>>     4. If browser ever returns that user-consent has been granted, then
>>>>        unmute/promote stream to full access.
>>> I sort of like this. If it also came with the info that also a
>>> "noaccess" MediaStream can be attached to a PeerConnection (but would
>>> never let any RTP packets, or only silence/black-RTP, go out on the net)
>>> it could be used to get the negotiation going immediately (since gUM
>>> returns quickly).
>> Exactly, it takes permissions out of setup.
> Thinking a bit more about this: it would work fine when the user returns
> (using the same HW) since the app can do gUM with sourceId - and the UA
> could go ahead and return a MS immediately (and that MS could be used to
> start negotiation).

Yes, repeat visits would be fast, which is good. Browsers could possibly 
even do this without sourceId, by remembering sites you've shared with 
before, since the information leakage is minimal in this case, even if 
repeat-visit consent hasn't been given.

> But the first time the user is at a site, isn't there a two stage thing
> with this model: first select _which_ camera (as Harald has pointed out
> there it may be difficult to start negotiating before the device is
> known), and second the user would have to grant access to it.

I wrote a about these tradeoffs before 
http://lists.w3.org/Archives/Public/public-media-capture/2013Sep/0095.html 
- Martin responded he thought the problems were overstated, so perhaps I 
can summon him again here.

> I guess the result would that the first time at a site gUM would not
> return (unless the UA magically knows which devices to use without user
> involvement) until the user has been involved.

That might work, though I suspect Harald and Martin are hoping to 
replace getUserMedia with something synchronous if we do this.

As to "UA magic", I'm sure the UA could guess right most of the time, 
but we can't leak the device information yet, right?

To re-summarize what I linked to, I think users will only perceive any 
delay *after* they consent, so as long as re-negotiating is faster than 
cold negotiation then there might be a win even on initial visit (the 
browsers can exchange candidates rather than twiddling thumbs while 
their users answer their respective permission dialogs).

> Stefan
>> .: Jan-Ivar :.

Received on Wednesday, 6 November 2013 22:30:51 UTC