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

[Titouan Rigoudy]

Contact emails

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

Interoperability and Compatibility

< 1% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: - https://www.chromestatus.com/metrics/feature/timeline/popularity/3689 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3691 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3693 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3695 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3697

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/143) https://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]

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

Contact emails

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

Interoperability and Compatibility

< 1% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: - https://www.chromestatus.com/metrics/feature/timeline/popularity/3689 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3691 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3693 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3695 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3697

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/143) https://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]

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.org, cl...@chromium.org, mk...@chromium.org, va...@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

Interoperability and Compatibility

< 1% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: - https://www.chromestatus.com/metrics/feature/timeline/popularity/3689 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3691 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3693 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3695 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3697

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/143) https://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]

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]

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

[1] https://uma.googleplex.com/p/chrome/timeline_v2/?sid=9316046e83ef01ba2d820fa3431af4aa

[2] https://uma.googleplex.com/p/chrome/timeline_v2/?sid=85970ee3fc0871a8716879e323f86131

[Daniel Bratell]

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]

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]

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]

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

[1] https://github.com/WICG/cors-rfc1918/issues/23

[2] https://web.dev/cors-rfc1918-feedback/

[Chris Harrelson]

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?

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

[Titouan Rigoudy]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f48xehxkD3B4KyGo8QZ1UKjsGSVDCftj48dtOSefe3Sg%40mail.gmail.com.

[Chris Harrelson]

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]

Hi Chris,

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

Cheers,

Titouan

[Lutz Vahl]

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fFaUWuatrCCROsrR1JJ1tPbvqAiL7hFyFGY75z4daSnA%40mail.gmail.com.

[Chris Harrelson]

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBPxqGd4KSizo6r3hNSpjKMYQe08q3Et8WsJDhYpNfNKew%40mail.gmail.com.

[Lutz Vahl]

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.

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

[Chris Harrelson]

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.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBOawYEzd3b2BRGrn4iAXhqq4mj5OPWUV%3DF-dsk-Ayemrw%40mail.gmail.com.

[Chris Harrelson]

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]

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]

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]

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]

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]

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.

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

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fFaUWuatrCCROsrR1JJ1tPbvqAiL7hFyFGY75z4daSnA%40mail.gmail.com.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBPxqGd4KSizo6r3hNSpjKMYQe08q3Et8WsJDhYpNfNKew%40mail.gmail.com.

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

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

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

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,

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

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

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

--
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/CAOMQ%2Bw86TgADuT7H%3D3qM3LnkELreJFbg9MmYKoK23TZDhT1vKw%40mail.gmail.com.

--
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/CAH0ixBOawYEzd3b2BRGrn4iAXhqq4mj5OPWUV%3DF-dsk-Ayemrw%40mail.gmail.com.

[Yoav Weiss]

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]

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:

1. https://chromestatus.com/metrics/feature/timeline/popularity/3758
   
2. https://chromestatus.com/metrics/feature/timeline/popularity/3756
   
3. https://chromestatus.com/metrics/feature/timeline/popularity/3754

 

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]

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

Updated: https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#

TAG review status

In review: https://github.com/w3ctag/design-reviews/issues/572#issuecomment-838040661

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

1. https://chromestatus.com/metrics/feature/timeline/popularity/3758
   
2. https://chromestatus.com/metrics/feature/timeline/popularity/3756
   
3. https://chromestatus.com/metrics/feature/timeline/popularity/3754

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

1. https://chromestatus.com/metrics/feature/timeline/popularity/3762
   
2. https://chromestatus.com/metrics/feature/timeline/popularity/3760

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):

• Dev metrics before address space fix
• Dev metrics after address space fix

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

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

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]

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]

Thanks for the correction Anne!

Cheers,
Titouan 

[Chris Harrelson]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f9-W5n3DEPGm6onsdr7O6kebgH%2BX-uycryYyQA1Nws8g%40mail.gmail.com.

[Daniel Bratell]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f9-W5n3DEPGm6onsdr7O6kebgH%2BX-uycryYyQA1Nws8g%40mail.gmail.com.

--

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]

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]

Hi all,

Thanks for the responses and for waiting, I'm catching up on emails after a couple days OOO. Response inline.

On Mon, May 17, 2021 at 3:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

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.

This case was indeed brought up by +Bart Jarochowski who is knowledgeable about the web in South Korea. None of the BBSes/Forums identified as the biggest users of this "feature" via UKM appear to have anything to do with regulated sectors (banking/finance, government).

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.

 

+Eiji Kitamura reached out to two online gaming companies who were surprised to hear that their websites were behaving this way, and did not oppose this launch. I have two hypotheses as to what was indeed going on there:

 - on-path attackers (such as e.g. an internet cafe) could be injecting malicious scripts in these http websites

 - this might be an artifact of the way we classified IP addresses before the aforemenioned fix. This hypothesis sounds less credible given the absence of change in UMA metric data post-fix.

We also reached out to a large commerce website, which said their infosec team would look into it. There has been no news on that front.

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?

Use cases where websites desire to speak to a daemon executing locally are particularly easy to fix, since http://localhost can be embedded on https websites without triggering mixed content restrictions. In that case, there is a safe upgrade path: serve the embedding website over HTTPS.

Otherwise, I do not believe this change would "break the web in South Korea". The constellation of BBSes in South Korea we identified seemed to be operated by the same entity, given the cross-linking involved. These were not reaching for http://localhost but instead for private IPs (e.g. RFC1918 192.168.0.0./16 addresses) and would be broken by this launch with no good replacement. My best bet as to the reason for this behavior was that someone (either the site owner or an on-path attacker) was trying to attack the visitors of these websites.

 

Cheers,

Yoav

On Thu, May 13, 2021 at 11:50 PM Chris Harrelson <chri...@chromium.org> wrote:

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? 

Correct. The BlockInsecurePrivateNetworkRequests [1] finch feature flag controls this feature and can act as a kill switch. The plan is to enable it by default and let the feature roll out with 92.

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

 We do not have a formal plan yet, beyond the fact that we embed a link to the blog post [2] in console errors when a fetch is blocked due to this launch. This should funnel developers towards us fairly efficiently.

I think the major obstacle to such a plan is that of identifying "bad breakage". Beyond the slight change in metric collection discussed above, there is no reason to believe the population of websites affected by this launch would be different from those tagged by our metrics before the launch. We will keep an eye on these metrics as the feature rolls out to make sure they behave as expected (same as before the launch).

In order to minimize compat risk here, we have instead tried to be quite proactive in our communications (deprecation warnings, blog posts, direct outreach) so as to raise awareness of the change ahead of time.

• Do you have a theory about if/how this might be important in enterprise settings?

For this launch to be relevant, an enterprise would need a hybrid public/private deployment where an intranet website is embedded by a public website. This was one of the scenarios we originally envisioned as problematic, but so far we have not observed much of this happening, nor have we heard directly from the developers of any such websites. An interesting point here is the difference with the metrics showing private network requests initiated from *secure* contexts, some of which show a clear pattern of high usage during the work week, and pronounced dips on the weekend, suggesting use in work environments. We see no such variations for this launch.

 

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.

We do not have granular data on the reason for the affected fetches (<img>, <script>, fetch(), ...), unfortunately. Adding that would take another ~1 1/2 milestones to roll out, monitor, then analyze.

Cheers,

Titouan

[1] https://source.chromium.org/chromium/chromium/src/+/main:content/public/common/content_features.cc;l=110;drc=655bad6b2e55af9f1f1a9dc6cf83997bbc217c14 

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

[Yoav Weiss]

Thanks for clarifying! LGTM3

On Mon, May 17, 2021 at 4:09 PM Titouan Rigoudy <tit...@google.com> wrote:

Hi all,

Thanks for the responses and for waiting, I'm catching up on emails after a couple days OOO. Response inline.

Same :)

 

On Mon, May 17, 2021 at 3:21 PM Yoav Weiss <yoav...@chromium.org> wrote:

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.

This case was indeed brought up by +Bart Jarochowski who is knowledgeable about the web in South Korea. None of the BBSes/Forums identified as the biggest users of this "feature" via UKM appear to have anything to do with regulated sectors (banking/finance, government).

That's reassuring!

 

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.

 

+Eiji Kitamura reached out to two online gaming companies who were surprised to hear that their websites were behaving this way, and did not oppose this launch. I have two hypotheses as to what was indeed going on there:

 - on-path attackers (such as e.g. an internet cafe) could be injecting malicious scripts in these http websites

Sounds like this merits breaking..

 

 - this might be an artifact of the way we classified IP addresses before the aforemenioned fix. This hypothesis sounds less credible given the absence of change in UMA metric data post-fix.

We also reached out to a large commerce website, which said their infosec team would look into it. There has been no news on that front.

That's a shame. Worthwhile to keep a close watch on related issues as this rolls out.

 

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?

Use cases where websites desire to speak to a daemon executing locally are particularly easy to fix, since http://localhost can be embedded on https websites without triggering mixed content restrictions. In that case, there is a safe upgrade path: serve the embedding website over HTTPS.

That's a great path forward!

[Titouan Rigoudy]

Hi all,

Sad news: as this launch has hit beta, a number of developers who had not noticed our previous outreach efforts have tuned in and started filing feedback about this change being incompatible with their websites.

Overall, I would like to unship this in M92 and start a Reverse Origin Trial in M93 instead. Please find the whole proposal and its reasoning here: https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit

We can continue the discussion here or there, as you prefer.

Cheers,

Titouan

[Yoav Weiss]

Thanks for listening to breakage feedback and for letting us know!

Delaying shipping to M93 doesn't require any further process. For a Deprecation Trial (which I believe is the latest preferred name for a Reverse OT), it might be best to send a separate intent to discuss timelines, the proposed solution, WebTransport dependencies, etc.

[Titouan Rigoudy]

On Fri, Jun 18, 2021 at 11:19 AM Yoav Weiss <yoav...@chromium.org> wrote:

Thanks for listening to breakage feedback and for letting us know!

Delaying shipping to M93 doesn't require any further process.

Got it. I will land and back-merge a CL to disable the feature then.

 

For a Deprecation Trial (which I believe is the latest preferred name for a Reverse OT), it might be best to send a separate intent to discuss timelines, the proposed solution, WebTransport dependencies, etc.

 

Understood, I'll send another intent.

Cheers,

Titouan

[Mathias Bynens]

On Fri, Nov 20, 2020 at 10:47 PM 'Titouan Rigoudy' via blink-dev <blin...@chromium.org> wrote:

Contact emails

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

Interoperability and Compatibility

< 1% of page views are currently loading at least one resource from a loopback address, and this change would affect them in one way or another: - https://www.chromestatus.com/metrics/feature/timeline/popularity/3689 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3691 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3693 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3695 - https://www.chromestatus.com/metrics/feature/timeline/popularity/3697

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/143) https://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.

Please don’t add new console messages. Instead, a new Issue should be added to the Issues panel. See the “Warnings, deprecations, removals” section in https://goo.gle/devtools-checklist for details.

 

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.

--

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

[Titouan Rigoudy]

Hi Mathias,

The warning and error messages have been added in DevTools for a while now. I worked with +Sigurd Schneider to land them. The warning messages come from integrating with the Reporting API's deprecation reports. We also show issues in the Issues panel. Are you saying we should remove the existing console messages?

Cheers,

Titouan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgbF2JFaNTeKDHmCp3vfNyfOsXzC%3DL-Jkes8kf%3DkyqcJNQ%40mail.gmail.com.

[Mathias Bynens]

Hi Titouan, I didn't have any context for this work. I see you've already been working with Sigurd (great!), and I fully defer to him on this. Thanks!

[Titouan Rigoudy]

Alright, thanks for confirming. I will leave things as they are for now.

Cheers,

Titouan

[Sigurd Schneider]

I'm fine with keeping the deprecation messages until we have dedicated issue support for the deprecation mechanism in blink.

That said, the general advice is true: If it is possible, we shouldn't introduce new console messages but use issues. We expect that there are cases where console messages may still be required.

--

Sigurd Schneider | Software Engineer | Chrome - V8 | sig...@google.com

 Germany GmbH / Erika-Mann-Straße 33 / 80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

    

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Titouan Rigoudy]

Hi blink-dev,

As part of working on Private Network Access (fka CORS-RFC1918) support for dedicated, shared and service workers, we found out that this launch had accidentally impacted dedicated workers.

Specifically, fetches for dedicated worker scripts as well as fetches for resources from within dedicated workers were both subject to the restriction described in this intent. Non-secure contexts were no longer allowed to make requests to the private network. Technically, this is due to PlzDedicatedWorker not having shipped, while PlzSharedWorker and PlzServiceWorker have.

This behavior shipped along with our change in Chrome in M94. We have had no complaints about it, so the compatibility impact seems to have been nil.

Cheers,

Titouan

On Sat, Jul 3, 2021 at 1:38 AM jj rice jaquan <jjjaqu...@gmail.com> wrote:

Good 

[Yoav Weiss]

Thanks for letting us know. Glad this had no negative impact!

--

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/CAPATO9fKM%2BkXaqpAf0ffuSDU9LpgCXYbvWRM%3Da5%3DyYaRk4ZWwg%40mail.gmail.com.