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.
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.
None.
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.
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
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.
DevTrial on desktop | 98 |
DevTrial on android | 98 |
--
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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com.
Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?
I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.
I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.
The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?
--
Given this specifically calls out subresources and the design doc lists “the case of navigations” as “followup work,” you’re explicitly not touching how navigations (top-level or an iframe) work at this stage, correct?
I expect the most significant compat impact to come from Windows apps that delegate to the default browser to do a login flow where the last step of the auth flow is making a request to a localhost HTTP server to pass back to the app an auth ticket.
I anticipate most of those are top-level navigations, but my experience with the first version of Microsoft Edge (pre-Chromium) which prevented localhost loopback for subresources (including iframes), there are apps that handle it some other way which we broke. Some of those may have been passing it back via an iframe navigation (I don’t recall—it was 6+ years ago) in which case they’ll potentially still work after this change.
The Microsoft Edge team will work to reach out to Microsoft teams that are potentially impacted. If the roadmap is going to eventually force a preflight before allowing a navigation to a private network origin, we would ideally include clear guidance on what’s likely coming there as well. Is there a general timeline you have in mind for expanding this to navigations as well?
Explainer
https://github.com/WICG/private-network-access/blob/main/explainer.mdSpecification
https://wicg.github.io/private-network-access/Design docs
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/editSummary
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>PrivateNetworkAccessTAG review
https://github.com/w3ctag/design-reviews/issues/572TAG review status
PendingRisks
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
On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote:
Explainer
https://github.com/WICG/private-network-access/blob/main/explainer.mdSpecification
https://wicg.github.io/private-network-access/Design docs
https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/editSummary
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>PrivateNetworkAccessTAG review
https://github.com/w3ctag/design-reviews/issues/572TAG review status
PendingRisks
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.
Would that include deprecation reports?
2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time.
We'd also need to communicate this widely in order to get relevant developers to sign up for the deprecation trial. UKM investigation can help us focus efforts on that front.
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
That's a lot of usage :/ I remember you did a bunch of UKM investigations in the past. Did that include this case as well?
This sounds like a change that would disproportionately affect "enterprise" so it's probably best to involve the Chrome enterprise team sooner rather than later. The numbers are higher than I would have expected. Makes me wonder if there is some specific source of those. I would have expected it to be rarer than that to embed a resource from a private network.
/Daniel
--
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/CAPATO9f6QS%3D4oJqnJg6NR%3DpoKcT149h8LeiSzkfd%3Dqq8qV6pLA%40mail.gmail.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org.
Hi,Now when chrome 102 is out I wanted to test it so I ran it with --enable-features=PrivateNetworkAccessRespectPreflightResultsThere's one thing I'm trying to understand,I have an HTML page with a script tag, the src of this tag points to a more private network, the default behavior of script tags is not to trigger CORS and since v102 they do trigger it which is expected.My question is:I'm getting this error: "Response to preflight request doesn't pass access control check: The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'."I never asked to send credentials in my script tag, I guess I can force not send it by adding crossorigin="" to the tag but shouldn't the default behavior be not to send it with credentials?
Just wanted to state here that we'll send a different intent to ship
Grammar correction, sorry:"a brief tutorial to a newbie on the status of PNA and..."On Monday, April 24, 2023 at 2:13:59 PM UTC-5 Scott Weber wrote:Forgive me if this is not the correct place to ask...I seem to have stumbled across this conversation trying to find answers (this thread looks like an email archive chain).I am new to this platform of getting early information about upcoming changes.Originally, PNA was supposed to "go live" in Version 113. When I heard about it back in Nov '22, we tested it in Chrome v104 and placed support in our firmware back then.So, is this now what could be called "on hold" ?
(while we updated our firmware, there is no assurance the 1000's and 1000's of devices in the wild are being updated in a timely manner)On Thursday, April 6, 2023 at 3:58:02 AM UTC-5 Titouan Rigoudy wrote:Just wanted to state here that we'll send a different intent to shipWhat is "intent to ship" ? And what is meant my "send"? Send to who? Is there a mailing list?
Titouan and others mention things like M100, M101. Is this the same designation as version number (v104, and v113).
In summary, my supervisor is asking me to find out if we need to be ready to tell a plethora of customers they have to upgrade our firmware when it stops working in the next day or two (or have doc ready telling them how to disable this requirement).Please, could someone give a brief tutorial to a newbie on PNA and how to be "in the loop" on these things?
Thanks.