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/CAEx2XGz1jT6CXDkqpQccPgkmoy4v1wwYV9PEyErNw%2B%3D6VzmRtA%40mail.gmail.com.
