Hi Joe, This is currently scheduled to ship in M100.
Thanks, Victor. On Wed, Feb 16, 2022 at 12:14 PM Joe Medley <jmed...@google.com> wrote: > Which version of Chrome are you wanting to ship in? > Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com | > 816-678-7195 <(816)%20678-7195> > *If an API's not documented it doesn't exist.* > > > On Wed, Feb 16, 2022 at 8:20 AM Daniel Bratell <bratel...@gmail.com> > wrote: > >> LGTM3 >> >> Comment about double checking the security review stands. >> >> (We decided this was fine two weeks ago but not all the necessary mails >> ended up on the list - our fault, good that you pinged us!) >> >> /Daniel >> On 2022-02-16 13:39, 'Victor Vasiliev' via blink-dev wrote: >> >> Friendly ping. >> >> On Wed, Feb 2, 2022 at 11:53 AM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> LGTM2 >>> >>> My understanding is that there is a security/privacy review ongoing to >>> double-check this feature, so if there is an LGTM3 please make sure that >>> review has concluded as well. >>> >>> On Wed, Feb 2, 2022 at 3:28 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> LGTM1 >>>> >>>> On Thursday, January 20, 2022 at 7:08:59 AM UTC+1 Victor Vasiliev wrote: >>>> >>>>> Contact emails >>>>> >>>>> yhir...@chromium.org, vasi...@chromium.org >>>>> >>>>> Explainer >>>>> >>>>> https://github.com/w3c/webtransport/blob/main/explainer.md >>>>> >>>>> Spec >>>>> >>>>> >>>>> https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes >>>>> >>>>> WebTransport has been already covered by a series of TAG reviews (389 >>>>> <https://github.com/w3ctag/design-reviews/issues/389>, 669 >>>>> <https://github.com/w3ctag/design-reviews/issues/669>). >>>>> >>>>> Summary >>>>> >>>>> In WebTransport, the serverCertificateHashes option allows the website >>>>> to connect to a WebTransport server by authenticating the certificate >>>>> against the expected certificate hash instead of using the Web PKI. This >>>>> feature allows Web developers to connect to WebTransport servers that >>>>> would >>>>> normally find obtaining a publicly trusted certificate challenging, such >>>>> as >>>>> hosts that are not publically routable, or virtual machines that are >>>>> ephemeral in nature. >>>>> >>>>> During the WebTransport Intent to Ship email thread >>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/kwC5wES3I4c>, >>>>> concerns were raised regarding the security considerations of this portion >>>>> of the spec being incomplete. We believe that we have addressed those >>>>> concerns (notably, in this PR >>>>> <https://github.com/w3c/webtransport/pull/375>). >>>>> >>>> >>>> Please followup on the PR to ensure it lands. Thanks! :) >>>> >>>> >>>>> In terms of the actual code behavior, the only major difference >>>>> since the previous thread is that we no longer allow RSA keys for the >>>>> certificates. >>>>> >>>>> Link to “Intent to Prototype” blink-dev discussion >>>>> >>>>> >>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/I6MS2kOKcx0/m/NAdg7Sc-CwAJ >>>>> >>>>> Is this feature supported on all six Blink platforms (Windows, Mac, >>>>> Linux, Chrome OS, Android, and Android WebView)? >>>>> >>>>> Yes. >>>>> >>>>> Debuggability >>>>> >>>>> The certificate-related errors for WebTransport sessions are logged >>>>> into the developer console. >>>>> >>>>> Measurement >>>>> >>>>> The use of this feature is tracked by the >>>>> WebTransportServerCertificateHashes use counter. >>>>> >>>>> Risks >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> There is some discussion about adding a mechanism to prevent websites >>>>> from using this feature via an HTTP header (either CSP or a new header). >>>>> Some of the proposals could potentially break existing usage under certain >>>>> conditions (e.g. if a webpage both uses serverCertificateHashes and has a >>>>> connect-src directive, and we decide to extend connect-src); I expect for >>>>> those cases to be sufficiently niche to ultimately not be a problem, and >>>>> the question itself is of fairly low priority as there does not seem to be >>>>> a strong security reason for a website to restrict >>>>> serverCertificateHashes. >>>>> >>>> >>>> Are you planning to file a separate intent once those plans materialize? >>>> >>>> >>>>> >>>>> Gecko: worth prototyping >>>>> <https://github.com/mozilla/standards-positions/issues/167#issuecomment-1015951396> >>>>> >>>>> WebKit: no signal >>>>> <https://lists.webkit.org/pipermail/webkit-dev/2021-September/031980.html> >>>>> >>>>> Web / Framework developers: positive (we have received indication in >>>>> the past that serverCertificateHashes is a blocker for migrating from >>>>> WebRTC at least one of them) >>>>> >>>>> Ergonomics >>>>> >>>>> The API is roughly modeled after a similar WebRTC API >>>>> (RtcDtlsFingerprint), with a noted improvement that the certificate hash >>>>> no >>>>> longer requires to be serialized into a specific format. >>>>> >>>>> Activation >>>>> >>>>> Using this feature would require web developers to design their >>>>> application in a way that supports generating and distributing ephemeral >>>>> certificates on demand. >>>>> >>>>> Security >>>>> >>>>> Security considerations for this feature are discussed at length in PR >>>>> #375 >>>>> <https://pr-preview.s3.amazonaws.com/vasilvv/web-transport/pull/375.html#certificate-hashes> >>>>> . >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>? >>>>> Link to test suite results from wpt.fyi. >>>>> >>>>> WebTransport itself is tested by web-platform-tests; this specific >>>>> feature requires infra support that is currently not available (issue >>>>> <https://github.com/web-platform-tests/wpt/issues/32463>). >>>>> >>>>> Entry on the feature dashboard <http://www.chromestatus.com/> >>>>> >>>>> https://chromestatus.com/feature/5690646332440576 >>>>> >>>> -- >>>> 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/2a591c7e-ef31-4015-8b34-256e12bcfce3n%40chromium.org >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2a591c7e-ef31-4015-8b34-256e12bcfce3n%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/CAAZdMaetk7JoQ-gOmhcPKgRh2uo%2BnKNeG%3DYOF%3Dnrat0YVPUgBQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaetk7JoQ-gOmhcPKgRh2uo%2BnKNeG%3DYOF%3Dnrat0YVPUgBQ%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/546df1df-f975-85d1-ff9b-b59eadeab4a8%40gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/546df1df-f975-85d1-ff9b-b59eadeab4a8%40gmail.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/CAAZdMac4f6k8u9fAY%3DqUt4uhn9SbNiYLL3Ee78Hq6%3D3fXPjrzA%40mail.gmail.com.
