Intent to Prototype: Transferable MediaStreamTracks

[Tony Herre]

Contact emails

he...@google.com, h...@chromium.org

Explainer

None

Specification

https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack

Summary

Expose MediaStreamTracks in Workers and allow them to be transferred between contexts. Allowing this transfer makes it easier to access and process media in contexts other that where it was created, eg in Workers or other documents.

Blink component

Blink>MediaStream

Motivation

Having transferable MediaStreamTracks allows much more flexibility for architecting web applications which have multiple windows which each wish to contribute video or audio tracks to a single WebRTC conference, without having to have independent competing network connections via PeerConnection. This also allows transferring all media processing to a separate context eg a worker, rather than mediating control signals through the window.

Initial public proposal

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

Positive in WebRTC Working Group discussions

WebKit: No signal
Positive in WebRTC Working Group discussions

Web developers: No signals

Other signals:

Debuggability

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1288839

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5747241384935424

This intent message was generated by Chrome Platform Status.

[Mike West]

Hey Tony!

My understanding of the transfer mechanism is that the transferring context loses control of the stream, handing it off to the receiving context. The stream source remains with the original context, however, and I'm wondering whether that provides an opportunity for replicating the timing attacks that SharedArrayBuffers enabled. Given the ability to clone streams, it seems possible for a source in one context to be writeable in one context, and readable from multiple contexts.

Have y'all thought about that potential threat? Is it actually a risk, or have I missed things? :)

/cc +Artur Janc

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxEAdAdKs-T5o_TWCnvXpWEXiXDvpoxz_zpwADn%2BpyBwEA%40mail.gmail.com.

[Kamila Hasanbega]

Hey Tony,

Can you please confirm that if the target context is destroyed, or calls MediaStreamTrack.stop(), that will stop the source, unless other MediaStreamTrack objects depend on it, just like in the non-transferred case. See: https://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack-stop

In addition, please provide a practical example where it makes sense to pass the track between cross-origin windows.

- Kamila 

On Tuesday, January 25, 2022 at 10:52:38 AM UTC+1 Mike West wrote:

Hey Tony!

My understanding of the transfer mechanism is that the transferring context loses control of the stream, handing it off to the receiving context. The stream source remains with the original context, however, and I'm wondering whether that provides an opportunity for replicating the timing attacks that SharedArrayBuffers enabled. Given the ability to clone streams, it seems possible for a source in one context to be writeable in one context, and readable from multiple contexts.

Have y'all thought about that potential threat? Is it actually a risk, or have I missed things? :)

/cc +Artur Janc

-mike

On Wed, Jan 19, 2022 at 5:07 PM 'Tony Herre' via blink-dev <blin...@chromium.org> wrote:

Contact emails

he...@google.com, hta@chromium.org

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.