*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/CAPATO9d_h-tzpkRxfHQrcwiDrkgAGDeDw8KnoS1FnTK2X0eqAw%40mail.gmail.com.
