W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

Re: Proposed new text for noaccess

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 26 Oct 2013 08:35:05 -0700
Message-ID: <CABcZeBMhycK+cJ7ym41Xy5mgy-Mp+G02hQTU-rUpyaDsbrt0Mg@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Stefan points out that we need language for what happens if you add
a noaccess stream to a PC. I suggest:

"If any tracks in a MediaStream added via AddStream() have a noaccess
the implementation MUST throw an exception of XXX" (I am still a little
vague on
how we have decided to do exceptions.

On Sat, Oct 26, 2013 at 7:35 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Harald pointed out that the noaccess text doesn't really work the way we
> had in mind. Here
> is my proposed new text. Note that the last paragraph is something we
> haven't discussed
> in detail, but I think is the right thing for what we want here.
> When either the "noaccess" or "peerIdentity" constraints is applied to
> a MediaStreamTrack, the track shall be isolated so that its content is
> not accessible to the content JS. Either type of stream may be
> Displayed in an appropriate tag (e.g., a video or audio element). The
> video element must have a unique origin so that it is inaccessible to
> the content JS. This is the same security mechanism as is used with an
> ordinary audio or video element which has a src= property from a
> separate origin.
> A stream with the peerIdentity constraint may also be used as the
> argument to addStream() for a PeerConnection, subject to the
> restrictions detailed in the WebRTC document.
> Browser implementations MAY choose to allow creation of "noaccess"
> streams without an explicit permission prompt to the user. This allows
> a mode where the JS does a "hair check" dialog for device selection
> and then prompts the user prior to actually initiating the call by
> re-setting the constraints.
> -Ekr
Received on Saturday, 26 October 2013 15:36:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC