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 (added in https://github.com/WICG/direct-sockets/pull/81) 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. Why is this IWA-specific? SSM is an optional sourceAddress on MulticastController.joinGroup()/leaveGroup(), part of the Direct Sockets API. Direct Sockets multicast is exposed only to Isolated Web Apps (Chrome Apps can use Direct Sockets, but not multicast), and the app must also declare the "direct-sockets-multicast" permissions policy in its manifest. SSM inherits that exposure unchanged and adds no new permission or prompt: it narrows each membership to a single source, which also lets apps receive multicast on networks that only route SSM. Blink component Blink>Network>DirectSockets 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 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? 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 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. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? No Estimated milestones Shipping on desktop: 160 DevTrial on desktop: 152 Anticipated spec changes Open questions in a spec that may cause breaking changes, or where implementations may diverge? 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 -- 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/179202665552.929522.18414200708482080828%40blockcast.net.
