Re: Proposed new text for noaccess

On 27/10/13 15:28, Eric Rescorla wrote:
>
>
>
> On Sun, Oct 27, 2013 at 4:20 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto: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.

OK. But I still think we should define ""accessible to the content JS".

Similarly we mix talking about "noaccess/identity" being associated with 
a MediaStream and a MediaStreamTrack, that is something we also need to 
define.

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

Yes, but that discussion deals with the case when a stream/track is on 
type noaccess when added to PeerConnection, not what happens if it 
changes while in operation. (And we have the same case for the Recorder 
and Image Capture BTW).

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

OK, then it can check.

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

Received on Monday, 28 October 2013 09:22:55 UTC