Re: Proposed new text for noaccess

On 05/11/13 20:14, Harald Alvestrand wrote:
> On 11/05/2013 07:54 PM, Martin Thomson wrote:
>> On 5 November 2013 08:38, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>>> In my mind, a 'noaccess' stream and a stream awaiting user-permissions are
>>> similar and could work the same:
>> I'm thinking now that offering the ability to construct streams and
>> tracks attached to any source, without user interaction, is going to
>> work.  That would have to cause the tracks to gain the properties of a
>> "noaccess" track.  At that point, I agree that the UA can render (or
>> not) those streams however it chooses.  gUM is used to elevate access
>> to peeridentity or unconstrained.
>
> This is tempting .... just saying that grabbing a stream gives you a
> black stream until permission is given. But I think we'd also have to
> put some kind of event or callback on the stream so that JS could know
> that permission was granted.

Perhaps this could be a simple as using the "unmute" event - a track 
would be muted until consent is given.

> Showing the user black when the user
> expects a face is a bad user experience.
>
> BTW, I'll repeat what I said before in another context: if we change
> getUserMedia's behaviour, I'd much prefer to see a new call that is NOT
> called getUserMedia, and a short Javascript snippet that shows how to
> emulate getUserMedia on top of the new function (which has a new name).
>
>
>>
>> With respect to the light coming on, I note that Firefox offers a way
>> to revoke access to plugins on pages.  Maybe that shows that there is
>> a way out here.  If you don't like the light coming on when you visit
>> google.com, revoke access when it first happens and never see it
>> again.
>>
>> BTW, I didn't find your other email.  Archive links are far more
>> reliable than times.  That said, I don't think that any of the options
>> offered ended up with double-permissions-dialog problems.
>
>

Received on Tuesday, 5 November 2013 19:27:49 UTC