Request for Deprecation Trial: Restrict "private network requests" for subresources to secure contexts.

128 views
Skip to first unread message

Titouan Rigoudy

unread,
Jun 28, 2021, 6:48:46 AMJun 28
to blink-dev

Contact emails

tit...@chromium.orgcl...@chromium.orgmk...@chromium.orgva...@chromium.org

Explainer

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

Specification

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

API spec

Yes

Design docs


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

Summary

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



Blink component

Blink>SecurityFeature>CORS

TAG review

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

TAG review status

Under way

Risks



Interoperability and Compatibility

No interoperability risks. Compatibility risk is small but non-negligible. UseCounters show ~0.1% of page visits 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: Under consideration (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: Negative (https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit) Some websites, broadly falling in the category of controller webapps for IoT devices, find this change incompatible with their use cases. While most use cases can be solved with tailored workarounds, some may still require further engagement.

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.


Since this deprecation only affects non-secure contexts, however, this Deprecation Trial would need to allow non-secure/HTTP origins to sign up. This is a departure from established practice where Origin Trials are scoped to secure/HTTPS origins only. While this may open the door to silliness due to the lack of authentication, it seems inevitable that Deprecation Trials allow HTTP origins to sign up. Indeed more and more features of the Web Platform will be deprecated over time as their access is restricted to secure contexts. Each of those deprecations will require a similar setup. Note that there is no technical obstacle to this, see the discussion here.



Goals for experimentation

It seems that many developers have not noticed the upcoming launch despite outreach efforts, and will likely only notice once Chrome ships the secure context restriction. Thus delaying the launch by a few milestones to offer more breathing room to the currently-aware developers would not mitigate the risk when we ship the next time. A Deprecation Trial seems like the logical next step. This would allow us to protect the vast majority of users of the web by at least requiring attackers to sign up for the trial, itself a deterrent. Simultaneously, it would give enough time to legitimate websites to work around the new restriction. Finally, it would allow more time for discussions should our planned solutions fail to adequately address developers’ concerns.



Ongoing technical constraints

The Origin Trial will only support setting tokens via headers, and not via a <meta> tag. This is because the opt-in status of a given document must be known at commit time, before the document has started being parsed. This is similar to the existing SharedArrayBuffer deprecation trial. See also details here.

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, Chrome OS, Android, and Android WebView)?

Yes

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

Not yet. Implementation is being finalized, now that WPT RFC 72 has finally been implemented with WPT PR #28870.

Flag name

BlockInsecurePrivateNetworkRequests

Tracking bug

https://crbug.com/986744

Launch bug

https://crbug.com/1129801

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5436853517811712

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ
Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/EeGg7TxW6U4/m/7ZvqAqHLAwAJ
Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/cPiRNjFoCag/m/DxEEN9-6BQAJ


This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
Jun 28, 2021, 9:27:16 AMJun 28
to Titouan Rigoudy, blink-dev
Do I understand correctly that in parallel to this deprecation trial, you'd also remove the private network access to non-secure contexts from origins that aren't part of the trial? (per the I2S)
Also, what are the experimentation timelines?

On Mon, Jun 28, 2021 at 12:48 PM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:

Contact emails

tit...@chromium.orgcl...@chromium.orgmk...@chromium.orgva...@chromium.org

Explainer

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

Specification

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

API spec

Yes

Design docs


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

Summary

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



Blink component

Blink>SecurityFeature>CORS

TAG review

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

TAG review status

Under way

Seems like it's resolved :)
 
--
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/CAPATO9eQJqk4Uss3_3fVmskEsPfVXF404Jfgp-17k60kkJkA5g%40mail.gmail.com.

Titouan Rigoudy

unread,
Jun 28, 2021, 10:13:42 AMJun 28
to Yoav Weiss, Yutaka Hirano, blink-dev
On Mon, Jun 28, 2021 at 3:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
Do I understand correctly that in parallel to this deprecation trial, you'd also remove the private network access to non-secure contexts from origins that aren't part of the trial? (per the I2S)

Exactly. This trial would preserve the ability for certain signed-up websites to delay the deprecation for a few milestones.
 
Also, what are the experimentation timelines?

+Yutaka Hirano from WebTransport tells me they are aiming to ship in M96. I think it would be reasonable to run the trial for 2 more milestones after that. So, we would run this trial until M99 (exclusive).
 
On Mon, Jun 28, 2021 at 12:48 PM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:

Contact emails

tit...@chromium.orgcl...@chromium.orgmk...@chromium.orgva...@chromium.org

Explainer

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

Specification

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

API spec

Yes

Design docs


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

Summary

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



Blink component

Blink>SecurityFeature>CORS

TAG review

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

TAG review status

Under way

Seems like it's resolved :)

Mostly, indeed. It reminds me that I should poke them now that the IETF and Martin Thomson's concerns are resolved.

Yoav Weiss

unread,
Jun 28, 2021, 10:18:25 AMJun 28
to Titouan Rigoudy, Yutaka Hirano, blink-dev
LGTM to run a deprecation trial M93-M98 (inclusive).



On Mon, Jun 28, 2021 at 4:13 PM Titouan Rigoudy <tit...@google.com> wrote:
On Mon, Jun 28, 2021 at 3:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
Do I understand correctly that in parallel to this deprecation trial, you'd also remove the private network access to non-secure contexts from origins that aren't part of the trial? (per the I2S)

Exactly. This trial would preserve the ability for certain signed-up websites to delay the deprecation for a few milestones.
 
Also, what are the experimentation timelines?

+Yutaka Hirano from WebTransport tells me they are aiming to ship in M96. I think it would be reasonable to run the trial for 2 more milestones after that. So, we would run this trial until M99 (exclusive).

IIRC, WebTransport would provide the alternative implementation. Is that correct?

Titouan Rigoudy

unread,
Jun 29, 2021, 5:09:52 AMJun 29
to Yoav Weiss, Yutaka Hirano, blink-dev
On Mon, Jun 28, 2021 at 4:18 PM Yoav Weiss <yoav...@chromium.org> wrote:
LGTM to run a deprecation trial M93-M98 (inclusive).

Thanks!

On Mon, Jun 28, 2021 at 4:13 PM Titouan Rigoudy <tit...@google.com> wrote:
On Mon, Jun 28, 2021 at 3:27 PM Yoav Weiss <yoav...@chromium.org> wrote:
Do I understand correctly that in parallel to this deprecation trial, you'd also remove the private network access to non-secure contexts from origins that aren't part of the trial? (per the I2S)

Exactly. This trial would preserve the ability for certain signed-up websites to delay the deprecation for a few milestones.
 
Also, what are the experimentation timelines?

+Yutaka Hirano from WebTransport tells me they are aiming to ship in M96. I think it would be reasonable to run the trial for 2 more milestones after that. So, we would run this trial until M99 (exclusive).

IIRC, WebTransport would provide the alternative implementation. Is that correct?

Exactly.

Cheers,
Titouan

Titouan Rigoudy

unread,
Aug 13, 2021, 6:07:07 AMAug 13
to Yoav Weiss, Yutaka Hirano, blink-dev
Hi API owners,

We hit a snag trying to roll ship this trial in M93, and delayed to M94. Details at the end for those interested.

Separately, given the switch from a 6-week to a 4-week release cadence, I believe the maximum trial length in milestones should be extended to keep a similar length in calendar days. Instead of 5 milestones, it seems logical to allow for 7 milestones instead.

In addition, WebTransport implementers tell me that the server-side situation is not yet sorted out. There is no easy off-the-shelf WebTransport server for developers to use just yet. It will take some time for the ecosystem to converge on a standard solution or two.

Overall, I would like to request approval to run this deprecation trial from 94 to 101 (inclusive). This would give developers until the end of March 2022 to migrate.

Details about the delay follow:

The reason is that some developers run web apps inside intranets that clients access through literal IP addresses (e.g. http://192.168.1.42). A Deprecation Trial would require them to register tokens for each and every deployment with a distinct IP address, then update the servers to serve those tokens. This being in healthcare, updating servers is hard and comes with a lot of red tape. In effect, it was practically impossible for them to integrate with the trial framework in time.

This deprecation has thus been down-scoped to cover only private network requests made from *public* websites. Requests made from *private* websites, such as the ones described above, can be tackled later.

Cheers,
Titouan

Titouan Rigoudy

unread,
Aug 25, 2021, 4:09:05 AMAug 25
to Yoav Weiss, Yutaka Hirano, blink-dev
Hi there,

Any thoughts? We'd like to announce this trial in a blog post prior to beta promotion tomorrow.

Cheers,
Titouan

Yoav Weiss

unread,
Aug 25, 2021, 6:41:11 AMAug 25
to Titouan Rigoudy, Yutaka Hirano, blink-dev
Apologies for the delay..

LGTM to run the deprecation trial M94-M101

Titouan Rigoudy

unread,
Aug 25, 2021, 7:50:25 AMAug 25
to Yoav Weiss, Yutaka Hirano, blink-dev
No worries, thanks for the reply! We'll announce that then.

Cheers,
Titouan
Reply all
Reply to author
Forward
0 new messages