- From: Eric Rescorla <ekr@rtfm.com>
- Date: Sat, 26 Oct 2013 07:35:40 -0700
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Received on Saturday, 26 October 2013 14:36:48 UTC
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 14:36:48 UTC