Re: Proposed new text for noaccess

To me (and that perhaps says more about my lack of competence than this 
text) a lot is still unclear:

* I think we need to elaborate a bit more of what "accessible to the 
content JS" means. Can you record (presumably not)? Can you clone?

* It is also unclear if you can change an existing track from "noaccess" 
to normal (or vice versa). And if that is done, what will happen with 
illegal consumers?

* Also unclear is when you can define "noaccess". Is it at gUM? Or at 
any time?

* Should there be any way for the app to check if a stream/track is 
"noaccess/identiTY"?

* From the text below I understand that a "noaccess" stream/track can 
_not_ be sent over a PeerConnection. That should probably be said 
clearly (perhaps in the WebRTC draft).

Stefan

On 26/10/13 16:37, Eric Rescorla 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 Sunday, 27 October 2013 11:35:26 UTC