Use Case: in-home cache node content delivery and LNA as a UX barrier #111
Description
Our project relies on a transparent in-home cache node installed at the user's HGU (Home Gateway Unit) to deliver video content via Multicast by design, this is completely invisible to the end user. The new LNA policy interrupts this architecture with a browser prompt that the user must consciously approve, breaking the transparent delivery model and introducing a hard friction point that is incompatible with a consumer-grade video streaming experience. Known as Multicast ABR (MABR) it permits Content providers to deliver content via Multicast to OTT devices installing a content gateway at home premises. The solution needs to finally redirect the end user to the local HGU to get the content.
The broader industry trend among Content Providers (CPs) and Network Operators (NOs) is unambiguous: edge and in-home caching is the next frontier for high-quality, low-latency video delivery at scale.
Network Operators are actively deploying cache nodes within the subscriber's CPE/HGU (or as a standalone device on the LAN) to offload CDN transit costs, reduce last-mile congestion, and enable ultra-low-latency delivery of live and on-demand content including Multicast-to-Unicast translation for IPTV and OTT workflows.
Content Providers are pushing toward edge delivery to meet 4K/8K bitrate demands, reduce rebuffering, and improve QoE metrics especially for live sports and real-time events where CDN RTT matters.
Standards bodies (ETSI, CableLabs, 3GPP) and industry alliances (DASH-IF, DVB) are converging on architectures where the home gateway is a first-class delivery node, not just a router.
Our system is specifically designed so the cache node is transparent to the end user the player fetches content from what appears to be a standard CDN URL, and local DNS/ARP resolution silently redirects to the in-home cache. The user has zero awareness of (and zero need to understand) the local network topology.
Chrome's LNA enforcement surfaces a permission dialog that:
-
Requires immediate user action: The prompt appears before content can be fetched, blocking playback until the user consciously chooses to allow or deny access.
-
Lacks user-meaningful context: The browser UI refers generically to "local network access", giving no indication that this is a legitimate, operator-deployed caching infrastructure indistinguishable from a malicious request. And it forces third party Content provider applications to be modified to manage this permission, making this a barrier for the seamless introduction of MABR solutions in the streaming market.
Breaks on denial: If the user clicks "Block" (the safe default for most users), the fetch to the local cache fails, playback cannot start or falls back to degraded CDN delivery or breaks entirely.
Non-recoverable without expertise: Reversing a "Block" decision requires navigating to chrome://settings/content/localNetworkDevices completely outside the reach of a typical consumer subscriber.
Possible solution:
Access to the local device using HTTPS requires to use a FQDN that is resolved to the local address (our solution implements exactly that). If the redirections belongs to the same domain than the original request, LNA should permit this connection without user intervention.
For example:
Content provider Video Platform: videos.contentprovider.com
When user plays out the content, it can go though fetch or other mechanisms to a third party CDN that is permitted thtough CORS.
CDN URL: videocontent.thirdpartycdn.com/video.mp4
When the CDN knows there is an Edge cache at user's premises, it will try a redirect to it using a subdomain that could be resolved to the local address.
HTTP 302 Redirect
Location: https://edgenode.thirdpartycdn.com/video.mp4
As the edge cache node is in the same domain as the original request, LNA permits the connection without any notification.