LGTM2
On Wed, Oct 21, 2026 at 8:19 AM Alex Russell
<[email protected]> wrote:
Thanks Omar,
LGTM1
On Tuesday, October 20, 2026 at 6:28:37 AM UTC-7
[email protected] wrote:
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
On Tue, Oct 20, 2026 at 1:48 AM Alex Russell
<[email protected]> wrote:
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
<https://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 <https://crrev.com/c/8583003>
(RestrictedUDPSocket rejects non-multicast groups
with a bad message) and crrev.com/c/8583123
<https://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
<https://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
<https://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):
<https://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;
<https://crbug.com/443716695;> flaky on Linux,
crbug.com/570251397
<https://crbug.com/570251397>). No Chromium test
sends SSM datagrams yet either; adding one is
tracked in crbug.com/461262401
<https://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
<https://crrev.com/c/8583003> and
crrev.com/c/8583123 <https://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 <https://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
<https://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/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org?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/CAOMQ%2Bw_F4V%3DQmMytduzNor5TgytJS3i8P%3D_sqPHSx8HskndFqA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_F4V%3DQmMytduzNor5TgytJS3i8P%3D_sqPHSx8HskndFqA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
