ContextSince M104, we've started sending preflight requests before private network access, but ignoring the preflight result (or the lack of it). After analyzing the URL-keyed metrics, we found that most of them don't seem legit, most likely used for fingerprinting purposes, so we decided to start enforcing the preflight response, which means that the websites will not be able to fetch subresources from less-public ip address space without getting proper preflight responses.
An intent focusing on the deprecation trial was sent earlier in this thread: https://groups.google.com/a/chromium.org/g/blink-dev/c/k8osI88QbKs/m/16ytAQ-BAwAJ?utm_medium=email&utm_source=footer. There, we were suggested to send a separate intent to remove the functionality, and hence this intent email. Contact emailstito...@chromium.org, v...@chromium.org, cl...@chromium.org, l...@chromium.org, p...@chromium.org Explainer https://github.com/WICG/private-network-access/blob/main/explainer.md Specificationhttps://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 componentBlink>SecurityFeature>CORS>PrivateNetworkAccess <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ESecurityFeature%3ECORS%3EPrivateNetworkAccess> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/572 TAG review statusIssues addressed 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. 2. Wait for 3 milestones. 3. Gate actual request on preflight request success, with deprecation trial for developers to buy some more time. 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 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. It does not cover navigation requests and workers, which are to be addressed in followup launches. 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 WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? Not going to ship on Android WebView Goals for experimentation Give websites time to make sure they respond to the preflights Reason this experiment is being extended N/A Ongoing technical constraints N/A 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. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?No Not on Android WebView given previous difficulty in supporting PNA changes due to the lack of support for deprecation trials. Support for WebView will be considered separately. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Yes DevTrial instructions https://github.com/WICG/private-network-access/blob/main/HOWTO.md Flag namePrivateNetworkAccessRespectPreflightResults Requires code in //chrome?False Tracking bughttps://crbug.com/591068 Launch bughttps://crbug.com/1274149 Estimated milestones OriginTrial desktop last 112 OriginTrial desktop first 109 DevTrial on desktop 98 OriginTrial Android last 112 OriginTrial Android first 109 DevTrial on Android 98 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5737414355058688 Links to previous Intent discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/PrB0xnNxaHs/m/jeoxvNjXCAAJ Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/72CK2mxD47c This intent message was generated by Chrome Platform Status <https://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/CAOC%3DiP%2BEcXFNTOfg829uzFh2YMov%3DTsmAzdP9VDn8MoLuHqjog%40mail.gmail.com.