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


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, ie 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" (eg 
[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


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 (eg links to known github issues in the project 
for the feature specification) whose resolution may introduce web 
compat/interop risk (eg, 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.

-- 
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.

Reply via email to