LGTM2 On Wed, Oct 21, 2026 at 8:19 AM Alex Russell <[email protected]> wrote:
> Thanks Omar, > > LGTM1 > > On Tuesday, October 20, 2026 at 6:28:37 AM UTC-7 [email protected] > wrote: > >> Hi Alex, >> >> The benefit is that SSM makes the multicast API usable beyond a single >> LAN. Multicast that crosses network boundaries is SSM in practice: >> - RFC 8815 deprecates inter-domain ASM. >> - ISP and enterprise deployments carry channels in the SSM ranges (232/8, >> FF3x::/32), where routers only forward source-specific joins (RFC 4607). >> - AMT relays (RFC 7450) serve (S,G) channels. >> That is the TreeDN model (RFC 9706): native multicast where the network >> supports it and AMT relays everywhere else. Lenny Giuliano's introduction: >> https://community.juniper.net/blogs/lenny/2025/08/21/introduction-to-TreeDN >> An ASM-only IWA can't receive those channels off its LAN. Its only >> workaround is an AMT gateway written in JS over unicast UDP, which needs a >> relay and gives up native delivery on networks that support it. >> >> Who's asking: >> >> 1. My company, Blockcast. We built that workaround, and this intent lets >> us drop it on native networks. >> - Our Chrome extension, Multicast Gateway (BEACON), gives pages a small >> window.multicast API: >> https://chromewebstore.google.com/detail/multicast-gateway-beacon/djikmiecejmojgcglkfmihhkfgekjlaj >> - The sockets live in our IWA, which uses Direct Sockets and only serves >> sites the user has allowed (an exact-origin allowlist). Pages get multicast >> only through components the user installed: >> >> const sub = await window.multicast.subscribe({ >> group: '232.1.1.50', port: 8000, >> source: '192.0.2.10', // SSM; omit for ASM >> consume: 'bytes', >> }); >> sub.addEventListener('bytes', (e) => handle(e.detail)); // one >> ArrayBuffer per datagram >> >> - Each subscription is delivered natively or through an AMT relay. The >> native SSM case is a direct call to MulticastController.joinGroup(group, { >> sourceAddress }), which is what this intent ships. Outside the dev trial >> that option is dropped and the join silently becomes any-source, so today >> our users beyond the LAN need the AMT path. >> - Public demo: https://blockcast.network/live compares a live ISS camera >> feed in the browser over QUIC, ROUTE, AMT and native multicast. The AMT and >> native multicast choices appear once the extension and IWA are installed. >> >> 2. The IETF MBONED community. Browser multicast drew a lot of interest at >> IETF 126 in July (minutes: >> https://datatracker.ietf.org/doc/minutes-126-mboned-202607211430/): >> - QUICast (https://quicast.de/) showed a modified Firefox receiving >> multicast natively beneath WebTransport, without an IWA. >> - Aircast reported live-event deployments over multicast and AMT, >> including Wimbledon. >> - Chris Needham of the BBC and W3C board of directors offered to help >> coordinate a browser multicast API in W3C. >> >> 3. Other signals: >> - On the proposal (#80), Harald Alvestrand recommended SSM as the only >> safe model beyond the local network. >> - Node.js dgram already exposes the same capability >> (addSourceSpecificMembership). >> - Jake Holland's Multicast Receiver API explainer is SSM-only for the >> same reason: >> https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md >> Outside this community, the Ready for Trial thread got no replies. >> >> A larger discussion with W3C about multicast on the web is still needed, >> including how IWAs will roll out: today the install UX isn't great and >> there's no mobile support. But this is an exciting first step, and a small >> one: an optional sourceAddress on joinGroup()/leaveGroup(), mapped to >> MCAST_JOIN_SOURCE_GROUP, with no new permission or prompt. >> >> Thanks, >> Omar >> >> On Tue, Oct 20, 2026 at 1:48 AM Alex Russell <[email protected]> >> wrote: >> >>> What's the developer benefit for SSM? Is anyone asking for this? >>> >>> Best, >>> >>> Alex >>> >>> On Monday, October 19, 2026 at 1:57:36 PM UTC-7 Reilly Grant wrote: >>> >>>> IWA OWNER LGTM >>>> >>>> This is an extension to an extension of an existing IWA-only API. The >>>> previous justification for why multicast would create a privacy issues for >>>> the web platform (see also threads on net-dev@) still applies. >>>> Reilly Grant | Software Engineer | [email protected] | Google Chrome >>>> <https://www.google.com/chrome> >>>> >>>> >>>> On Wed, Oct 14, 2026 at 7:43 PM Chromestatus < >>>> [email protected]> wrote: >>>> >>>>> *Contact emails* >>>>> [email protected] >>>>> >>>>> *Explainer* >>>>> >>>>> https://github.com/WICG/direct-sockets/blob/main/docs/multicast-explainer.md >>>>> >>>>> *Specification* >>>>> >>>>> https://wicg.github.io/direct-sockets/#dom-multicastgroupoptions-sourceaddress >>>>> >>>>> *Summary* >>>>> Adds Source-Specific Multicast (SSM) support to the Direct Sockets >>>>> API, allowing Isolated Web Apps to optionally specify a source address >>>>> when >>>>> joining multicast groups to receive UDP packets only from that source. >>>>> Without a source address, joinGroup() uses Any-Source Multicast (ASM), >>>>> which receives packets from any source sending to the group. SSM is >>>>> essential to using multicast outside of private networks, simplifying >>>>> packet routing, and filtering traffic at the network level by source >>>>> address, which mitigates spoofing and denial-of-service attacks. >>>>> >>>>> *Blink component* >>>>> Blink>Network->Direct Sockets >>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork-%3EDirect%20Sockets%22> >>>>> >>>>> *Web Feature ID* >>>>> Missing feature >>>>> >>>>> *Motivation* >>>>> RFC 8815 deprecates ASM for inter-domain use due to security >>>>> vulnerabilities and operational complexity. Without SSM support, >>>>> developers >>>>> building multicast applications in Isolated Web Apps face several >>>>> problems: >>>>> Limited deployment scenarios: Applications are restricted to controlled >>>>> private networks where all sources are trusted, preventing use cases like >>>>> internet-wide content distribution or cross-organization IoT systems. >>>>> Application-layer filtering overhead: Applications must receive and >>>>> process >>>>> all packets sent to a multicast group before validating the source, >>>>> wasting >>>>> CPU cycles and bandwidth on potentially malicious traffic. SSM is the >>>>> IETF-recommended model for multicast across domains (RFC 4607, RFC 8815) >>>>> and is supported by many enterprise and ISP networks. Adding SSM support >>>>> enables more secure multicast communication beyond private network >>>>> boundaries. >>>>> >>>>> *Initial public proposal* >>>>> https://github.com/WICG/direct-sockets/issues/80 >>>>> >>>>> *TAG review* >>>>> TAG does not review Isolated Web Apps: >>>>> https://github.com/w3ctag/design-reviews/issues/842#issuecomment-2917031448 >>>>> API design was reviewed on WICG/direct-sockets#80 and #81 (approved by >>>>> reillyeon and GrapeGreen). Alternatives considered there: a positional >>>>> source argument (replaced by an options dictionary) and a >>>>> source-filter-list API like IP_MSFILTER (rejected because each call >>>>> replaces the whole list). >>>>> >>>>> *TAG review status* >>>>> Not applicable >>>>> >>>>> *Goals for experimentation* >>>>> None >>>>> >>>>> *Risks* >>>>> >>>>> >>>>> *Interoperability and Compatibility* >>>>> Low. sourceAddress is an optional dictionary member: code that doesn't >>>>> pass it behaves exactly as before, and joinedGroups still returns strings >>>>> for ASM memberships. Where SSM is unavailable (older Chrome, or the >>>>> feature >>>>> turned off), sourceAddress is ignored and joinGroup() makes an ASM join; >>>>> apps can detect this because joinedGroups then lists a string, not a >>>>> MulticastMembership. Other browsers may choose to implement this API. >>>>> >>>>> *Gecko*: No signal Mozilla's position on the parent Direct Sockets >>>>> API is negative: >>>>> https://github.com/mozilla/standards-positions/issues/431 >>>>> >>>>> *WebKit*: No signal The WebKit position request for Isolated Web Apps >>>>> is open without a position: >>>>> https://github.com/WebKit/standards-positions/issues/184 >>>>> >>>>> *Web developers*: No signals The Ready for Trial thread got no >>>>> replies. >>>>> >>>>> *Other signals*: Harald Alvestrand recommended SSM in >>>>> https://github.com/WICG/direct-sockets/issues/80: "Basically >>>>> Any-Source Multicast with a scope larger than your local network is a >>>>> high-powered DDOS vector, not something that it's safe to build services >>>>> on, so I heartily recommend adding support for Single-Source Multicast." >>>>> Node.js dgram has the same capability (addSourceSpecificMembership / >>>>> dropSourceSpecificMembership). >>>>> >>>>> *Ergonomics* >>>>> The API follows the OS socket API (MCAST_JOIN_SOURCE_GROUP) and >>>>> Node.js dgram. Each (group, source) pair is its own membership, several >>>>> sources for one group are additive (RFC 4604), and a socket cannot mix ASM >>>>> and SSM memberships for the same group. >>>>> >>>>> *Activation* >>>>> Receiving SSM traffic needs a network that supports IGMPv3/MLDv2 and >>>>> routes SSM, or an AMT (RFC 7450) gateway on the host or local router that >>>>> tunnels it from a relay. Apps can't polyfill native SSM reception; the >>>>> closest substitute is running their own AMT gateway over unicast UDP. >>>>> >>>>> *Security* >>>>> SSM is part of the Direct Sockets API, and its security and privacy >>>>> self-review applies: >>>>> https://github.com/WICG/direct-sockets/blob/main/docs/security-privacy-self-review.md >>>>> SSM-specific points: - Exposure is the same as ASM multicast: Isolated Web >>>>> Apps with the "direct-sockets-multicast" permissions policy, on bound UDP >>>>> sockets that passed the local-network and loopback-network permission >>>>> checks. Since M150, ChromeOS users can also install IWAs that are on >>>>> Chrome's IWA allowlist; a user-installed IWA gets that policy only if the >>>>> allowlist grants it the DIRECT_SOCKETS_MULTICAST entitlement. There is no >>>>> new permission, prompt or content setting. - It reduces injection risk >>>>> compared with ASM: the OS and SSM routers drop datagrams from other source >>>>> addresses, so off-path hosts cannot inject traffic (RFC 8815 §3.2.3). It >>>>> is >>>>> not authentication: a host that forges the source address can potentially >>>>> still inject (RFC 4607 §7.4), so apps that need authenticity must >>>>> authenticate content, as with ASM. That also covers the fallback to an ASM >>>>> join when SSM is unavailable (see Interoperability). - The Linux >>>>> network-service sandbox allows setsockopt MCAST_JOIN_SOURCE_GROUP / >>>>> MCAST_LEAVE_SOURCE_GROUP (crrev.com/c/7641869). No other sandbox >>>>> change. - The network service re-checks the renderer's arguments but >>>>> missed >>>>> one case, which predates SSM: a compromised renderer of an IWA allowed to >>>>> use multicast could crash the network service (a NOTREACHED or CHECK, i.e. >>>>> denial of service) with an empty group address. crrev.com/c/8583003 >>>>> (RestrictedUDPSocket rejects non-multicast groups with a bad message) and >>>>> crrev.com/c/8583123 (network::UDPSocket rejects invalid group >>>>> addresses for all clients) fix it and land before the flag flips. - An SSM >>>>> join sends an IGMPv3/MLDv2 report that names the (source, group) pair on >>>>> the local link, as any native SSM receiver does. >>>>> >>>>> *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? >>>>> No. Direct Sockets is not available in WebView. >>>>> >>>>> >>>>> *Debuggability* >>>>> DevTools' Network panel lists Direct Sockets UDP sockets, and the >>>>> experimental CDP events Network.directUDPSocketJoinedMulticastGroup / >>>>> directUDPSocketLeftMulticastGroup report the groups a socket joins and >>>>> leaves. For SSM, their IPAddress field currently carries "group@source" >>>>> (e.g. [email protected]); a follow-up will add a separate >>>>> sourceAddress parameter (crbug.com/461262401). >>>>> MulticastController.joinedGroups returns {groupAddress, sourceAddress} for >>>>> SSM memberships, and invalid input throws specific TypeError or >>>>> InvalidStateError messages. >>>>> >>>>> *Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>> No >>>>> It is implemented on desktop platforms but only available to end users >>>>> where Isolated Web Apps are supported, which is currently ChromeOS. >>>>> Android >>>>> and WebView do not support Direct Sockets. Known macOS issue: on the macOS >>>>> 15 test bots, joining a group with a second source fails with NetworkError >>>>> for a reason not yet understood (crbug.com/443716695). It succeeds on >>>>> macOS 26, and single-source joins succeed on both. >>>>> >>>>> *Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>> No >>>>> There is no SSM WPT yet (follow-up tracked in crbug.com/461262401): >>>>> the spec rejects loopback sources, so the test has to send from a >>>>> non-loopback address of the test host, which I haven't validated on the >>>>> WPT >>>>> bots yet. The ASM multicast WPT >>>>> (direct-sockets/udp_socket_multicast.https.html) runs in Chromium's >>>>> virtual/direct-sockets suite (Timeout on Mac, crbug.com/443716695; >>>>> flaky on Linux, crbug.com/570251397). No Chromium test sends SSM >>>>> datagrams yet either; adding one is tracked in crbug.com/461262401. >>>>> SSM is covered by: - blink_unittests: MulticastControllerSsmTest.* >>>>> (validation, membership rules, IP-version mismatch, ASM/SSM mixing) and >>>>> the >>>>> IDL feature-flag tests - content_browsertests: >>>>> DirectSocketsBoundUdpBrowserTest.*SSM* - browser_tests (installed IWA): >>>>> ChromeDirectSocketsUdpIsolatedWebAppMulticastTest.*SSM* - net_unittests: >>>>> UDPSocketTest.JoinSourceGroup*, LeaveSourceGroup*, >>>>> SSMSourceFilteringMultiNIC* (join and leave with two sources) - >>>>> services_unittests: the bad-message and invalid-address tests in >>>>> crrev.com/c/8583003 and crrev.com/c/8583123 >>>>> >>>>> *DevTrial instructions* >>>>> >>>>> https://github.com/WICG/direct-sockets/blob/main/docs/multicast-explainer.md#receiving-datagrams-example-source-specific-multicast >>>>> >>>>> *Flag name on about://flags* >>>>> source-specific-multicast-in-direct-sockets >>>>> >>>>> *Finch feature name* >>>>> SourceSpecificMulticastInDirectSockets >>>>> >>>>> *Rollout plan* >>>>> Will ship enabled for all users >>>>> >>>>> *Requires code in //chrome?* >>>>> False >>>>> >>>>> *Tracking bug* >>>>> https://issues.chromium.org/issues/461262401 >>>>> >>>>> *Measurement* >>>>> The existing MulticastController use counters >>>>> (MulticastControllerJoinGroupFunction, >>>>> MulticastControllerLeaveGroupFunction, >>>>> MulticastControllerJoinedGroupsAttribute) count ASM and SSM calls >>>>> together. >>>>> A new use counter, MulticastControllerJoinGroupWithSourceAddress, counts >>>>> SSM joins and lands before the flip (crrev.com/c/8574609). >>>>> >>>>> *Availability expectation* >>>>> Available only to Isolated Web Apps, on platforms where IWAs are >>>>> supported (currently ChromeOS): IWAs installed by an admin or in developer >>>>> mode, and user-installed IWAs that Chrome's IWA allowlist grants the >>>>> DIRECT_SOCKETS_MULTICAST entitlement. Not available on Android or WebView. >>>>> >>>>> *Adoption expectation* >>>>> Initially a small number of IWA developers receiving multicast from >>>>> known sources, for example live streaming over SSM-enabled networks or AMT >>>>> relays. >>>>> >>>>> *Estimated milestones* >>>>> Shipping on desktop 160 >>>>> DevTrial on desktop 152 >>>>> >>>>> *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 expected. crrev.com/c/8582708 (lands before the flip) makes >>>>> Chromium reject loopback sourceAddress values, as the spec already >>>>> requires. Two Chromium behaviors are not in the spec text yet: a socket >>>>> cannot mix ASM and SSM memberships for one group, and leaveGroup() >>>>> validates its arguments like joinGroup(). >>>>> https://github.com/WICG/direct-sockets/pull/86 adds both. >>>>> >>>>> *Link to entry on the Chrome Platform Status* >>>>> https://chromestatus.com/feature/6208452397498368?gate=6516721057923072 >>>>> >>>>> *Links to previous Intent discussions* >>>>> Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692dffe2.050a0220.17ec37.0673.GAE%40google.com >>>>> Ready for Trial: >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vMmLZVd7rQI >>>>> >>>>> >>>>> 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 [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad03dc5.32cf16a2.aa5e8.002a.GAE%40google.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad03dc5.32cf16a2.aa5e8.002a.GAE%40google.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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org?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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_F4V%3DQmMytduzNor5TgytJS3i8P%3D_sqPHSx8HskndFqA%40mail.gmail.com.
