Thanks! I'll come back for further discussion with UKM data in hand. Cheers, Titouan
On Mon, Dec 6, 2021 at 10:58 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > 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/CAPATO9erMAdBaXQhcmdbUiwp9E7W1ogNzV7ZRHhBt6F3hfEeng%40mail.gmail.com.
