v152 · isolated web apps · proposed
Source Specific Multicast for Direct Sockets API
Joining a multicast group with plain joinGroup("239.0.0.1") is Any-Source Multicast: the socket receives from whoever sends to the group — which is why RFC 8815 deprecates ASM between domains as a DDoS vector. This proposal adds one optional dictionary member, MulticastGroupOptions.sourceAddress, turning the join into Source-Specific Multicast: packets arrive only from the source you named. Direct Sockets — and therefore all of this — exists only inside Isolated Web Apps; a normal page like this one genuinely cannot open a UDPSocket, and these demos never pretend otherwise.
concepts
-
Isolated-context probe
The honest capability read: probe
UDPSocket,TCPSocketandMulticastControllerfor real, alongside the context facts that explain the result — secure context, cross-origin isolation, the permissions-policy register. The point is the why: these interfaces carry[IsolatedContext], so their absence here is the IWA gate, not browser age. -
SSM vs ASM lab
An interactive network diagram — three senders, one group, one receiver. Build the exact
joinGroup()call with or withoutsourceAddress, toggle which senders transmit (including a spoofing attacker), and watch which datagrams the membership actually delivers. Clearly labelled a model of the spec's filtering behavior, never a live socket. -
Join validation bench
The edge and failure angle: the spec's
joinGroup()steps, run in order against any group/source pair you type. Family mismatches, non-multicast groups, loopback sources, duplicate memberships, ASM/SSM mixing, leaving with the wrong source — each stops at the exact step the spec names, with the exact exception (TypeError,InvalidStateError,NetworkError) a real IWA would see.
why it shipped
It is proposed for Chrome 160 (per ChromeStatus) and incubating in WICG. The driver is security at scale: Harald Alvestrand's review of the multicast proposal put it bluntly — any-source multicast beyond the local network "is a high-powered DDOS vector, not something that it's safe to build services on", recommending single-source support. SSM fixes that at the network layer: receivers declare the one source they trust, routers stop maintaining state for every possible sender, and attackers can't inject into the stream without owning the expected source address. Node's dgram grew the same capability (addSourceSpecificMembership), and the ChromeApps sockets.udp API this ports from had multicast for a decade. The use cases — synchronized video walls, mDNS-style device discovery — come straight from the explainer.
research record — use cases & exact surface
- Exact surface (WICG Direct Sockets spec):
dictionary MulticastGroupOptions { DOMString sourceAddress; }, consumed byMulticastController.joinGroup(groupAddress, options)/leaveGroup(groupAddress, options);joinedGroupsis aFrozenArray<(DOMString or MulticastMembership)>where SSM memberships surface as{ groupAddress, sourceAddress }objects.MulticastControlleris[Exposed=(Window, DedicatedWorker), SecureContext, IsolatedContext]and arrives viaUDPSocketOpenInfo.multicastController. - Validation steps (spec, joinGroup): invalid IP →
TypeError; non-multicast group (outside IPv4 224.0.0.0/4 / IPv6 ff00::/8) →TypeError; sourceAddress invalid, or multicast/loopback/unspecified, or a different IP version from the group →TypeError; duplicate (group, source) membership or closed socket →InvalidStateError; OS join failure →NetworkError. The explainer adds: mixing ASM and SSM memberships on one group address →InvalidStateError. SSM convention ranges (IANA): 232.0.0.0/8 and ff3x::/32 — recommended, not enforced. - Gating: Direct Sockets is Isolated-Web-Apps-only; multicast operations additionally sit behind the
direct-sockets-multicastpolicy-controlled feature (violations reject withNotAllowedError). Runtime flagSourceSpecificMulticastInDirectSockets, statustestinruntime_enabled_features.json5(verified on trunk) — statustestmeans even--enable-experimental-web-platform-featuresdoes NOT enable it; only an explicit--enable-blink-features=SourceSpecificMulticastInDirectSocketsinside an isolated context does. Finch nameSourceSpecificMulticastInDirectSockets. - Use-case portfolio: honest capability probe (isolated-context-probe), configuration/inspection + the explainer's practical scenarios as presets (ssm-vs-asm-lab: video wall, mDNS discovery, spoofing attacker), edge/failure (join-validation-bench). Because Direct Sockets is policy-gated to installed IWAs, every angle past the probe is necessarily a clearly-labelled model on a showcase page — the documented pattern for policy-gated features. A separate "practical product" page would duplicate the lab's scenario presets rather than add an angle, so the practical angle lives inside the lab; a live-socket composition belongs in an installable IWA sample, recorded as an open question.