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). 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/77558f26-eaab-4a14-b5f4-ad75f948f1f6n%40chromium.org.
