Good idea, I will alert the enterprise team of the upcoming change. There are also existing enterprise policies [1] [2] introduced for the previous change (secure context restriction) that also work in this context to disable the new behavior entirely. Their descriptions need a little updating for it to be clear that they apply to this change as well. Filed crbug.com/1275567 to fix that.
As for specific sources: UKM data might not tell us unfortunately, since AFAIU that data is not reported by enterprise deployments? Cheers, Titouan [1] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowed [2] https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowedForUrls On Wed, Dec 1, 2021 at 3:02 PM Daniel Bratell <bratel...@gmail.com> wrote: > This sounds like a change that would disproportionately affect > "enterprise" so it's probably best to involve the Chrome enterprise team > sooner rather than later. The numbers are higher than I would have > expected. Makes me wonder if there is some specific source of those. I > would have expected it to be rarer than that to embed a resource from a > private network. > > /Daniel > On 2021-12-01 14:42, 'Titouan Rigoudy' via blink-dev wrote: > > Thanks for the response Yoav, answers inline. > > On Wed, Dec 1, 2021 at 1:22 PM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> >> >> On Monday, November 29, 2021 at 4:37:24 PM UTC+1 Titouan Rigoudy wrote: >> >>> Contact emails tito...@chromium.org, v...@chromium.org, >>> cl...@chromium.org >>> >>> Explainer >>> https://github.com/WICG/private-network-access/blob/main/explainer.md >>> >>> Specification https://wicg.github.io/private-network-access/ >>> >>> Design docs >>> >>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit >>> >>> Summary >>> >>> Sends a CORS preflight request ahead of any private network requests for >>> subresources, asking for explicit permission from the target server. A >>> private network request is any request from a public website to a private >>> IP address or localhost, or from a private website (e.g. intranet) to >>> localhost. Sending a preflight request mitigates the risk of cross-site >>> request forgery attacks against private network devices such as routers, >>> which are often not prepared to defend against this threat. >>> >>> >>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> >>> >>> TAG review https://github.com/w3ctag/design-reviews/issues/572 >>> >>> TAG review status Pending >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> The main interoperability risk, as always, is if other browser engines >>> do not implement this. Compat risk is straightforward: web servers that do >>> not handle the new preflight requests will eventually break, once the >>> feature ships. The plan to address this is as follows: 1. Send preflight >>> request, ignore result, always send actual request. Failed preflight >>> requests will result in a warning being shown in devtools. >>> >> >> Would that include deprecation reports? >> > > Not so far. Blink is not made aware of the warnings yet, they go from the > network service to the browser process and then straight to devtools. More > wiring would be needed for Blink to notice the warning and send a > deprecation report. > > >> >> > 2. Wait for 3 milestones. 3. Gate actual request on preflight request >>> success, with deprecation trial for developers to buy some more time. >>> >> >> We'd also need to communicate this widely in order to get relevant >> developers to sign up for the deprecation trial. UKM investigation can help >> us focus efforts on that front. >> > > That is true. I am planning to write a blog post on web.dev or the chrome > blog to help raise awareness. > > 4. End deprecation trial 4 milestones later. UseCounters: >>> https://chromestatus.com/metrics/feature/timeline/popularity/3753 >>> https://chromestatus.com/metrics/feature/timeline/popularity/3755 >>> https://chromestatus.com/metrics/feature/timeline/popularity/3757 >>> >> >> That's a lot of usage :/ I remember you did a bunch of UKM investigations >> in the past. Did that include this case as well? >> > > I did not look at these metrics during my previous UKM analysis - I was > focusing on non-secure contexts initiating private network requests. I can > look into them again however, and try to reach out to the biggest users > before enforcement is turned on. > > Cheers, > Titouan > > >> The above measure pages that make at least one private network request >>> for which we would now send a preflight request. >>> >>> >>> Gecko: Worth prototyping ( >>> https://github.com/mozilla/standards-positions/issues/143) >>> >>> WebKit: No signal ( >>> https://lists.webkit.org/pipermail/webkit-dev/2021-November/032040.html) >>> Pending response. >>> >>> Web developers: No signals Anecdotal evidence so far suggests that most >>> web developers are OK with this new requirement, though some do not control >>> the target endpoints and would be negatively impacted. >>> >>> Other signals: >>> >>> Ergonomics >>> >>> None. >>> >>> >>> Activation >>> >>> Gating access to the private network overnight on preflight requests >>> would likely result in widespread breakage. This is why the plan is to >>> first send requests but not act on their result, giving server developers >>> time to implement code handling these requests. Deprecation warnings will >>> be surfaced in DevTools to alert web/client developers when the potential >>> for breakage later on is detected. Enforcement will be turned on later >>> (aiming for 3 milestones), along with a deprecation trial for impacted web >>> developers to buy themselves some more time. Experience suggests a large >>> fraction of developers will not notice the advance deprecation warnings >>> until things break. >>> >>> >>> Security >>> >>> This change aims to be security-positive, preventing CSRF attacks >>> against soft and juicy targets such as router admin interfaces. DNS >>> rebinding threats were of particular concern during the design of this >>> feature: >>> https://docs.google.com/document/d/1FYPIeP90MQ_pQ6UAo0mCB3g2Z_AynfPWHbDnHIST6VI/edit#heading=h.189j5gnadts9 >>> >>> >>> Debuggability >>> >>> Relevant information (client and resource IP address space) is already >>> piped into the DevTools network panel. Deprecation warnings and errors will >>> be surfaced in the DevTools issues panel explaining the problem when it >>> arises. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? Yes >>> >>> DevTrial instructions >>> https://github.com/WICG/private-network-access/blob/main/HOWTO.md >>> >>> Flag name PrivateNetworkAccessRespectPreflightResults >>> >>> Requires code in //chrome? False >>> >>> Tracking bug https://crbug.com/591068 >>> >>> Launch bug https://crbug.com/1274149 >>> >>> Estimated milestones >>> DevTrial on desktop 98 >>> DevTrial on android 98 >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5737414355058688 >>> >>> Links to previous Intent discussions Intent to prototype: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ >>> >>> >>> 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 blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f6QS%3D4oJqnJg6NR%3DpoKcT149h8LeiSzkfd%3Dqq8qV6pLA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f6QS%3D4oJqnJg6NR%3DpoKcT149h8LeiSzkfd%3Dqq8qV6pLA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9d8uEophL-%2BbCU0YEdGSKcC8ujDApYra1peS1BsykKdVw%40mail.gmail.com.
