Intent to Extend Deprecation Trial: Restrict "private network requests" for subresources from public websites to secure contexts.

[Emily Stark]

Contact emails

est...@google.com, jdeb...@google.com, dad...@google.com, l...@chromium.org, tit...@chromium.org, cl...@chromium.org, mk...@chromium.org, va...@chromium.org

Explainer

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

Specification

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

Design docs

https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64

Summary

Requires that private network requests for subresources from public websites may only be initiated from a secure context. Examples include internet to intranet requests and internet to loopback requests. This is a first step towards fully implementing Private Network Access: https://wicg.github.io/private-network-access/

Blink component

Blink>SecurityFeature>CORS>PrivateNetworkAccess

TAG review

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

TAG review status

Issues addressed

Chromium Trial Name

PrivateNetworkAccessNonSecureContextsAllowed

Link to origin trial feedback summary

https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?usp=sharing&resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ

Origin Trial documentation link

https://developer.chrome.com/blog/private-network-access-update/

WebFeature UseCounter name

kPrivateNetworkAccessNonSecureContextsAllowedDeprecationTrial

Risks

Interoperability and Compatibility

No interoperability risks. Compatibility risk is small but non-negligible. UseCounters show ~0.1% of page visit making use of this feature. Direct outreach to the largest users per UKM data revealed no objections to this launch. Rolling this deprecation out to beta per the previous I2S resulted in more feedback about the compatibility risk and the need for a time extension. See the following doc for an extensive discussion: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit

Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143) Tentatively positive, but no formal position yet.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)

Web developers: Mixed signals (https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) In our recent survey, most of websites are able to migrate if our new permission prompt can be landed as a way for them to relax mixed content checks. https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 ------------ Some websites, broadly falling in the category of controller webapps for IoT devices, find this change incompatible with their use cases. While many use cases can be solved with specific workarounds, some still require further engagement.

Other signals:

Activation

Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. The initial launch in M92 was delayed due to compatibility risks surfaced during the rollout to beta. See this doc for a lot more details: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit

Security

This change should be security-positive.

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?

Goals for experimentation

Reason this experiment is being extended

The blocker to shipping this feature is that some websites can't create HTTPS connections to subresources on the private network due to various constraints (e.g., unable to obtain a publicly trusted HTTPS certificate). A permission prompt is in development (https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ) to allow such subresources to be loaded over HTTP (whereas they would usually be blocked by mixed content rules). However, the permission prompt currently only works for fetch() and does not work in iframes, thus we need to investigate whether we need to support use cases not supported by the current implementation. The overall Private Network Access project is also currently being transitioned between teams, so the extension request includes some time for handoff/rampup.

Ongoing technical constraints

None.

Debuggability

When a request is made that violates this restriction and the feature is not enabled, three things happen: 1. A warning message is logged to the DevTools console. 2. A deprecation report is filed against the initiator website's Reporting API, if so configured. 3. An issue is surfaced in the DevTools Issues panel. Likewise, when the feature is enabled and a request is blocked, the same happens except that the message logged to the DevTools console is an error and its text is slightly different. The devtools network panel shows information about the source and remote address spaces at play.

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

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/fetch/private-network-access?label=master&label=experimental&aligned

Flag name on chrome://flags

BlockInsecurePrivateNetworkRequests

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://crbug.com/986744

Launch bug

https://crbug.com/1129801

Estimated milestones

Shipping on desktop	127
Origin trial desktop first	94
Origin trial desktop last	126
Origin trial extension 1 end milestone	126
Origin trial extension 5 end milestone	132
Origin trial extension 6 end milestone	126
DevTrial on desktop	86

OriginTrial Android last	126
OriginTrial Android first	94
DevTrial on Android	86

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5436853517811712?gate=5187028487766016

Links to previous Intent discussions

Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/vlDZXlPb00k/m/1421ACiuAAAJ
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Extend Experiment 6: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck
Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/JPD001kqeck

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi Emily,

A few questions inline:

Can you speak to the number of sites in the largest users group? Is it dozens of sites? Hundreds? Presumably they're all enrolled in the DT?

Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143) Tentatively positive, but no formal position yet.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)

Web developers: Mixed signals (https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) In our recent survey, most of websites are able to migrate if our new permission prompt can be landed as a way for them to relax mixed content checks. https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 ------------ Some websites, broadly falling in the category of controller webapps for IoT devices, find this change incompatible with their use cases. While many use cases can be solved with specific workarounds, some still require further engagement.

Other signals:

Activation

Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. The initial launch in M92 was delayed due to compatibility risks surfaced during the rollout to beta. See this doc for a lot more details: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit

Security

This change should be security-positive.

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?

Goals for experimentation

Reason this experiment is being extended

The blocker to shipping this feature is that some websites can't create HTTPS connections to subresources on the private network due to various constraints (e.g., unable to obtain a publicly trusted HTTPS certificate). A permission prompt is in development (https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ) to allow such subresources to be loaded over HTTP (whereas they would usually be blocked by mixed content rules). However, the permission prompt currently only works for fetch() and does not work in iframes, thus we need to investigate whether we need to support use cases not supported by the current implementation. The overall Private Network Access project is also currently being transitioned between teams, so the extension request includes some time for handoff/rampup.

I'm slightly confused on the timing - https://chromestatus.com/feature/5954091755241472 states that we shipped the permission prompt in 124 - is that not the case?

What are the non-fetch cases that might need to be supported? XHR? Sub-resource loads? Both? Something else? Is it feasible to design a DT that addresses the non-fetch() use cases?

Also, could you clarify what milestones you're requesting a renewal for? The table below is hard for me to parse (e.g., extension 5 ending in 132; extension 6 ending in 126).

--
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/CAPP_2Sbhrsrmmk5ZTwkxkuwT6_iEs4QPNGNYTL9u_7ODmEb3Vw%40mail.gmail.com.

[Emily Stark]

(Apologies for the slow response, we had some OOOs)

I've requested access to the OT data so I can't say for sure yet, but in the meantime, my impression is that we're roughly talking about hundreds of sites. The breakage of ending the deprecation trial would be quite small in terms of affected page loads, but there are legitimate use cases for nonsecure subresource requests to the private network that we're trying to accomodate because they don't have an alternative/workaround.

Gecko: Closed Without a Position (https://github.com/mozilla/standards-positions/issues/143) Tentatively positive, but no formal position yet.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html)

Web developers: Mixed signals (https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) In our recent survey, most of websites are able to migrate if our new permission prompt can be landed as a way for them to relax mixed content checks. https://docs.google.com/spreadsheets/d/1z5ZdCslNCnSVR7TNlUTHjSvunMFmT_9G9NOx8-O78-I/edit?resourcekey=0-DITlG8tDuFDWHiBUHnlSoQ#gid=309953809 ------------ Some websites, broadly falling in the category of controller webapps for IoT devices, find this change incompatible with their use cases. While many use cases can be solved with specific workarounds, some still require further engagement.

Other signals:

Activation

Developers of non-secure sites that rely upon local servers will need to upgrade to HTTPS. This might cause some complications, as mixed-content checks will begin to apply. Chrome carves out HTTP access to loopback (as perhttps://w3c.github.io/webappsec-secure-contexts/#localhost), which is a release valve for folks who don't want to go through the effort of securely-distributing certs for local servers. The initial launch in M92 was delayed due to compatibility risks surfaced during the rollout to beta. See this doc for a lot more details: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit

Security

This change should be security-positive.

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?

Goals for experimentation

Reason this experiment is being extended

The blocker to shipping this feature is that some websites can't create HTTPS connections to subresources on the private network due to various constraints (e.g., unable to obtain a publicly trusted HTTPS certificate). A permission prompt is in development (https://groups.google.com/a/chromium.org/g/blink-dev/c/sL15TKGmXqM/m/rD0SF8sQBwAJ) to allow such subresources to be loaded over HTTP (whereas they would usually be blocked by mixed content rules). However, the permission prompt currently only works for fetch() and does not work in iframes, thus we need to investigate whether we need to support use cases not supported by the current implementation. The overall Private Network Access project is also currently being transitioned between teams, so the extension request includes some time for handoff/rampup.

I'm slightly confused on the timing - https://chromestatus.com/feature/5954091755241472 states that we shipped the permission prompt in 124 - is that not the case?

What are the non-fetch cases that might need to be supported? XHR? Sub-resource loads? Both? Something else? Is it feasible to design a DT that addresses the non-fetch() use cases?

The permission prompt for fetch() requests did indeed ship in M124, but there are feature requests to support subresouce loads from HTML tags (<img>, <iframe>, etc.) as well as to support permission delegation to iframes. These outstanding feature requests are described in this (Google-internal) doc: https://docs.google.com/document/d/1r4MnGtCmXvt-sDdp3RiaYLkdTcLKPjmmL4ky4TCOMS0/edit?tab=t.0#heading=h.1fxgtnya8b50

So we're requesting an extension to this DT (which allows enrolled nonsecure origins to make private network requests) to give us time to implement those feature requests. That will allow the origins enrolled in this DT to migrate to secure origins and use the permission prompt (and related feature requests) to make private network requests to nonsecure origins.

I don't think I understand your last question ("Is it feasible to design a DT...?"), could you clarify?

Also, could you clarify what milestones you're requesting a renewal for? The table below is hard for me to parse (e.g., extension 5 ending in 132; extension 6 ending in 126).

I've been staring at Chrome Status for a while and am honestly pretty confused as to how that table came to be. We're requesting a renewal in M127, to last until M132.

[Emily Stark]

Update: it looks like there are ~1000 sites registered in the DT.

[Yoav Weiss (@Shopify)]

LGTM to extend the deprecation trial M127-132, but it'd be good to have meaningful progress by then to reduce the number of folks that use it..

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPP_2SaQKCfQCsMpcJUHDYU%3Dx%3Dc5uuwBVyesqeBheMrAma%2B7Zg%40mail.gmail.com.