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 <[email protected]> wrote: > Good > > On Friday, November 20, 2020 at 4:47:51 PM UTC-5 Titouan Rigoudy wrote: > >> Contact [email protected], [email protected], [email protected] >> , [email protected] >> >> Explainerhttps://github.com/WICG/cors-rfc1918/blob/master/explainer.md >> >> Specificationhttps://wicg.github.io/cors-rfc1918/ >> >> API specYes >> >> 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 componentBlink >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink> >> >> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 >> >> TAG review statusPending >> >> 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 >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >> ?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 bughttps://crbug.com/986744 >> >> Launch bughttps://crbug.com/1129801 >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5436853517811712 >> >> Links to previous Intent discussionsIntent 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 >> <https://www.chromestatus.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 [email protected]. 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.
