Intent to Ship: Restrict "private network requests" for subresources to secure contexts.

755 views
Skip to first unread message

Titouan Rigoudy

unread,
Nov 20, 2020, 4:47:51 PM11/20/20
to blink-dev

Contact emails

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

Explainer

https://github.com/WICG/cors-rfc1918/blob/master/explainer.md

Specification

https://wicg.github.io/cors-rfc1918/

API spec

Yes

Design docs

https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/edit

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 CORS-RFC1918: https://chromestatus.com/feature/5733828735795200


Blink component

Blink

TAG review

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

TAG review status

Pending

Risks

Note that the above metrics almost certainly overestimate the affected page loads as some frame hierarchies currently confuse Blink: https://crbug.com/1136028. Previous estimates based on less precise metrics suggested that this was much less widespread.

In any case, we are waiting for more detailed metrics gathered in M87 to finalize our plan to ship the feature. We have an enterprise opt-out through enterprise policies. This is a bit unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources, but necessary.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

WebKit: No signal

Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentally-related WebKit bug is representative.

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.


See also the discussion with Plex, which embed videos served from the private network into their public webapp: https://github.com/WICG/cors-rfc1918/issues/23. We are fairly confident that other such issues can be resolved on a case-by-case basis.

Security

This change should be security-positive.



Debuggability

When blocking a request due to a secure-context restriction, we'll add a helpful message to the console. The devtools network panel will show information about the source and remote address spaces at play.



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

No. Further tests are on their way. Full coverage will require a change to WPTs, RFC currently under review: https://github.com/web-platform-tests/rfcs/pull/72

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


This intent message was generated by Chrome Platform Status.

yo...@yoav.ws

unread,
Nov 23, 2020, 4:21:27 AM11/23/20
to blink-dev, Titouan Rigoudy
On Friday, November 20, 2020 at 10:47:51 PM UTC+1 Titouan Rigoudy wrote:

Contact emails

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

Explainer

https://github.com/WICG/cors-rfc1918/blob/master/explainer.md

Specification

https://wicg.github.io/cors-rfc1918/

API spec

Yes

Design docs

https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/edit

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.


To clarify, the network requests to those private networks will be done over non-secure HTTP, and will not be considered mixed content?
 

This is a first step towards fully implementing CORS-RFC1918: https://chromestatus.com/feature/5733828735795200


Blink component

Blink

TAG review

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

TAG review status

Pending

Risks

Note that the above metrics almost certainly overestimate the affected page loads as some frame hierarchies currently confuse Blink: https://crbug.com/1136028. Previous estimates based on less precise metrics suggested that this was much less widespread.

In any case, we are waiting for more detailed metrics gathered in M87 to finalize our plan to ship the feature. We have an enterprise opt-out through enterprise policies. This is a bit unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources, but necessary.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

WebKit: No signal

Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentally-related WebKit bug is representative.

My read of that thread is that folks would want to keep the possibility to access either localhost or local servers, but that the restriction of that access to secure contexts would not be a huge blocker for their use-cases. Am I understanding correctly?

Titouan Rigoudy

unread,
Nov 23, 2020, 9:57:20 AM11/23/20
to yo...@yoav.ws, blink-dev
Hi Yoav,

Thanks for the reply, see my answers below.

On Mon, Nov 23, 2020 at 4:21 AM yo...@yoav.ws <yo...@yoav.ws> wrote:


On Friday, November 20, 2020 at 10:47:51 PM UTC+1 Titouan Rigoudy wrote:

Contact emails

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

Explainer

https://github.com/WICG/cors-rfc1918/blob/master/explainer.md

Specification

https://wicg.github.io/cors-rfc1918/

API spec

Yes

Design docs

https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/edit

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.


To clarify, the network requests to those private networks will be done over non-secure HTTP, and will not be considered mixed content?

We are not relaxing mixed content restrictions for this launch. There was an existing carveout for http://localhost, so public and private https websites will still be able to make requests to http://localhost without running into mixed content. However, public https websites are not able to make requests to private websites served over http due to mixed content. Fixing this requires serving the private website with https, and thus having proper certificates in place.

 

This is a first step towards fully implementing CORS-RFC1918: https://chromestatus.com/feature/5733828735795200


Blink component

Blink

TAG review

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

TAG review status

Pending

Risks

Note that the above metrics almost certainly overestimate the affected page loads as some frame hierarchies currently confuse Blink: https://crbug.com/1136028. Previous estimates based on less precise metrics suggested that this was much less widespread.

In any case, we are waiting for more detailed metrics gathered in M87 to finalize our plan to ship the feature. We have an enterprise opt-out through enterprise policies. This is a bit unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources, but necessary.



Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

WebKit: No signal

Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentally-related WebKit bug is representative.

My read of that thread is that folks would want to keep the possibility to access either localhost or local servers, but that the restriction of that access to secure contexts would not be a huge blocker for their use-cases. Am I understanding correctly?

I believe so. I think this was written with a full CORS-RFC1918 launch in mind, not just the secure context restriction part. I should have double-checked this entry was still up-to-date, sorry!

yo...@yoav.ws

unread,
Nov 27, 2020, 10:15:09 AM11/27/20
to blink-dev, Titouan Rigoudy, blink-dev, yo...@yoav.ws
When do you expect to have more accurate metrics?
1% of page views is a lot...
Also - do you know what the distribution of that usage over sites is? 
Seems like the metrics are too recent to have landed in an HA run, which is a shame, as that would've made looking at what the responsible sites are easier.

Titouan Rigoudy

unread,
Dec 3, 2020, 1:46:44 PM12/3/20
to yo...@yoav.ws, blink-dev
Hi Yoav,

Great questions! We expect to have more accurate metrics once we fix inheritance issues, for which we are targeting M89.

I think an explanation would help. The problem right now is that the numbers are dominated by requests made from the "unknown" address space, which account for ~1% of page visits [1]. Requests made from non-unknown address spaces account for ~0.08% of page visits [2]. We have decided not to block requests coming from the "unknown" address space as part of this launch. So far this means that only ~0.08% of page visits would be affected.

We suspect that the metric imbalance is due to a bug in the address space calculation logic. Iframes whose content is not loaded from the network (`about:blank`, `about:srcdoc`, `data:`, `blob:`, `filesystem:` and `javascript:`) are incorrectly classified as coming from the "unknown" address space instead of inheriting an address space from their parent/navigation initiator/what have you. Say a private website embeds an `about:blank` iframe and then `document.write()`s some HTML requesting an image from its own origin, we will classify that as a request from "unknown" to "private", when it should be "private" to "private" and thus unaffected by this launch.

This intuition is bolstered by the fact that the number of private network requests coming from non-unknown address spaces is an order of magnitude lower. It seems unlikely that 92% of private network requests on Windows are coming from iframes behaving as described in the scenario above, though in fairness it is possible.

All in all this means we suspect that once we fix address space inheritance, we will see that most of these requests were incorrectly classified as problematic. Some might also turn out to be bad ads or malicious injected scripts trying to poke at users' private networks, which we would like to block.

If that does not turn out to be the case, we will re-evaluate the decision to ship anyway.

As for the distribution: we have UKM integration which has highlighted a few external websites that seem to be relying on this feature. So far we have identified no more than a handful legitimate cases. We are waiting for 87 to roll out to 100% of stable to gather more complete data. In the meantime, we have engaged with DevRel to start reaching out to help affected websites work around the upcoming restriction.

Cheers,
Titouan

Daniel Bratell

unread,
Dec 3, 2020, 3:48:06 PM12/3/20
to Titouan Rigoudy, yo...@yoav.ws, blink-dev

I think having the whole compatibility picture, including the current dark matter in the "unknown" address space, is required before judging the impact the web will see from this. Especially since something that is more or less a bug fix (change "unknown" to something more correct) could otherwise expand the usage beyond what is tolerable.

My hope is that your suspicions are correct, but I think we should see what the data says after your improvements to the classifications.

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

Titouan Rigoudy

unread,
Dec 9, 2020, 9:30:22 AM12/9/20
to Daniel Bratell, yo...@yoav.ws, blink-dev
Hi Daniel,

That's fair. We are aiming to fix our metrics by M89. Once that's rolled out, we'll analyze the metrics some more and I'll get back to this thread with analysis results.

Cheers,
Titouan

yo...@yoav.ws

unread,
Dec 9, 2020, 9:52:17 AM12/9/20
to blink-dev, Titouan Rigoudy, yo...@yoav.ws, blink-dev, Daniel Bratell
The scenario that concerns me here is the following:
http://vendor.example.com is currently used to control a certain home appliance, which it does over plain-text HTTP.
Once that restriction will be in effect, it would need to upgrade the site to https://vendor.example.com, which the vendor can easily do, but would also need to upgrade the appliance to have a local address and provide a cert for it, which presumably is hard and would require work from the local IT person (AKA the customer).

Is the above a reasonable scenario? Did I understand it correctly?
Do we know of appliances that fit this model? Do we know of ones that won't be able to upgrade?

Titouan Rigoudy

unread,
Dec 9, 2020, 10:19:57 AM12/9/20
to yo...@yoav.ws, blink-dev, Daniel Bratell
Hi Yoav,

That is a very reasonable scenario indeed, and one that we have considered already in the case of Plex [1]. In their case there is a reasonable workaround, since their local appliance also serves a copy of the webapp. In general there are a couple strategies a service can use to work around the upcoming restriction: flipping the embedding, navigating instead of fetching subresources, or using webtransport to sidestep the PKI.

We have started analyzing UKM data to identify other similarly-impacted services. So far we have only noticed a couple more seemingly-legitimate usecases. We are planning to reach out to all affected parties through DevRel. We also put out a web.dev article [2] requesting feedback from services that find themselves in a position like you described.

Cheers,
Titouan

Chris Harrelson

unread,
Dec 9, 2020, 10:24:06 PM12/9/20
to Titouan Rigoudy, yo...@yoav.ws, blink-dev, Daniel Bratell
What about router configuration pages? My ASUS home router, for example, is accessed by a non-secure-only URL at "router.asus.com" (which is of course intercepted locally by the router). Since the top level URL in that case is non-secure, this intent does not apply to it, right? Is it generally the case that route configuration pages are like mine, and won't be affected by this intent?

Titouan Rigoudy

unread,
Dec 10, 2020, 4:29:17 AM12/10/20
to Chris Harrelson, yo...@yoav.ws, blink-dev, Daniel Bratell
Hi Chris,

What matters is not the domain name of the website but rather the IP address from which it was loaded. If the router serves its own configuration website (responds to the DNS request with its own private IP address), then the website should not make cross-origin / cross-network requests. Thus it should be unaffected by this intent.

In my experience, router configuration pages are indeed like yours: the router serves its own admin interface.

Cheers,
Titouan

Chris Harrelson

unread,
Dec 10, 2020, 11:36:11 AM12/10/20
to Titouan Rigoudy, yo...@yoav.ws, blink-dev, Daniel Bratell
On Thu, Dec 10, 2020 at 1:29 AM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:
Hi Chris,

What matters is not the domain name of the website but rather the IP address from which it was loaded. If the router serves its own configuration website (responds to the DNS request with its own private IP address), then the website should not make cross-origin / cross-network requests. Thus it should be unaffected by this intent.

Makes sense, thanks for the clarification.

Chris Harrelson

unread,
Dec 10, 2020, 4:34:29 PM12/10/20
to Titouan Rigoudy, yo...@yoav.ws, blink-dev, Daniel Bratell
OK thanks. The API owners reviewed this intent today, and while we saw no problems other than compat data, will wait for the M89 data you mentioned before making a decision.

Titouan Rigoudy

unread,
Dec 11, 2020, 4:44:11 AM12/11/20
to Chris Harrelson, yo...@yoav.ws, blink-dev, Daniel Bratell
Hi Chris,

Thanks for the update. I'll come back with better data in hand sometime in early March, then :)

Cheers,
Titouan

Lutz Vahl

unread,
Jan 12, 2021, 9:20:26 AMJan 12
to Chris Harrelson, yo...@yoav.ws, blink-dev, Daniel Bratell, Titouan Rigoudy
Hi Chris,

Thanks for the info! While we're waiting for the metrics to roll out we crafted a plan how to ship the change as soon as we got the approval. Part of the plan is to raise a deprecation issue in DevTools letting the developers know that requests will get blocked soon. As this will help us bring the use counters down we're thinking about adding such a warning already in M90 (Stable release 2021-04-13). 
Would this be ok even if the I2S is not approved by then as the API owners didn't see any other problems than the compat data?

Please let me know if you've any concerns.

Cheers,
 Lutz


Chris Harrelson

unread,
Jan 12, 2021, 11:55:36 AMJan 12
to Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell, Titouan Rigoudy
Hi,

Adding a deprecation message that the feature will be removed in M91 might be fine... Are you pretty sure that the data will show an actually-impacted fraction of page loads much less than 1%? What does the data on canary and dev indicate?

Lutz Vahl

unread,
Jan 12, 2021, 12:51:43 PMJan 12
to Chris Harrelson, yo...@yoav.ws, blink-dev, Daniel Bratell, Titouan Rigoudy
Hi Chris,

The new metrics are currently only available on canary and we know from earlier analysis that canary data was not reflecting the same distribution as dev/stable. Therefore we're not sure yet! We'll monitor the metrics as soon as they hit additional channels. But we're thinking about adding the warning in M90 (CL adding it needs to land before 2021-02-25) to let the affected user know about the upcoming change. This will help us to spread the information about the upcoming change and bring the use counter down. Is this fine with you?

The plan is to enable the feature in M92 controlled via finch. Doing so we can monitor the metrics during the rollout and react in case of issues.



Chris Harrelson

unread,
Jan 12, 2021, 1:06:28 PMJan 12
to Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell, Titouan Rigoudy
Hi,

On Tue, Jan 12, 2021 at 9:51 AM Lutz Vahl <va...@chromium.org> wrote:
Hi Chris,

The new metrics are currently only available on canary and we know from earlier analysis that canary data was not reflecting the same distribution as dev/stable.

Right, I get that part. But does the canary data at least look positive?
 
Therefore we're not sure yet! We'll monitor the metrics as soon as they hit additional channels. But we're thinking about adding the warning in M90 (CL adding it needs to land before 2021-02-25) to let the affected user know about the upcoming change. This will help us to spread the information about the upcoming change and bring the use counter down. Is this fine with you?

The problem is that we don't approve deprecations without removal timelines, so we need at least some indication that we're likely to hit the timeline. That's why I was asking about the Canary channel. If the data from Canary looks promising, then your plan sounds good to me.
 

Chris Harrelson

unread,
Jan 14, 2021, 3:35:23 PMJan 14
to Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell, Titouan Rigoudy
The API owners met today, and we're ok with adding the deprecation message targeting M92 removal. Once the UseCounters come in please come back to this thread for final approval. If the UseCounter is too high, we'll need to adjust or remove the deprecation message.

Titouan Rigoudy

unread,
Jan 15, 2021, 4:08:30 AMJan 15
to Chris Harrelson, Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell
Hi Chris,

> Right, I get that part. But does the canary data at least look positive?

Not so far, but we are hopeful that the story will improve by next week. We carried out our plan to fix the known issue with address space calculation and inheritance, but that did not yield the expected improvements in canary data when it started trickling in this week. Turns out, there were more than one bug at play.

Our metrics were:
 1) incorrectly classifying provisional frames' first navigations as originating from the unknown address space
 2) lumping together subresource fetches and navigation fetches

Based on our tests, we are more confident in the correctness of the metrics for subresource fetches only, and would like to start blocking those first. Yesterday I landed a patch in M89 to split up the metrics between subresources and navigations, so that we can evaluate compat risk independently.

> The API owners met today, and we're ok with adding the deprecation message targeting M92 removal. Once the UseCounters come in please come back to this thread for final approval. If the UseCounter is too high, we'll need to adjust or remove the deprecation message.

That's great! I will come back with canary data about subresources in particular when the data is available. I think it would make sense to start displaying a deprecation warning for those only, and start blocking those first. Navigations (including child frame navigations) can be evaluated separately, once metric issues are sorted out?

Cheers,
Titouan

Titouan Rigoudy

unread,
Jan 20, 2021, 10:14:13 AMJan 20
to Chris Harrelson, Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell
Hi friendly API Owners,

I come bearing good news. Canary metric data for subresource fetches looks much better in M89: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=3640110376dac998bbe14d7b9ff5898a

We are down to ~0.1% of page visits that would be affected by this launch, were they to not migrate away from this behavior by M92. Uses of the unknown address space are down to ~0.001% of page visits - these can be excluded from the launch anyway.

I would also like to double check that scoping down the launch to only subresource requests sounds reasonable? Navigations can also be used for CSRF attacks, but the metrics code needs a little more work before we can rely on it for launch decisions.

Cheers,
Titouan

Daniel Bratell

unread,
Jan 21, 2021, 3:36:02 PMJan 21
to Titouan Rigoudy, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, blink-dev

Really good to have gotten rid of the dark matter in the metrics! The range initially was about 0.08 - 1.0%, and now it's about 0.1% (the Canary data you link is Google internal so I have not checked anything myself).

The number 0.1% is still high if it means a service/device/page would be broken, but you don't expect that to be the case come final shipping in the summer? Sorry if I'm asking something that has already been answered, but I can't remember an answer. You were going to reach out to possibly affected services/device makers?

And it's perfect that is is scoped to subresources since that is the part we have been evaluating.

/Daniel

Titouan Rigoudy

unread,
Jan 22, 2021, 4:44:25 AMJan 22
to Daniel Bratell, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, blink-dev
Hi Daniel,

There are a couple reasons I hope that launching this will be OK anyway:
  1. Some of the uses we record are malicious: breaking these pages is our stated goal.
  2. We are gathering data to identify the biggest users of this feature, and will reach out to them directly through DevRel.
  3. We have communicated about this publicly through web.dev, and will show a deprecation warning in DevTools starting in M90.
#2 and #3 should help us bring the use counters down, but #1 means we will never fall below a certain threshold.

Cheers,
Titouan

Yoav Weiss

unread,
Mar 18, 2021, 6:10:45 AMMar 18
to blink-dev, Titouan Rigoudy, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, blink-dev, Daniel Bratell
Any news on the data front?

Hi,

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.
--
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+unsubscribe@chromium.org.

Titouan Rigoudy

unread,
Mar 18, 2021, 6:16:55 AMMar 18
to Yoav Weiss, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
Hi Yoav,

Thanks for asking! I have good news so far. Stable UMA data shows that at most ~0.1% of page visits are affected by this change across platforms: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=1efd0761559b30146db8af342685a3d1
If anything, today's data shows a sharp drop, but that looks like an outlier - maybe a problem with data collection?

I am in the process of analyzing UKM data to identify specific websites we want to reach out to proactively. We have engaged with DevRel to help mediate. I am planning to finalize the list this week.

Cheers,
Titouan


Hi,

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

Yoav Weiss

unread,
Mar 18, 2021, 6:51:30 AMMar 18
to Titouan Rigoudy, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
On Thu, Mar 18, 2021 at 11:16 AM Titouan Rigoudy <tit...@google.com> wrote:
Hi Yoav,

Thanks for asking! I have good news so far. Stable UMA data shows that at most ~0.1% of page visits are affected by this change across platforms: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=1efd0761559b30146db8af342685a3d1
 
That's encouraging! :)

Side question: Why can't we get the same usecounter data on chromestatus.com?

If anything, today's data shows a sharp drop, but that looks like an outlier - maybe a problem with data collection?

I am in the process of analyzing UKM data to identify specific websites we want to reach out to proactively. We have engaged with DevRel to help mediate. I am planning to finalize the list this week.

Analyzing UKM to try and better understand how many different websites are involved sounds like a great plan. Please keep us in the loop on the results.

Titouan Rigoudy

unread,
Mar 18, 2021, 8:04:49 AMMar 18
to Yoav Weiss, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
On Thu, Mar 18, 2021 at 11:51 AM Yoav Weiss <yoav...@chromium.org> wrote:


On Thu, Mar 18, 2021 at 11:16 AM Titouan Rigoudy <tit...@google.com> wrote:
Hi Yoav,

Thanks for asking! I have good news so far. Stable UMA data shows that at most ~0.1% of page visits are affected by this change across platforms: https://uma.googleplex.com/p/chrome/timeline_v2/?sid=1efd0761559b30146db8af342685a3d1
 
That's encouraging! :)

Side question: Why can't we get the same usecounter data on chromestatus.com?

Good question. I am tracking the launch via 3 separate metrics, which all correspond to slightly different behavior covered by this intent. I tend to use the UMA dashboard to aggregate them. Here they are on chromestatus.com:
 
If anything, today's data shows a sharp drop, but that looks like an outlier - maybe a problem with data collection?

I am in the process of analyzing UKM data to identify specific websites we want to reach out to proactively. We have engaged with DevRel to help mediate. I am planning to finalize the list this week.

Analyzing UKM to try and better understand how many different websites are involved sounds like a great plan. Please keep us in the loop on the results.

Will do!

Cheers,
Titouan

Titouan Rigoudy

unread,
May 12, 2021, 6:16:59 AMMay 12
to Yoav Weiss, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
Hi there API owners,

Things have been going pretty well on the metrics and outreach front, so I would like to request approval to ship this in M92. There have been a few notable developments which I would like to highlight.


Design docs


TAG review status

Note that this review covers the whole Private Network Access specification, which extends well beyond the current I2S.

Risks



Interoperability and Compatibility

< 0.1% of page views are currently loading at least one resource from a less-public IP address space

Loads from the "unknown" address space (the previously-discussed "dark matter in the metrics") now affect less than 0.0001% of page views:

In M92, our logic to classify IP addresses into IP address spaces changed slightly as a result of https://github.com/WICG/private-network-access/issues/50. This means that the metrics recorded in M91 (e.g. the chromestatus metrics above) are slightly different than those in M92. Since these metrics represent the occurrence of requests that would be blocked once this ships, the chromestatus metrics are no longer counting affected requests exactly. So far, Dev metrics indicate that the change has had no observable effect on UMA data (Googlers only, sorry):

We will keep an eye on these as the fix rolls out to beta to verify that the above chromestatus metrics can be relied on to make a decision here.


UKM analysis revealed sparse, diffuse usage of this "feature" of the web platform on a variety of websites that mostly did not seem to have a good reason to probe the private network (again, Googlers only, sorry): https://docs.google.com/document/d/14bmunqUEX0TftNI4JDZg_kyv71hpNw7NDZp84jXbyC4/edit


We performed direct outreach to the largest seemingly-legitimate affected websites to inform them of our measurements. None expressed opposition to this intent.

We have an enterprise opt-out through enterprise policies. This is a bit unfortunate, as enterprises are exactly the sort of things that have large local networks full of interesting resources, but necessary.


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

Web developers: Negative (https://bugs.webkit.org/show_bug.cgi?id=171934) Developers running local servers generally want those servers to keep running without alteration. The conversation on a tangentally-related WebKit bug is representative. Discussion with Plex on https://github.com/WICG/private-network-access/issues/23 has reached a slight disagreement, an improvement  compared to the significant disagreements before

Security

This change should be security-positive.



Debuggability

Currently, requests that would be blocked once this ships generate deprecation warnings in the DevTools console and file deprecation reports agains the initiator website's reporting API, if configured. They also generate issue entries in the DevTools issues panel.


Once this ships, blocked requests would be surfaced in DevTools in the console with a descriptive error message and in the network panel.


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

Not yet, but good progress has been made. We have earlier tests in fetch/private-network-access/ that provide coverage for the allowed/blocked distinction, but support for the full matrix of IP address space combinations has been blocked on the implementation of the aforementioned WPT RFC 72. Code for that has landed in Chromium, and a wptrunner PR is out for review. Once that lands, we will be able to write full WPTs.

Cheers,
Titouan

Anne van Kesteren

unread,
May 12, 2021, 6:47:48 AMMay 12
to Titouan Rigoudy, Yoav Weiss, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
On Wed, May 12, 2021 at 12:16 PM 'Titouan Rigoudy' via blink-dev
<blin...@chromium.org> wrote:
> Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143) https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

It's marked as worth prototyping, i.e., we're positive on this.

Titouan Rigoudy

unread,
May 12, 2021, 7:30:18 AMMay 12
to Anne van Kesteren, Yoav Weiss, blink-dev, Chris Harrelson, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
Thanks for the correction Anne!

Cheers,
Titouan 

Chris Harrelson

unread,
May 12, 2021, 11:17:02 AMMay 12
to Titouan Rigoudy, Anne van Kesteren, Yoav Weiss, blink-dev, Lutz Vahl, yo...@yoav.ws, Daniel Bratell
LGTM1 to ship, conditioned on adding WPTs during the shipping process (ok to do it in parallel with shipping).

Good luck, and hope it sticks!

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

Daniel Bratell

unread,
May 13, 2021, 3:08:07 PMMay 13
to Chris Harrelson, Titouan Rigoudy, Anne van Kesteren, Yoav Weiss, blink-dev, Lutz Vahl, yo...@yoav.ws

Titouan, do you know what kind of resources are blocked too? I'm thinking about whether the breakage that remains might be "just" cosmetic.

/Daniel

Alex Russell

unread,
May 13, 2021, 5:48:24 PMMay 13
to blink-dev, Daniel Bratell, ann...@annevk.nl, Yoav Weiss, blink-dev, Lutz Vahl, yo...@yoav.ws, Chris Harrelson, Titouan Rigoudy
Thanks for all the background in this thread all.

We discussed again today at the API OWNERS meeting and the consensus was that this seems like something we're comfortable with modulo a few caveats:
  • Would like to make sure there's a plan for quickly reverting should this go sideways. To that effect, can y'all confirm this will be Finch'd (in Chrome at least) for at least one release?
  • Now that y'all have done the work to characterize potential breakage (thank you so much for that!), do you have a plan for how to watch for potentially bad breakage?
  • Do you have a theory about if/how this might be important in enterprise settings? 
Assuming there's a plan you can share for monitoring for breakage and rolling back from a bad interaction with stable channel, LGTM1.

Thanks again for the data collection and analysis. We know how much work that is, and it's deeply appreciated.

Warmest Regards


On Thursday, May 13, 2021 at 12:08:07 PM UTC-7 Daniel Bratell wrote:

Titouan, do you know what kind of resources are blocked too? I'm thinking about whether the breakage that remains might be "just" cosmetic.

/Daniel

On 2021-05-12 17:16, Chris Harrelson wrote:
LGTM1 to ship, conditioned on adding WPTs during the shipping process (ok to do it in parallel with shipping).

Good luck, and hope it sticks!

On Wed, May 12, 2021 at 4:30 AM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:
Thanks for the correction Anne!

Cheers,
Titouan 

On Wed, May 12, 2021 at 12:47 PM Anne van Kesteren <ann...@annevk.nl> wrote:
On Wed, May 12, 2021 at 12:16 PM 'Titouan Rigoudy' via blink-dev
<blin...@chromium.org> wrote:
> Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143) https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

It's marked as worth prototyping, i.e., we're positive on this.
--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
May 13, 2021, 5:50:57 PMMay 13
to Alex Russell, blink-dev, Daniel Bratell, ann...@annevk.nl, Yoav Weiss, Lutz Vahl, yo...@yoav.ws, Titouan Rigoudy
On Thu, May 13, 2021 at 2:48 PM Alex Russell <sligh...@chromium.org> wrote:
Thanks for all the background in this thread all.

We discussed again today at the API OWNERS meeting and the consensus was that this seems like something we're comfortable with modulo a few caveats:
  • Would like to make sure there's a plan for quickly reverting should this go sideways. To that effect, can y'all confirm this will be Finch'd (in Chrome at least) for at least one release?
  • Now that y'all have done the work to characterize potential breakage (thank you so much for that!), do you have a plan for how to watch for potentially bad breakage?
  • Do you have a theory about if/how this might be important in enterprise settings? 
Assuming there's a plan you can share for monitoring for breakage and rolling back from a bad interaction with stable channel, LGTM1.

Clarification, that's an LGTM2 since I LGTM1ed above. :) 


Thanks again for the data collection and analysis. We know how much work that is, and it's deeply appreciated.

Warmest Regards


On Thursday, May 13, 2021 at 12:08:07 PM UTC-7 Daniel Bratell wrote:

Titouan, do you know what kind of resources are blocked too? I'm thinking about whether the breakage that remains might be "just" cosmetic.

/Daniel

On 2021-05-12 17:16, Chris Harrelson wrote:
LGTM1 to ship, conditioned on adding WPTs during the shipping process (ok to do it in parallel with shipping).

Good luck, and hope it sticks!

On Wed, May 12, 2021 at 4:30 AM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:
Thanks for the correction Anne!

Cheers,
Titouan 

On Wed, May 12, 2021 at 12:47 PM Anne van Kesteren <ann...@annevk.nl> wrote:
On Wed, May 12, 2021 at 12:16 PM 'Titouan Rigoudy' via blink-dev
<blin...@chromium.org> wrote:
> Gecko: No signal (https://github.com/mozilla/standards-positions/issues/143) https://bugzilla.mozilla.org/show_bug.cgi?id=1481298

It's marked as worth prototyping, i.e., we're positive on this.
--
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.

--
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/7bfc5dec-89b3-49c1-a92f-70a18747bc4fn%40chromium.org.

Yoav Weiss

unread,
May 17, 2021, 9:21:42 AMMay 17
to Chris Harrelson, Alex Russell, blink-dev, Daniel Bratell, ann...@annevk.nl, Lutz Vahl, yo...@yoav.ws, Titouan Rigoudy
Hey Titouan!

The (Googler-only) UKM analysis doc surfaces some potential use-cases that I'd be hesitant to break without coordination. Specifically, there's a potential use case in South Korea for coordination with locally installed software, which may or may not be legally mandated. There are also cases mentioned related to gaming and commerce, where it says we'd reach out, but it's unclear what the conclusion for that outreach was.

Can you clarify the above? Do we have confidence that shipping this won't break the web in South Korea and won't hurt use cases that currently have no safer replacement?

Cheers,
Yoav

Titouan Rigoudy

unread,
May 17, 2021, 10:09:07 AMMay 17