LGTM3 for step 1. On Mon, Dec 6, 2021 at 6:11 AM Mike Taylor <miketa...@chromium.org> wrote:
> LGTM2 for step 1. > > On 12/6/21 5:31 AM, Titouan Rigoudy wrote: > > *assuming I get 2 more LGTMs, that is. > > On Mon, Dec 6, 2021 at 11:31 AM Titouan Rigoudy <tito...@google.com> > wrote: > >> 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/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e557fb7-5b1d-20bc-aae5-65526ca8efb7%40chromium.org?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/CAOMQ%2Bw8Fb9kUHFireR73U3Lpz7bCNpRxvfk3iZiYQuYkQUxK%2BA%40mail.gmail.com.
