While plumbing use counters from //net back into Blink would be technically possible, it would be a lot of work and we'd need some compelling user benefit to justify it.
In this case, just having a kill switch seems sufficient. On Thu, 29 Jun 2023 at 16:26, Yoav Weiss <yoavwe...@chromium.org> wrote: > Thanks for working on this! > > Would you be able to put this behind a flag > <https://chromium.googlesource.com/chromium/src/+/master/docs/how_to_add_your_feature_flag.md#step-1_adding-a-new>, > to reduce any risk this might hit in the wild? > > It'd also be good to add use-counters to know how common these digests > are, but given that the code is fully contained in net/ this might be a bit > tricky. Maybe +Adam Rice <ri...@chromium.org> and team would be able to > help with adding some metrics there? That's not a blocker for this intent, > but would help shed light on overall usage of this feature. > > On Wed, Jun 28, 2023 at 4:15 PM Deomid "rojer" Ryabkov <ro...@rojer.me> > wrote: > >> +ericlaw@microsoft >> >> Eric, could you perhaps provide updated numbers of digest auth usage? >> (i'm referring to your previous comment here: >> https://bugs.chromium.org/p/chromium/issues/detail?id=1160478#c6) >> >> >> On Mon, Jun 26, 2023, 18:09 David Benjamin <david...@chromium.org> wrote: >> >>> Not an expert in our HTTP auth code overall, but I don't see any metrics >>> for specifically digest auth vs. other HTTP auth types either. >>> >>> As an upper bound, I wouldn't expect HTTP auth of any form to be common. >>> This whole space is mostly a legacy feature as far as the web is concerned. >>> I doubt usage would ever completely fall off, but it's not exactly a >>> preferred path, or a space that sees much active work. Making modern hashes >>> available for Digest seems reasonable enough, I suppose, but I wouldn't >>> want to spend more time on it than that. :-) >>> >>> But I couldn't find good metrics for the upper bound either. >>> Net.HttpResponseCode says how often we see 401 and 407 response codes (very >>> rarely), but that's a little misleading. If I recall (not an HTTP auth >>> expert), for the simpler auth types (Basic and Digest), cached credentials >>> are sufficient to preemptively send a (Proxy-)Authorization header. That >>> means we'll only see a 401 or 407 on the first go around, up to some >>> interesting rules around which paths an auth entry is scoped to. >>> >>> In terms of breakage risk, since this protocol is server-offer >>> / client-select, the client never sends the list of values it supports. >>> That means only servers that actually claim to support the new hashes will >>> see any change at all. So the risk is limited to early-adopting servers >>> that have adopted the new thing but gotten it wrong. Or if we got it wrong. >>> :-) (No particular opinions on my end as to whether that makes it worth >>> flag-protecting.) >>> >>> On Mon, Jun 26, 2023 at 10:46 AM Rick Byers <rby...@chromium.org> wrote: >>> >>>> Hi Deomid, >>>> Thanks for the contribution! Do you know if chromium has any metrics on >>>> how common digest auth is? I took a quick look and didn't find one myself. >>>> +David >>>> Benjamin <david...@chromium.org> also. Technically all new APIs (which >>>> includes protocols) require a killswitch flag >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md#When-is-a-flag-required> >>>> since >>>> we've seen even new APIs break websites sometimes (eg. in this case >>>> presumably it would be from a misconfigured server). But if we have data >>>> showing the usage of digest auth is small / insignificant enough, I'd >>>> personally be receptive to an argument that that is unnecessary extra >>>> bureaucracy. >>>> >>>> Also it would be nice to know if WebKit has an opinion on this, could >>>> you file a position request >>>> <https://docs.google.com/document/d/1xkHRXnFS8GDqZi7E0SSbR3a7CZsGScdxPUWBsNgo-oo/edit#heading=h.tgzhprxcmw4u> >>>> please? >>>> >>>> Thanks, >>>> Rick >>>> >>>> On Wed, Jun 21, 2023 at 3:31 PM Deomid "rojer" Ryabkov <ro...@rojer.me> >>>> wrote: >>>> >>>>> Hi Daniel, >>>>> >>>>> I do not anticipate immediate impact. By and large, this is not >>>>> currently used because the most popular browser engine doesn't support it. >>>>> So people just use MD5, as in the bad old days. >>>>> If we ship this tomorrow, nothing changes: servers still send legacy >>>>> MD5 challenges, which we continue to support. >>>>> As awareness of SHA-256 support by Chrome/Blink-based browser spreads, >>>>> I expect service administrators to gradually start transitioning away from >>>>> MD5. >>>>> The RFC specifies use of multiple algorithm challenges by sending >>>>> multiple WWW-Authenticate headers, so there's a good transition path there >>>>> for service admins (send both SHA-256 and MD5 challenges, phase out MD5 >>>>> eventually). >>>>> I verified that with my current code this works as specified (order of >>>>> headers specifies server's preference). >>>>> Firefox already supports SHA-256, so there's already a capable browser >>>>> in the wild, but since it's a minority there isn't much use yet. >>>>> As far as deviating from Firefox in also supporting SHA-512-256 and >>>>> userhashing, it's again a no-op initially: these won't be used unless >>>>> servers explicitly specify that they can be used (for example, for >>>>> lighttpd >>>>> there's an explicit option to enable username hashing, off by default). >>>>> If Firefox catches up and also implements these, then we might start >>>>> seeing adoption. >>>>> >>>>> >>>>> On Wed, 21 Jun 2023 at 11:18, Daniel Bratell <bratel...@gmail.com> >>>>> wrote: >>>>> >>>>>> I am missing the compatibility picture here. How will this affect >>>>>> existing web pages, and what happens to browsers that do not support this >>>>>> is we add support? >>>>>> >>>>>> /Daniel >>>>>> On 2023-06-20 18:13, Deomid "rojer" Ryabkov wrote: >>>>>> >>>>>> Contact emails roj...@gmail.com >>>>>> >>>>>> Explainer None >>>>>> >>>>>> Specification https://datatracker.ietf.org/doc/html/rfc7616 >>>>>> >>>>>> Summary >>>>>> >>>>>> https://datatracker.ietf.org/doc/html/rfc7616 specifies SHA-256 and >>>>>> SHA-512-256 algorithms for the HTTP digest authentication scheme, in >>>>>> addition to the obsolete and insecure MD5. It also specifies way of >>>>>> concealing the username, provided that server supports it. Firefox >>>>>> supports >>>>>> algorithm=SHA-256 since 93, but not SHA-512-256 or username hashing. >>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4611879 is >>>>>> the pending CL. >>>>>> >>>>>> >>>>>> Blink component Blink>Network >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>>>> >>>>>> TAG review None >>>>>> >>>>>> TAG review status Not applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> *Gecko*: Shipped/Shipping ( >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=472823) >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ? No >>>>>> >>>>>> Flag name >>>>>> >>>>>> Requires code in //chrome? False >>>>>> >>>>>> Tracking bug >>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1160478 >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop 116 >>>>>> Shipping on Android 116 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5139896267702272 >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> Deomid "rojer" Ryabkov >>>>>> ro...@rojer.me >>>>>> -- >>>>>> 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/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwr1XJbEU-yWbe2Whx%2Bago2njJFg-gOOdKzEj0%3DGVzP%3D0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Deomid "rojer" Ryabkov >>>>> ro...@rojer.me >>>>> >>>>> -- >>>>> 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/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwof4uGQYUB%3Dac00NisuQG%3Di1JrDT7BcvJtPzMReWcZyxQ%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/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwryoCQ8j4sfPFh3Ozs%3DKaMDt0xEHFMo61mQXXzVw0eM%3DQ%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/CAC_ixdy_zN8J78m_zVFmo0XKgxsoC6Faa%2B4Pv58R7VMsSTMKoA%40mail.gmail.com.
