Intent to Ship: Private Network Access preflight requests for subresources

1360 views
Skip to first unread message

Titouan Rigoudy

unread,
Nov 29, 2021, 10:37:24 AM11/29/21
to blink-dev

Contact emails

tit...@chromium.orgva...@chromium.orgcl...@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

TAG review

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

TAG review status

Pending

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. 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



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

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

DevTrial on desktop98
DevTrial on android98


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


This intent message was generated by Chrome Platform Status.

Joe Medley

unread,
Nov 30, 2021, 3:27:58 PM11/30/21
to Titouan Rigoudy, blink-dev
Titouan,

Will the default for the runtime flag be 'Enabled' in 98?

The DevTrial number should reflect when the flag was first available. 'Shipping' refers to when it can be used in production without web developers or users doing anything. This can mean the flag was removed or it can mean the flag's default was changed to 'Enabled'.

Joe
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


--
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.

Erik Anderson

unread,
Nov 30, 2021, 5:42:39 PM11/30/21
to Titouan Rigoudy, blink-dev

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?

--

Titouan Rigoudy

unread,
Dec 1, 2021, 6:09:28 AM12/1/21
to Erik Anderson, blink-dev
Thanks for the responses!

Joe: the `PrivateNetworkAccessSendPreflights` feature flag will be enabled by default in M98 (if this intent gets 3 LGTMs). The `PrivateNetworkAccessRespectPreflightResults` will be enabled by default later, I am aiming for M101.

On Tue, Nov 30, 2021 at 11:42 PM Erik Anderson <Erik.A...@microsoft.com> wrote:

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?


That is 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.


If they indeed use either top-level or iframe navigations, then they will be unaffected by 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?


I don't have a very clear timeline yet, but I wish to tackle nested navigations in particular in M100.

Cheers,
Titouan

Yoav Weiss

unread,
Dec 1, 2021, 7:22:41 AM12/1/21
to blink-dev, Titouan Rigoudy


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.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

TAG review

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

TAG review status

Pending

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.


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.
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?

Titouan Rigoudy

unread,
Dec 1, 2021, 8:43:25 AM12/1/21
to Yoav Weiss, blink-dev
Thanks for the response Yoav, answers inline.

On Wed, Dec 1, 2021 at 1:22 PM Yoav Weiss <yoav...@chromium.org> wrote:
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.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

TAG review

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

TAG review status

Pending

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.


Would that include deprecation reports?

Not so far. Blink is not made aware of the warnings yet, they go from the network service to the browser process and then straight to devtools. More wiring would be needed for Blink to notice the warning and send a deprecation report.
 
 

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.

That is true. I am planning to write a blog post on web.dev or the chrome blog to help raise awareness.


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?

I did not look at these metrics during my previous UKM analysis - I was focusing on non-secure contexts initiating private network requests. I can look into them again however, and try to reach out to the biggest users before enforcement is turned on.

Cheers,
Titouan

Daniel Bratell

unread,
Dec 1, 2021, 9:02:46 AM12/1/21
to Titouan Rigoudy, Yoav Weiss, blink-dev

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.

Titouan Rigoudy

unread,
Dec 1, 2021, 9:14:29 AM12/1/21
to Daniel Bratell, Yoav Weiss, blink-dev
Good idea, I will alert the enterprise team of the upcoming change.

There are also existing enterprise policies [1] [2] introduced for the previous change (secure context restriction) that also work in this context to disable the new behavior entirely. Their descriptions need a little updating for it to be clear that they apply to this change as well. Filed crbug.com/1275567 to fix that.

As for specific sources: UKM data might not tell us unfortunately, since AFAIU that data is not reported by enterprise deployments?

Cheers,

Yoav Weiss

unread,
Dec 1, 2021, 9:21:59 AM12/1/21
to Titouan Rigoudy, blink-dev
https://groups.google.com/a/chromium.org/g/blink-dev/c/xWVtdGDLz_Q/m/kyofZuRfBAAJ may be a relevant conversation on that front. It may be worthwhile to talk to Andrew to see what they did on that front.

Titouan Rigoudy

unread,
Dec 1, 2021, 9:56:41 AM12/1/21
to Yoav Weiss, blink-dev
Thanks for the pointer! I've reached out and will see what I can do.

Cheers,
Titouan

Mike Taylor

unread,
Dec 2, 2021, 10:45:52 AM12/2/21
to Titouan Rigoudy, blink-dev
Hi Titouan,

I'm curious what the plan is for structured headers. https://github.com/WICG/private-network-access/issues/45 is marked as blocked - has there been other progress or thinking behind the scenes?

thanks,
Mike
--
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.

Titouan Rigoudy

unread,
Dec 2, 2021, 10:55:18 AM12/2/21
to Mike Taylor, blink-dev
Hi Mike,

There is no support for structured headers so far, for consistency reasons, and there has been no movement to deprecate the "true" value for Access-Control-Allow-Credentials. The value of such a deprecation seems minimal.

I could pretty easily add support for the structured "?1" value on top of the "true" token for the new Access-Control-Allow-Private-Network header, and specify that, but I'm not sure it would be terribly useful. Do you think otherwise?

Cheers,
Titouan

Mike West

unread,
Dec 2, 2021, 11:12:00 AM12/2/21
to Titouan Rigoudy, Mike Taylor, blink-dev
I'm not sure it makes sense to introduce a structured header here, given that it's layering on top of CORS headers that I don't think there's substantial interest in changing.

-mike


Mike Taylor

unread,
Dec 2, 2021, 11:14:25 AM12/2/21
to Mike West, Titouan Rigoudy, blink-dev
Thanks - I also don't think there's a lot of value in this particular header being the odd-one-out, just wanted to confirm we're not going to ship "true" first and try to change that to ?1 later (which is always challenging).

Mike West

unread,
Dec 2, 2021, 11:17:51 AM12/2/21
to Mike Taylor, Titouan Rigoudy, blink-dev
_I_ don't think we should do that, but I'd defer to Titouan's preference. :)

-mike

Titouan Rigoudy

unread,
Dec 2, 2021, 11:20:40 AM12/2/21
to Mike West, Mike Taylor, blink-dev
I agree!

Cheers,
Titouan

Titouan Rigoudy

unread,
Dec 3, 2021, 12:44:28 PM12/3/21
to Mike West, Mike Taylor, blink-dev
Yoav, do you think UKM analysis should block sending preflights without enforcing their success? I believe sending these will allow us to get more precise information on the affected websites through the usecounter recorded in crrev.com/c/3310846. I can then analyze UKM data and use the results to inform the decision whether and when to switch enforcement on?

Cheers,
Titouan

Yoav Weiss

unread,
Dec 6, 2021, 4:59:05 AM12/6/21
to Titouan Rigoudy, Mike West, Mike Taylor, blink-dev
I agree UKM analysis should not block step 1, as it holds little risk. (There's still some risks that servers will choke in the face of preflights, but that seems minor compared to the enforcement risk)

Therefore, LGTM1 for step 1 (preflights with no enforcement), but not further (yet). Please come back to this thread with any data you may have as a result of adding UKMs.

Titouan Rigoudy

unread,
Dec 6, 2021, 5:31:49 AM12/6/21
to Yoav Weiss, Mike West, Mike Taylor, blink-dev
Thanks! I'll come back for further discussion with UKM data in hand.

Cheers,
Titouan

Titouan Rigoudy

unread,
Dec 6, 2021, 5:32:26 AM12/6/21
to Yoav Weiss, Mike West, Mike Taylor, blink-dev
*assuming I get 2 more LGTMs, that is.

Mike Taylor

unread,
Dec 6, 2021, 9:11:14 AM12/6/21
to Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev
LGTM2 for step 1.

Chris Harrelson

unread,
Dec 6, 2021, 11:26:42 AM12/6/21
to Mike Taylor, Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev

Titouan Rigoudy

unread,
Feb 17, 2022, 9:26:22 AM2/17/22
to Chris Harrelson, Mike Taylor, Yoav Weiss, Mike West, blink-dev
Hi all,

Just to let you know that due to a couple issues, chief among which a renderer crash (crbug.com/1279376), we are rolling this feature back from Chrome 98.

A few issues have been identified and will block our next attempt at shipping this. In the meantime, we gathered some useful information about impact and notified developers of the upcoming change. I'll write a doc summarizing the timeline and lessons learned, then share as appropriate here.

Cheers,
Titouan

Mike Taylor

unread,
Feb 17, 2022, 9:30:03 AM2/17/22
to Titouan Rigoudy, Yoav Weiss, Mike West, blink-dev, Chris Harrelson
Thanks for the update Titouan. Looking forward to reading your doc.

Titouan Rigoudy

unread,
Mar 2, 2022, 5:36:21 AM3/2/22
to Mike Taylor, Yoav Weiss, Mike West, blink-dev, Chris Harrelson
Hi all,

Here's the promised doc: https://docs.google.com/document/d/1fdwetZXUz_Q03ZpGwXizq5AE1yn_lMhamUJMwvsHvTU/edit (public, comment access for committers only)

Cheers,
Titouan

Logan Wei

unread,
Apr 6, 2022, 11:20:51 AM4/6/22
to blink-dev, Titouan Rigoudy
Hello,  is there now an updated timeline to roll out this change?  Will the trial restart in Chrome 102 or a later version?  

Titouan Rigoudy

unread,
Apr 6, 2022, 1:23:58 PM4/6/22