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/CAEmk%3DMb7LptP0w-_PVwnUhmbwkWqg496ScuZzB_QUg2%2BLWJ_ZQ%40mail.gmail.com.
