Re: Proposed new text for noaccess

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
constraint,
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
>
>
>