- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 12 Jun 2013 12:12:12 +0200
- To: public-webrtc@w3.org
On 2013-06-12 11:55, Harald Alvestrand wrote: > Finally getting a round tuit.... picking up this thread from May 7. > > I think this proposal is fine, and we should just add it. I have some issues with the proposal (see further below); but we could add it as is to the document and then change (depending on where my comments lead). > > One question I have is about the value of "noaccess" in the context of > PeerConnection. > Given that any page can set up two PeerConnections and connect them to > each other, it seems to me a bit strange that one has a stream that can > be easily "whitewashed" by the application marked "noaccess"; a > restriction that can be easily bypassed seems like either a false sense > of security or just additional baggage. > > It would make more sense to me if "noaccess" permitted addition to NO > PeerConnection, just display; it would chiefly be useful for debugging > the access control and in local applications. > (Perhaps it could allow recording?) I think it should definitely _not_ allow recording. > > > > > On 05/07/2013 04:58 PM, Eric Rescorla wrote: >> Given that the document is still in flux, I am providing raw >> text and I leave it to the editors to figure out how to >> integrate the text. I'd be happy to help with that if the >> editors want. >> >> Martin and I have been discussing >> privately what the best UX is for the relevant identity >> indications. I've tried to capture the normative requirements >> below. Seeing as we're having trouble converging on the >> gUM UI, I think it's best if we don't provide too much >> non-normative guidance for now. >> >> >> TEXT I BELIEVE BELONGS IN MEDIASTREAMS >> 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. An isolated media stream >> may be used for two purposes: It seems that "media stream" is used with the same meaning as MediaStreamTrack - but we should be precise. >> >> - 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. >> >> - Used as the argument to addStream() for a PeerConnection, subject >> to the restrictions detailed in the WebRTC document. >> >> >> When the noaccess=true constraint applies to a track, that track >> may be added to any PeerConnection. Again, if we talk about "track", then it can't be added to a PeerConnection (but possibly to an existing MediaStream). And I assume you mean it could be added to one PeerConnection (if it could be added to several PC's simultaneously there is no gain!). To me it seems that we should be * talking about isolated MediaStreams - splitting it down on Tracks would be to confusing * that the right way to get an isolated MediaStream would be to ask gUM to create one * if the app creates an isolated MediaStream (using gUM) all other MediaStream's that are sourced by local devices should immediately end (otherwise I don't see what we gain with isolated MediaStreams or MediaStreamTracks - there is nothing the UA could tell the user regaring privacy if one MediaStream is isolated by five other aren't) //Stefan >> >> When the peerIdentity=<foo> constraint applies to a track, then >> that track may be added only to PeerConnections with compatible >> peer identities as described in Section XXX of [REF]. >> >> Both the noaccess and peerIdentity constraints must be mandatory. >> Any use of them in the optional block must trigger an error. >> >> >> TEXT I BELIEVE BELONGS IN WEBRTC >> Tracks which are tagged with the peerIdentity constraint must be >> handled as follows: >> >> 1. If the track is added to a PeerConnection which is in a >> disconnected state, the track is added successfully >> (subject to other restrictions). >> >> 2. If the track is added to a PeerConnection which is in >> a connected state: >> >> (a) If the connected peer has no identity or has an >> identity which is inconsistent with the peerIdentity >> constraint, then the error callback must be called >> with a TBD error. >> >> (b) If the connected peer has an identity which is equal >> to the peerIdentity constraint, then the track is >> added successfully (subject to other restrictions). >> >> 3. When a PeerConnection transitions from an disconnected >> state to a connected state or changes the peer identity, >> then the following checks must be performed: >> >> If any tracks on the PeerConnection have a peerIdentity >> constraint and either the PeerConnection connection has >> no peer identity or that identity is not equal to the specified >> peerIdentity, then the connection must be terminated >> with an error of [TBD: when we actually specify some >> run-time errors.] Media must not be transmitted to the >> other side in this case. >> >> 4. The identity mechanism MUST provide an indication to the remote >> side of the type of stream (ordinary, peerIdentity, noaccess) it is >> associated with. This is a requirement on the IETF specification. >> Implementations MUST display different identity UI in these >> cases. >> >> 5. If an incoming stream is associated with an identity assertion, >> implementations SHOULD still allow sites access to the stream >> (i.e., they should not taint it) but MUST NOT display the browser >> chrome identity indications if the site maps it onto a modifiable >> or viewable object. If the site performs such a mapping after >> the chrome indications have been displayed, the browser >> MUST change the identity indicators appropriately and MAY wish >> to ask for user consent prior to allowing the mapping. >> -Ekr >> >> > >
Received on Wednesday, 12 June 2013 10:12:36 UTC