Re: Proposed new text for noaccess

On Sun, Oct 27, 2013 at 4:20 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

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

Hmmm...I think a lot of this follows directly from the constraint model,
so I'm reluctant to describe it for this particular constraint and not
others.



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


No, because that's the content of the stream.



> Can you clone?
>

Yes, because you're just manipulating the handle.



> * It is also unclear if you can change an existing track from "noaccess"
> to normal (or vice versa).


Yes, because it's a constraint.


And if that is done, what will happen with
> illegal consumers?
>

That's what the discussion upthread between Harald, Martin, and I is
partly about.



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

It's a constraint, so at any time.



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

It's a constraint, so however constraints behave.



> * 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).


Sure. I think it would be easier here.
I propose "Streams with noaccess constraint may not be added
to RTCPeerConnections. Any attempt to do so so results in
X" where X is the outcome of the upthread discussion.

-Ekr



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