Thanks for pushing this! :) On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <p...@chromium.org> wrote:
> TL;DR: We'd like to set up a deprecation trial for the following feature > from M109 to M112. > What's the timeline for actual enforcement of preflights here? Are you also asking for approvals for that, or would it be covered by a separate intent? > > Context: Since 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 none of them > Can you clarify who "them" is? Is it URLs that fail the preflight? > looks legit, most likely used for fingerprinting purposes, so we decided > to start enforcing the preflight response, but with a deprecation trial so > that websites that do need it have a time to migrate, and we would be able > to know who they are. > 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%2Bew8hADZkdQ3AO6P9WzfGuzLPp9JjJZqztV5oZmaK8oQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOC%3DiP%2Bew8hADZkdQ3AO6P9WzfGuzLPp9JjJZqztV5oZmaK8oQ%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/CAL5BFfWitT4W4EpJzu8M3u%3DeqaOJ%2BX9UDSqirS7NTKe7FJyrtg%40mail.gmail.com.
