TL;DR: We'd like to set up a deprecation trial for the following feature
from M109 to M112.
Context: Since M104, we've started sending preflight requests before
private network access, but ignoring the preflight result (or the lack of
it). After analyzing the URL-keyed metrics, we found that none of them
looks legit, most likely used for fingerprinting purposes, so we decided to
start enforcing the preflight response, but with a deprecation trial so
that websites that do need it have a time to migrate, and we would be able
to know who they are.
Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org,
l...@chromium.org, p...@chromium.org

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

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

Design docs
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit

Summary

Sends a CORS preflight request ahead of any private network requests for
subresources, asking for explicit permission from the target server. A
private network request is any request from a public website to a private
IP address or localhost, or from a private website (e.g. intranet) to
localhost. Sending a preflight request mitigates the risk of cross-site
request forgery attacks against private network devices such as routers,
which are often not prepared to defend against this threat.


Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>

TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

The main interoperability risk, as always, is if other browser engines do
not implement this. Compat risk is straightforward: web servers that do not
handle the new preflight requests will eventually break, once the feature
ships. The plan to address this is as follows: 1. Send preflight request,
ignore result, always send actual request. Failed preflight requests will
result in a warning being shown in devtools. 2. Wait for 3 milestones. 3.
Gate actual request on preflight request success, with deprecation trial
for developers to buy some more time. 4. End deprecation trial 4 milestones
later. UseCounters:
https://chromestatus.com/metrics/feature/timeline/popularity/3753
https://chromestatus.com/metrics/feature/timeline/popularity/3755
https://chromestatus.com/metrics/feature/timeline/popularity/3757 The above
measure pages that make at least one private network request for which we
would now send a preflight request.


*Gecko*: Worth prototyping (
https://github.com/mozilla/standards-positions/issues/143)

*WebKit*: No signal (
https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html)
Pending response.

*Web developers*: No 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*:

Ergonomics

None.


Activation

Gating access to the private network overnight on preflight requests would
likely result in widespread breakage. This is why the plan is to first send
requests but not act on their result, giving server developers time to
implement code handling these requests. Deprecation warnings will be
surfaced in DevTools to alert web/client developers when the potential for
breakage later on is detected. Enforcement will be turned on later (aiming
for 3 milestones), along with a deprecation trial for impacted web
developers to buy themselves some more time. Experience suggests a large
fraction of developers will not notice the advance deprecation warnings
until things break.


Security

This change aims to be security-positive, preventing CSRF attacks against
soft and juicy targets such as router admin interfaces. It does not cover
navigation requests and workers, which are to be addressed in followup
launches. 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?


Not going to ship on Android WebView

Goals for experimentation

Give websites time to make sure they respond to the preflights

Reason this experiment is being extended

N/A

Ongoing technical constraints

N/A

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.


Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?No

Not on Android WebView given previous difficulty in supporting PNA changes
due to the lack of support for deprecation trials. Support for WebView will
be considered separately.


Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?Yes

DevTrial instructions
https://github.com/WICG/private-network-access/blob/main/HOWTO.md

Flag namePrivateNetworkAccessRespectPreflightResults

Requires code in //chrome?False

Tracking bughttps://crbug.com/591068

Launch bughttps://crbug.com/1274149

Estimated milestones
OriginTrial desktop last 112
OriginTrial desktop first 109
DevTrial on desktop 98
OriginTrial Android last 112
OriginTrial Android first 109
DevTrial on Android 98

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/72CK2mxD47c


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%3DiP%2Bew8hADZkdQ3AO6P9WzfGuzLPp9JjJZqztV5oZmaK8oQ%40mail.gmail.com.

Reply via email to