Intent to Ship: Source Specific Multicast for Direct Sockets API

[Chromestatus]

Contact emails

om...@blockcast.net

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, 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. 232....@192.0.2.100); 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 (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.

[Omar Ramadan]

Contact emails
om...@blockcast.net

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.

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?

[Reilly Grant]

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 | rei...@chromium.org | Google Chrome

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad03dc5.32cf16a2.aa5e8.002a.GAE%40google.com.

[Alex Russell]

What's the developer benefit for SSM? Is anyone asking for this?

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Omar Ramadan]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

Thanks Omar,

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Chris Harrelson]

LGTM2

Thanks Omar,

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ad03dc5.32cf16a2.aa5e8.002a.GAE%40google.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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org.

[Mike Taylor]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_F4V%3DQmMytduzNor5TgytJS3i8P%3D_sqPHSx8HskndFqA%40mail.gmail.com.