Correction: LGTM1, conditioned on requesting Enterprise, Debuggability,
and Testing bits in chromestatus. :)
On 2/2/24 5:09 PM, Mike Taylor wrote:
LGTM1
On 2/2/24 11:17 AM, Jonathan Hao wrote:
Contact emails
p...@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
<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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
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)
https://mozilla.github.io/standards-positions/#cors-and-rfc1918 makes
it a bit clearer that this is indeed positive (vs the issue).
/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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<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
<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 blink-dev+unsubscr...@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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiPJ3_pVL7Tecn_3iKBMojOVPx8%3D%3DnCDQWRKetG_9WBxsWg%40mail.gmail.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 blink-dev+unsubscr...@chromium.org.
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.
