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
< 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.
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.
This change should be security-positive.
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.
Contact emails
tit...@chromium.org, cl...@chromium.org, mk...@chromium.org, va...@chromium.orgExplainer
https://github.com/WICG/cors-rfc1918/blob/master/explainer.mdSpecification
https://wicg.github.io/cors-rfc1918/API spec
YesDesign docs
https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/editSummary
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
BlinkTAG review
https://github.com/w3ctag/design-reviews/issues/572TAG review status
PendingRisks
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.
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.orgExplainer
https://github.com/WICG/cors-rfc1918/blob/master/explainer.mdSpecification
https://wicg.github.io/cors-rfc1918/API spec
YesDesign docs
https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/editSummary
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
BlinkTAG review
https://github.com/w3ctag/design-reviews/issues/572TAG review status
PendingRisks
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 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.
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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f48xehxkD3B4KyGo8QZ1UKjsGSVDCftj48dtOSefe3Sg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fFaUWuatrCCROsrR1JJ1tPbvqAiL7hFyFGY75z4daSnA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH0ixBPxqGd4KSizo6r3hNSpjKMYQe08q3Et8WsJDhYpNfNKew%40mail.gmail.com.
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.
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?
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.
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
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.
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.
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.
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=1efd0761559b30146db8af342685a3d1That'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.
< 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:
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.
This change should be security-positive.
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.
--
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.
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
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.
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+...@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.
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,YoavOn 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?
- 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 RegardsOn 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.
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.
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.
Contact emails
tit...@chromium.org, cl...@chromium.org, mk...@chromium.org, va...@chromium.orgExplainer
https://github.com/WICG/cors-rfc1918/blob/master/explainer.mdSpecification
https://wicg.github.io/cors-rfc1918/API spec
YesDesign docs
https://docs.google.com/document/d/1tIl8F0i31_z6gttaaPmRDynHBqWsLaV_94ngrpg5Oeg/edit#heading=h.lnbc74amxd9e
https://docs.google.com/document/d/15r4PQdHJa3SunkGg0RDgm6MlcCdWSZLJj9Cq2awSLvo/editSummary
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
BlinkTAG review
https://github.com/w3ctag/design-reviews/issues/572TAG review status
PendingRisks
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.
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/72Tracking bug
https://crbug.com/986744Launch bug
https://crbug.com/1129801Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5436853517811712Links 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/7ZvqAqHLAwAJThis 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.
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.
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.
Good
--
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.