Ready for Developer Testing: Local network access restrictions for WebSockets

14 views
Skip to first unread message

Chromestatus

unread,
2:20 PM (8 hours ago) 2:20 PM
to blin...@chromium.org, cth...@chromium.org, jdeb...@chromium.org, hc...@chromium.org
Contact emails
hc...@chromium.org

Explainer
https://github.com/WICG/local-network-access/blob/main/explainer.md#websockets

Specification
https://wicg.github.io/local-network-access/#integration-with-websockets

Summary
Restricts the ability to make requests to the user's local network using WebSockets, gated behind a permission prompt. A local network request is any request from a public website to a local IP address or loopback, or from a local website (e.g. intranet) to loopback. Gating the ability for websites to perform these requests behind a permission reduces the ability of sites to use these requests to fingerprint the user's local network. This permission is restricted to secure contexts. This work is adding to the Local Network Access Restrictions work here: https://chromestatus.com/feature/5152728072060928

Blink component
Blink>SecurityFeature>LocalNetworkAccess

Web Feature ID
local-network-access

TAG review
None

TAG review status
Pending

Risks


Interoperability and Compatibility
Interoperability risks: LNA requires a Secure Context to make local network requests, but exempts some of these local network requests from mixed content checks (if the user grants permission). If another browser does not implement LNA, these same local network requests might be blocked as mixed content, or the site might need to serve over HTTPS for Chrome and over HTTP for browsers that don't implement LNA (to avoid triggering mixed content). Compatibility risks: There are some local network requests types that we cannot know ahead of time will be going to the local network (e.g., a subresource request to http://test.example which then resolves to 192.168.0.1). These would be blocked as mixed content, as mixed content checks happen before hostname resolution (i.e., they occur before "Obtain a connection" in Fetch). Explicit local IP addresses, and `.local` domains are exempted from mixed content checks, but we do not have an equivalent to the `targetAddressSpace` fetch() option for WebSockets We hope that our Dev Trial will help identify compatibility issues. The LNA reverse origin trial will provide a temporary opt-out for those that are not able to bypass the mixed content checks currently

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Activation
A new permission will be shown to users, which may be unexpected, and if users deny the permission functionality may break (potentially requiring additional support from site owners). As this is building off of the first Local Network Access launch, this should be a minimal risk, but has a chance of impacting those who are impacted by this launch but were not impacted by the original Local Network Access launch.

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? None



Goals for experimentation


Ongoing technical constraints
None

Debuggability
None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
NoThis is unsupported on WebView for the same reasons that Local Network Access is unsupported on WebView

Is this feature fully tested by web-platform-tests?
No

DevTrial instructions
https://docs.google.com/document/d/1GHbpRTCnfDXq9o8WKyrG7oPAiWC6Yozac-PvbfO3KoY/edit?usp=sharing

Flag name on about://flags
local-network-access-check-websockets

Finch feature name
LocalNetworkAccessChecksWebSockets

Requires code in //chrome?
False

Tracking bug
https://crbug.com/421156866

Measurement
Use counters: - PrivateNetworkAccessWebSocketConnected counts the number of LNA WebSockets request we see - LocalNetworkAccessWebSocketResourceNotKnownPrivate - counts cases in which a `targetAddressSpace` option could have helped bypass mixed content checks

Estimated milestones
DevTrial on desktop142
DevTrial on Android142


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5197681148428288

Links to previous Intent discussions
Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68b9e717.050a0220.3291f8.09fe.GAE%40google.com


This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages