Intent to Experiment: Private Network Access preflight requests for subresources

[Jonathan Hao]

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 emails

tit...@chromium.org, va...@chromium.org, cl...@chromium.org, l...@chromium.org, ph...@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

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?

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.

[Yoav Weiss]

Thanks for pushing this! :)

On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <ph...@chromium.org> wrote:

TL;DR: We'd like to set up a deprecation trial for the following feature from M109 to M112.

What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent?

 

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

Can you clarify who "them" is? Is it URLs that fail the preflight?

 

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

[Jonathan Hao]

On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for pushing this! :)

On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <ph...@chromium.org> wrote:

TL;DR: We'd like to set up a deprecation trial for the following feature from M109 to M112.

What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent?

Sorry I didn't make it clear.  We want to start the enforcement of preflights from M109, but also set up a deprecation trial that websites can sign up if they're affected and need time to fix it.

 

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

Can you clarify who "them" is? Is it URLs that fail the preflight?

Yes, the URLs. Also, to be precise, there are still a tiny portion of URLs that might be legit, which is why we wanted to set up a deprecation trial.

[Yoav Weiss]

On Wed, Oct 5, 2022 at 11:30 AM Jonathan Hao <ph...@chromium.org> wrote:

On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for pushing this! :)

On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <ph...@chromium.org> wrote:

TL;DR: We'd like to set up a deprecation trial for the following feature from M109 to M112.

What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent?

Sorry I didn't make it clear.  We want to start the enforcement of preflights from M109, but also set up a deprecation trial that websites can sign up if they're affected and need time to fix it.

I think it'd be better to send a separate intent to remove that functionality, to make it obvious to observers that we're talking about a removal.

Did current preflight failures go through deprecation reports or some other means to inform relevant developers?

Do we have means to outreach to impacted developers and inform them about the deprecation trial? Also, might be better to have the trial enabled before going ahead with the removal.

+Andre Bandarra - FYI  

[Titouan Rigoudy]

On Wed, Oct 5, 2022 at 12:00 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Oct 5, 2022 at 11:30 AM Jonathan Hao <ph...@chromium.org> wrote:

On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for pushing this! :)

On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <ph...@chromium.org> wrote:

TL;DR: We'd like to set up a deprecation trial for the following feature from M109 to M112.

What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent?

Sorry I didn't make it clear.  We want to start the enforcement of preflights from M109, but also set up a deprecation trial that websites can sign up if they're affected and need time to fix it.

I think it'd be better to send a separate intent to remove that functionality, to make it obvious to observers that we're talking about a removal.

Sure, we can do that.

 

Did current preflight failures go through deprecation reports or some other means to inform relevant developers?

No deprecation reports, because it would reveal cross-origin information to the fetch client. We surface warnings in DevTools issues and network panels instead. 

 

Do we have means to outreach to impacted developers and inform them about the deprecation trial?

We have consulted the list of impacted websites through UKMs and found that the majority of uses (out of ~0.1% of page visits affected) look illegitimate - those seem to be precisely the kind of requests we wish to prevent with this change. Out of the remaining websites, only a couple stood out as worth reaching out to given usage metrics. We tried to reach out and finally decided against it for reasons I can explain off-list.

Instead, we are updating the PNA preflight blog post on developer.chrome.com to mention the rollout timeline and deprecation trial.

Also, might be better to have the trial enabled before going ahead with the removal.

For sure. We would like to start the trial as soon as we gather 3 LGTMs here, though it will be useless until 109 rolls out with enforcement enabled. At that point, developers will be able to use dev and beta builds to make sure their websites are correctly enrolled in the trial before stable rolls out.

Cheers,

Titouan

[Yoav Weiss]

LGTM for a deprecation trial M109-M112 inclusive, assuming the removal intent passes.

On Wed, Oct 5, 2022 at 3:19 PM Titouan Rigoudy <tit...@google.com> wrote:

On Wed, Oct 5, 2022 at 12:00 PM Yoav Weiss <yoav...@chromium.org> wrote:

On Wed, Oct 5, 2022 at 11:30 AM Jonathan Hao <ph...@chromium.org> wrote:

On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for pushing this! :)

On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <ph...@chromium.org> wrote:

TL;DR: We'd like to set up a deprecation trial for the following feature from M109 to M112.

What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent?

Sorry I didn't make it clear.  We want to start the enforcement of preflights from M109, but also set up a deprecation trial that websites can sign up if they're affected and need time to fix it.

I think it'd be better to send a separate intent to remove that functionality, to make it obvious to observers that we're talking about a removal.

Sure, we can do that.

 

Did current preflight failures go through deprecation reports or some other means to inform relevant developers?

No deprecation reports, because it would reveal cross-origin information to the fetch client. We surface warnings in DevTools issues and network panels instead. 

 

Do we have means to outreach to impacted developers and inform them about the deprecation trial?

We have consulted the list of impacted websites through UKMs and found that the majority of uses (out of ~0.1% of page visits affected) look illegitimate - those seem to be precisely the kind of requests we wish to prevent with this change. Out of the remaining websites, only a couple stood out as worth reaching out to given usage metrics. We tried to reach out and finally decided against it for reasons I can explain off-list.

Instead, we are updating the PNA preflight blog post on developer.chrome.com to mention the rollout timeline and deprecation trial.

Also, might be better to have the trial enabled before going ahead with the removal.

For sure. We would like to start the trial as soon as we gather 3 LGTMs here, though it will be useless until 109 rolls out with enforcement enabled. At that point, developers will be able to use dev and beta builds to make sure their websites are correctly enrolled in the trial before stable rolls out.

You need 3 LGTMs on the removal, but only one here.

[Titouan Rigoudy]

Great, thanks!