I agree UKM analysis should not block step 1, as it holds little risk. (There's still some risks that servers will choke in the face of preflights, but that seems minor compared to the enforcement risk)
Therefore,* LGTM1 for step 1* (preflights with no enforcement), but not further (yet). Please come back to this thread with any data you may have as a result of adding UKMs. On Fri, Dec 3, 2021 at 6:44 PM 'Titouan Rigoudy' via blink-dev < blink-dev@chromium.org> wrote: > Yoav, do you think UKM analysis should block sending preflights without > enforcing their success? I believe sending these will allow us to get more > precise information on the affected websites through the usecounter > recorded in crrev.com/c/3310846. I can then analyze UKM data and use the > results to inform the decision whether and when to switch enforcement on? > > Cheers, > Titouan > > On Thu, Dec 2, 2021 at 5:19 PM Titouan Rigoudy <tito...@google.com> wrote: > >> I agree! >> >> Cheers, >> Titouan >> >> On Thu, Dec 2, 2021 at 5:17 PM Mike West <mk...@chromium.org> wrote: >> >>> _I_ don't think we should do that, but I'd defer to Titouan's >>> preference. :) >>> >>> -mike >>> >>> >>> On Thu, Dec 2, 2021 at 5:14 PM Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> Thanks - I also don't think there's a lot of value in this particular >>>> header being the odd-one-out, just wanted to confirm we're not going to >>>> ship "true" first and try to change that to ?1 later (which is always >>>> challenging). >>>> >>>> On 12/2/21 11:11 AM, Mike West wrote: >>>> >>>> I'm not sure it makes sense to introduce a structured header here, >>>> given that it's layering on top of CORS headers that I don't think there's >>>> substantial interest in changing. >>>> >>>> -mike >>>> >>>> >>>> On Thu, Dec 2, 2021 at 4:55 PM 'Titouan Rigoudy' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>>> Hi Mike, >>>>> >>>>> There is no support for structured headers so far, for consistency >>>>> reasons, and there has been no movement to deprecate the "true" value for >>>>> Access-Control-Allow-Credentials. The value of such a deprecation seems >>>>> minimal. >>>>> >>>>> I could pretty easily add support for the structured "?1" value on top >>>>> of the "true" token for the new Access-Control-Allow-Private-Network >>>>> header, and specify that, but I'm not sure it would be terribly useful. Do >>>>> you think otherwise? >>>>> >>>>> Cheers, >>>>> Titouan >>>>> >>>>> On Thu, Dec 2, 2021 at 4:45 PM Mike Taylor <miketa...@chromium.org> >>>>> wrote: >>>>> >>>>>> Hi Titouan, >>>>>> >>>>>> I'm curious what the plan is for structured headers. >>>>>> https://github.com/WICG/private-network-access/issues/45 is marked >>>>>> as blocked - has there been other progress or thinking behind the scenes? >>>>>> >>>>>> thanks, >>>>>> Mike >>>>>> >>>>>> On 11/29/21 10:36 AM, 'Titouan Rigoudy' via blink-dev 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. 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. 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/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9fdAK%2BnrTfUzug8ub_DhV_LE0b7XrgZ7j5%2Bj_BHtW-FXg%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/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9f3dAnHromxwvp8jWRxVLYVKZ0PAG5snX2KDFAYz4kc7Q%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/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPATO9ePgpof%2BBDWS9X7sfHHAqgc6Arem3b78ZGC%3D%2Bp4jB6_AQ%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/CAL5BFfXzaynzF%3DgF0DxKMRdiN60zWZXMmiNq9J2g5SNGqO0Buw%40mail.gmail.com.
