Great, thanks! On Thu, Oct 6, 2022 at 9:33 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
> LGTM for a deprecation trial M109-M112 inclusive, assuming the removal > intent passes. > > On Wed, Oct 5, 2022 at 3:19 PM Titouan Rigoudy <tito...@google.com> wrote: > >> On Wed, Oct 5, 2022 at 12:00 PM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> >>> >>> On Wed, Oct 5, 2022 at 11:30 AM Jonathan Hao <p...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wed, Oct 5, 2022 at 9:34 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> 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? >>>>> >>>> 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 <andre...@google.com> - 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 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/CAPATO9ehw8SDrUsMW4GwhZXrhaV-u5T3QR2GdtGPpWkoR55bCw%40mail.gmail.com.
