search

w3c / mediacapture-fromelement

API to create a MediaStream from Media Element
https://w3c.github.io/mediacapture-fromelement
Other
21 stars 15 forks source link

Inconsistency: Taint, not mute cross-origin element tracks #83

Open jan-ivar opened 4 years ago

jan-ivar commented 4 years ago

It seem clear from §5. Security Considerations element capture expressly supports tainted tracks: "Media elements can render media resources from origins that differ from the origin of the media element. In those cases, the contents of the resulting MediaStreamTrack MUST be protected from access by the document origin.

How this protection manifests will differ, depending on how the content is accessed. For instance, rendering inaccessible video to a canvas element [2DCONTEXT] causes the origin-clean property of the canvas to become false; attempting to create a Web Audio MediaStreamAudioSourceNode [WEBAUDIO] succeeds, but produces no information to the document origin (that is, only silence is transmitted into the audio context); attempting to transfer the media using WebRTC [WEBRTC] results in no information being transmitted. "

Closed issues like https://github.com/w3c/mediacapture-fromelement/issues/70 also support this reading.

However, HTMLMediaElement's captureStream algorithm appears to suggest implementations should mute rather than taint output: "At any time, a media element might not have active content available for capture on a given track for a variety of reasons: ... 4. The contents of the track might become inaccessible to the current origin due to cross-origin protections. ... Absence of content is reflected in captured tracks through the muted attribute. A captured MediaStreamTrack MUST have a muted attribute set to true if its corresponding source track does not have available and accessible content."

Muting seems like a mistake, contradicts §5, and AFAIK nobody implements this.

Firefox taints the track correctly, and Chrome used to.

cc @martinthomson

youennf commented 3 years ago

What is the usecase for tainting the track instead of muting the track?

martinthomson commented 3 years ago

Muting a track stops the flow of media. Tainting allows the track to continue to display, if it is being fed to <audio> or a visible <video>.

youennf commented 3 years ago

Understood but what is the actual usecase? Let's say there is a media element that is tainted and a tainted MediaStreamTrack is created from it. The first question is what can be done with this tainted MediaStreamTrack that cannot be done with the media element (or reasonably shimed using JS). The second question is whether these potential new capabilities are worth the cost and effort of introducing the concept of tainted tracks (and having to handle tainted tracks in all sinks).

dontcallmedom-bot commented 3 months ago

This issue was mentioned in WEBRTCWG-2024-03-26 (Page 29)