I'm curious about the enterprise situation here. This seems to me like
something that could be in use in enterprise applications, and we would
not really know about it. (
https://www.chromium.org/developers/enterprise-changes/ is a good
checklist for this)
Is there an enterprise policy for this that can be used for those that
need the old behaviour, if not, could one be added?
Also, have you reached out to the enterprise community? (See link above)
/Daniel
On 2022-10-05 15:28, Jonathan Hao wrote:
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 most of them don't seem legit, most likely used for
fingerprinting purposes, so we decided to start enforcing the
preflight response, which means that the websites will not be
able to fetch subresources from less-public ip address space
without getting proper preflight responses.
An intent focusing on the deprecation trial was sent earlier in this
thread:
https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer
<https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer>.
There, we were suggested to send a separate intent to remove the
functionality, and hence this intent email.
Contact emails
tito...@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
Specification
https://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 component
Blink>SecurityFeature>CORS>PrivateNetworkAccess
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess>
TAG review
https://github.com/w3ctag/design-reviews/issues/572
TAG review status
Issues 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 name
PrivateNetworkAccessRespectPreflightResults
Requires code in //chrome?
False
Tracking bug
https://crbug.com/591068
Launch bug
https://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 discussions
Intent 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%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%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/a9624eeb-3681-88fd-5886-9fccdd65bd82%40gmail.com.
