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 <https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers>. 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 <a...@google.com> -mike On Wed, Jan 19, 2022 at 5:07 PM 'Tony Herre' via blink-dev < blink-dev@chromium.org> wrote: > Contact emailshe...@google.com, h...@chromium.org > > ExplainerNone > > 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 componentBlink>MediaStream > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EMediaStream> > > 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 statusNot 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ?No > > Flag name > > Requires code in //chrome?False > > Tracking bughttps://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 > <https://chromestatus.com/>. > > -- > 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+unsubscr...@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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAArnMxEAdAdKs-T5o_TWCnvXpWEXiXDvpoxz_zpwADn%2BpyBwEA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeJuNyf2P8EdtuUONouqCG6bL-7PKi_z2iBVqjxkvXqXg%40mail.gmail.com.
