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.
