Can we have non-origin-clean MediaStreamTracks?

[alvestrand]

In resolving #2390, we started discussing whether there can be origin-unclean MediaStreamTracks, meaning that we need to have language on how to handle this.

[youennf]

https://w3c.github.io/mediacapture-fromelement/#dom-htmlcanvaselement-capturestream is pretty clear for canvas capture stream. "Content from a canvas that is not origin-clean MUST NOT be captured."

The wording is less clear from video element tracks: "The contents of the track might become inaccessible to the current origin due to cross-origin protections". My interpretation is that content should never hit the consumer, be it web audio or peer connection.

Maybe the scenario is to introduce "trusted consumers" like the video element that would be able to get access to that content, other consumers never getting anything.

[alvestrand]

The needed modification is to modify PR #2390 to not remove the language that deals with non-origin-clean tracks.

[youennf]

I updated https://github.com/w3c/webrtc-pc/pull/2390 to leave some of the text.

It seems the only case that could have cross origin MediaStreamTrack is video element capture. It seems best for the video element capture to define how these tracks should behave (i.e. do not provide content except to video elements).

This is already done in https://w3c.github.io/mediacapture-fromelement/#security-considerations: "attempting to transfer the media using WebRTC [WEBRTC] results in no information being transmitted".

I would prefer we tighten the wording there instead of webrtc-pc (current webrtc-pc wording is vague and difficult to understand without context). FWIW, WebAudio is not defining anything special here, this seems fine to me.

[jan-ivar]

It seems out-of place to discuss WebRTC in from-element. We also don't want to update fromelement every time a new sink is added. Case in point: it omits discussing MediaRecorder.

I think we should define somewhere that MediaStreamTracks may or may not be origin-clean, and decree that specs defining new sinks must discuss what to do when handed one.

The oldest open issue in mediacapture-main is about this https://github.com/w3c/mediacapture-main/issues/529#issuecomment-412447137.

I think we've hesitated putting it there in the past, since camera and microphone streams are inherently clean, but this is also the "main" spec that defines MediaStreamTrack, so perhaps it belongs there. It would make a good place to link to.

[henbos]

This quote is there for addTrack, we should probably add it to addTransceiver as well or move it to some section that talks about any tracks

A track could have contents that are inaccessible to the application. This can be due to anything that would make a track CORS cross-origin. These tracks can be supplied to the addTrack() method, and have an RTCRtpSender created for them, but content MUST NOT be transmitted. Silence (audio), black frames (video) or equivalently absent content is sent in place of track content.

Note that this property can change over time.