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/3ee3e99a-518d-4984-8638-ab25559a8ac6n%40chromium.org.
