Intent to Prototype and Ship: Private network access checks for navigation requests: warning-only mode

[Jonathan Hao]

Contact emails

ph...@chromium.org

Explainer

https://github.com/WICG/private-network-access/blob/main/explainer.md

Specification

https://wicg.github.io/private-network-access

Design docs

https://docs.google.com/document/d/1UqkJsc2VZ4bXmZkVxh-EPyBFEtdxX9p2zX4sxzAj754/edit?usp=sharing&resourcekey=0-7cfhrTo57AElxA6M9EVScg

Summary

Before a website A navigates to another site B in the user's private network, this feature does the following:
1. Checks whether the request has been initiated from a secure context
2. Sends a preflight request, and checks whether B responds with a header that allows private network access.

The above checks are made to protect the user's private network.  There are already features for subresources and workers, but this one is for navigation requests specifically.

Since this feature is the "warning-only" mode, we do not fail the requests if any of the checks fails.  Instead, a warning will be shown in the DevTools, to help developers prepare for the coming enforcement.

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

Motivation

To prevent malicious websites from pivoting through the user agent's network position to attack devices and services which reasonably assumed they were unreachable from the Internet at large, by virtue of residing on the user’s local intranet or the user's machine.

Initial public proposal

https://discourse.wicg.io/t/transfer-cors-rfc1918-and-hsts-priming-to-wicg/1726

TAG review

https://github.com/w3ctag/design-reviews/issues/572

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

Since we don't enforce the checks and only show warnings, there isn't any compatibility risks on the client side. On the server side, it shouldn't pose any risk either as the server can ignore the preflight requests.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/143)

WebKit: Positive (https://github.com/WebKit/standards-positions/issues/163) Safari disagrees with the spec name and header names, but still overall positive.

Web developers: Mixed signals Anecdotal evidence so far suggests that most web developers are OK with this new requirement, though some do not control the target endpoints and would be negatively impacted.

Other signals:

Security

This change aims to be security-positive, preventing CSRF attacks against soft and juicy targets such as router admin interfaces. DNS rebinding threats were of particular concern during the design of this feature: https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9

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

Debuggability

Relevant information (client and resource IP address space) is already piped into the DevTools network panel. Deprecation warnings and errors will be surfaced in the DevTools issues panel explaining the problem when it arises.

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

Yes

https://wpt.fyi/results/fetch/private-network-access?q=fetch%2Fprivate-network-access&run_id=5090117631868928&run_id=6245938696814592&run_id=5769215446351872&run_id=5679819023974400

Flag name on chrome://flags

None

Finch feature name

PrivateNetworkAccessForNavigations, PrivateNetworkAccessForNavigationsWarningOnly

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1524350

Estimated milestones

Shipping on desktop

124

Shipping on Android

124

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4869685172764672

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM1

https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes it a bit clearer that this is indeed positive (vs the issue).

--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPJ3_pVL7Tecn_3iKBMojOVPx8%3D%3DnCDQWRKetG_9WBxsWg%40mail.gmail.com.

[Mike Taylor]

Correction: LGTM1, conditioned on requesting Enterprise, Debuggability, and Testing bits in chromestatus. :)

[Yoav Weiss (@Shopify)]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f8b93f8-4358-4fdc-bfe2-d43cec3e37c1%40chromium.org.

[Daniel Bratell]

LGTM3 to add a warning.

Normally we don't like open ended deprecation warnings, end, which this is, but this should be a rare warning, except possibly in enterprise situations, and even there, warnings might trigger some feedback from a group that is normally not aware of upcoming changes.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSLfMW08XDibmDKrCKkJOjyHj3B%2B3MsmQ4WnwxeoBk_wng%40mail.gmail.com.

[Jonathan Hao]

Here's a public version of the design doc: https://docs.google.com/document/d/1QyFqHCgZLmEfy0wbgXNgce9zKpZVaqSpQY3JleFWrk0/edit?usp=sharing

[Jonathan Hao]

I just realized that we can still make M123 so I plan to do so unless there are any objections.

[Mike Taylor]

The change in milestones won't affect your approvals to ship. :)