LGTM for a deprecation trial M109-M112 inclusive, assuming the removal intent passes.
On Wed, Oct 5, 2022 at 3:19 PM Titouan Rigoudy <[email protected]> wrote: > On Wed, Oct 5, 2022 at 12:00 PM Yoav Weiss <[email protected]> wrote: > >> >> >> On Wed, Oct 5, 2022 at 11:30 AM Jonathan Hao <[email protected]> wrote: >> >>> >>> >>> On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> Thanks for pushing this! :) >>>> >>>> On Fri, Sep 30, 2022 at 5:13 PM Jonathan Hao <[email protected]> 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? >>>> >>> Sorry I didn't make it clear. We want to start the enforcement of >>> preflights from M109, but also set up a deprecation trial that websites can >>> sign up if they're affected and need time to fix it. >>> >> >> I think it'd be better to send a separate intent to remove that >> functionality, to make it obvious to observers that we're talking about a >> removal. >> > > Sure, we can do that. > > >> Did current preflight failures go through deprecation reports or some >> other means to inform relevant developers? >> > > No deprecation reports, because it would reveal cross-origin information > to the fetch client. We surface warnings in DevTools issues and network > panels instead. > > >> Do we have means to outreach to impacted developers and inform them about >> the deprecation trial? >> > > We have consulted the list of impacted websites through UKMs and found > that the majority of uses (out of ~0.1% of page visits affected) look > illegitimate - those seem to be precisely the kind of requests we wish to > prevent with this change. Out of the remaining websites, only a couple > stood out as worth reaching out to given usage metrics. We tried to reach > out and finally decided against it for reasons I can explain off-list. > > Instead, we are updating the PNA preflight blog post on > developer.chrome.com to mention the rollout timeline and deprecation > trial. > > Also, might be better to have the trial enabled before going ahead with >> the removal. >> > > For sure. We would like to start the trial as soon as we gather 3 LGTMs > here, though it will be useless until 109 rolls out with enforcement > enabled. At that point, developers will be able to use dev and beta builds > to make sure their websites are correctly enrolled in the trial before > stable rolls out. > You need 3 LGTMs on the removal, but only one here. > > Cheers, > Titouan > > >> +Andre Bandarra <[email protected]> - FYI >> >> >>>> >>>>> >>>>> 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? >>>> >>> Yes, the URLs. Also, to be precise, there are still a tiny portion of >>> URLs that might be legit, which is why we wanted to set up a deprecation >>> trial. >>> >>>> >>>> >>>>> 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 [email protected], [email protected], >>>>> [email protected], [email protected], [email protected] >>>>> >>>>> 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 [email protected]. >>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWJMe9DLKzYBufMZjWyrF%3D%3DS1OOvaMw8rEx088t-u72WA%40mail.gmail.com.
