- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Mon, 3 Jun 2013 14:14:37 +0200
- To: robert@ocallahan.org
- CC: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, Jim Barnett <Jim.Barnett@genesyslab.com>, Martin Thomson <martin.thomson@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 2013-06-03 09:51, Robert O'Callahan wrote: > On Mon, Jun 3, 2013 at 6:15 PM, Adam Bergkvist > <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote: > > But the key idea is still that all new tracks that the user agent > adds (local in the gUM() case, and remote in the PeerConnection > case) have the same origin so the stream would never change origin. > > > I'm not up to date on the latest thinking on the WebRTC security model > but this might not be the case for PeerConnection. Imagine if you get a > gUM track with origin A and add it to a PeerConnection. The remote > machine sees a MediaStream with a track with origin A. Then later the > local machine gets a PeerConnection track with origin B and adds it to > the MediaStream feeding into the PeerConnection. Now the remote machine > sees its MediaStream get a new track added with origin B. Yes, you're right. It may be too limiting (use case-wise) to only expect one origin from a remote peer. /Adam
Received on Monday, 3 June 2013 12:15:03 UTC