The security review concluded last week. The change to enable this by default has landed, and will be available starting in M130: https://chromium.googlesource.com/chromium/src.git/+/1f5f2853635ab7a43d3507f02e1de903d2703019
Thank you! On Thu, Aug 15, 2024 at 12:26 PM Thomas Guilbert <tguilb...@google.com> wrote: > Thank you all! I will wait on the security review to finish, and will turn > on the feature by default on M130. > > > Do you know if there's any effort to merge this monkey patch into the > base specification? > There was none that I knew of, so I opened an issue > <https://github.com/w3c/webrtc-pc/issues/2986> to start a discussion. > Thanks for the suggestion! > > On Thu, Aug 15, 2024 at 11:55 AM Vladimir Levin <vmp...@chromium.org> > wrote: > >> LGTM3 >> >> On Thu, Aug 15, 2024 at 12:11 AM Domenic Denicola <dome...@chromium.org> >> wrote: >> >>> LGTM2. >>> >>> On Fri, Aug 9, 2024 at 8:22 AM Thomas Guilbert <tguilb...@chromium.org> >>> wrote: >>> >>>> Contact emailstguilb...@chromium.org >>>> >>>> ExplainerNone >>>> >>>> Specification >>>> https://w3c.github.io/webrtc-extensions/#rtcdatachannel-transferable >>>> >>> >>> This is a fine specification for shipping the feature. But it's a bit >>> sad that it's a monkey patch specification >>> <https://annevankesteren.nl/2014/02/monkey-patch> for a feature that it >>> sounds like everyone agrees on. >>> >>> The Web RTC Extensions specification says "As extensions mature and gain >>> implementation experience, they may move from this document to the base >>> specification if WG consensus emerges to do so." Do you know if there's any >>> effort to merge this monkey patch into the base specification? >>> >>> >>>> >>>> >>>> Summary >>>> >>>> The RTCDataChannel interface is part of the WebRTC standard, and >>>> represents a network channel which can be used for bidirectional >>>> peer-to-peer transfers of arbitrary data. This feature tracks exposing >>>> RTCDataChannel in dedicated workers, and allowing the transfer of >>>> RTCDataChannels to them workers. This will help reduce main thread >>>> contention and lead to smoother and more reliable WebRTC applications. >>>> >>>> >>>> Blink componentBlink>WebRTC>DataChannel >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebRTC%3EDataChannel> >>>> >>>> TAG reviewNone >>>> >>>> TAG review statusNot applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> There is an interoperability risk when it comes to which types of >>>> workers are supported by which browser. - Safari/WebKit supports transfers >>>> to DedicatedWorkers and to ServiceWorkers. - Chromium is only looking to >>>> add transfers to DedicatedWorkers; supporting transfers to ServiceWorkers >>>> would require significant architectural changes (across processes, rather >>>> than across threads) and might never be supported. - Firefox/Gecko supports >>>> neither, but might support transfers to both DedicatedWorkers and >>>> ServiceWorkers, if/when they choose to support this feature. Regardless of >>>> whether or not Chromium supports transfers to ServiceWorkers, enabling >>>> transfers to DedicatedWorkers addresses current developer needs, and >>>> improves interoperability. >>>> >>>> >>>> *Gecko*: No signal ( >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1209163) Mozilla is aware >>>> of the issue, but has not allocated resources to it as of yet. >>>> >>>> *WebKit*: Shipped/Shipping ( >>>> https://bugs.webkit.org/show_bug.cgi?id=222965) >>>> >>>> *Web developers*: Positive This has been a longstanding request from >>>> developers. E.g: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1209163#c4 >>>> https://issues.chromium.org/issues/40787712#comment21 >>>> >>>> *Other signals*: >>>> >>>> Ergonomics >>>> >>>> This feature improves the ergonomics of existing Worker exposed APIs. >>>> For example, it allows developers to use WebCodecs and Offscreen canvas >>>> from workers, without having to repeatedly transfer data from the main >>>> thread. >>>> >>>> >>>> Activation >>>> >>>> N/A >>>> >>>> >>>> Security >>>> >>>> This feature should not introduce any new security risks. Existing >>>> risks can be found in the WebRTC API specification: >>>> https://w3c.github.io/webrtc-pc/#privacy-and-security-considerations >>>> >>>> >>>> WebView application risks >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> >>>> None >>>> >>>> >>>> Debuggability >>>> >>>> N/A >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?Yes >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ?Yes >>>> >>>> DedicatedWorkers: >>>> https://wpt.fyi/results/webrtc-extensions/transfer-datachannel.html?label=experimental&label=master&aligned >>>> ServiceWorkers (out of scope for this feature): >>>> https://wpt.fyi/results/webrtc-extensions/transfer-datachannel-service-worker.https.html?label=experimental&label=master&aligned >>>> >>>> >>>> Flag name on chrome://flagsNone >>>> >>>> Finch feature nameTransferableRTCDataChannel >>>> >>>> Requires code in //chrome?False >>>> >>>> Sample links >>>> https://tguilbert-google.github.io/RTCDataChannel/index.html >>>> >>>> Estimated milestones >>>> Shipping on desktop 130 >>>> DevTrial on desktop 129 >>>> Shipping on Android 130 >>>> DevTrial on Android 129 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> None >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/6612726584180736?gate=4885503741263872 >>>> >>>> Links to previous Intent discussionsIntent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dab53bcd-e51d-41bc-a312-4bd3e08322f0n%40chromium.org >>>> >>>> >>>> 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/CABrVPoba%2B6EuYDdfxKF8ZXn%3DXmzt6vd1tZ53yTS9-CEdUBXTzw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABrVPoba%2B6EuYDdfxKF8ZXn%3DXmzt6vd1tZ53yTS9-CEdUBXTzw%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/CAM0wra_MUXCsrpODkCarYj%3DY7%2BDipq0mX_dcY44auGzV-QZ7Qw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_MUXCsrpODkCarYj%3DY7%2BDipq0mX_dcY44auGzV-QZ7Qw%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/CABrVPoYdL8OXCuAeL3EfaSYCnOmTW-yK0ZTQKgAqFF1wLhB8Qw%40mail.gmail.com.
