Hi Rick, thanks for your response. I've files a WebKit issue: https://github.com/WebKit/standards-positions/issues/212 as for metrics, i don't have any. we have a 2-year old comment <https://bugs.chromium.org/p/chromium/issues/detail?id=1160478#c6> from ericlaw@microsoft that usage is extremely low. Perhaps i should clarify why I am bothering with this at all: embedded device usage. Use of built-in auth mechanisms is attractive for extremely low footprint devices, we happen to be shipping one of those and currently use it. Use of SSL/TLS there is also usually not an option (for lack of trusted certificates, if not footprint concerns), so basic+TLS is not a viable alternative, hence the desire to have digest auth with a modern algorithm. This - use in embedded environments - could also be masking some of the usage. But in general I tend to agree that current use is most likely negligible overall. I do not have access to any metrics though.
On Mon, 26 Jun 2023 at 10:46, Rick Byers <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 [email protected] >>> >>> 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 >>> [email protected] >>> -- >>> 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 [email protected]. >>> 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 >> [email protected] >> >> -- >> 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 [email protected]. >> 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> >> . >> > -- Deomid "rojer" Ryabkov [email protected] -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABFmFwpSkBSRzQegCUQqAeS-70BSe2A158KMhhgDci%3DLa%2B3PuQ%40mail.gmail.com.
