W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: Proposed new text for noaccess

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 5 Nov 2013 19:27:25 +0000
To: Harald Alvestrand <harald@alvestrand.no>, Martin Thomson <martin.thomson@gmail.com>, Jan-Ivar Bruaroey <jib@mozilla.com>
CC: Eric Rescorla <ekr@rtfm.com>, "Mandyam, Giridhar" <mandyam@quicinc.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3D2C08@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC