*LGTM2* to ship without certificate fingerprints. It'd be great to ensure public documentation for this includes the fallback mechanism we want developers to implement. (both in the web.dev article and future MDN documentation).
On Thu, Oct 7, 2021 at 9:19 PM Mike West <mk...@chromium.org> wrote: > LGTM1, to ship this without the certificate fingerprint portion of 349 > discussed above. There's still some conversation to be had there, and I > think it's worth finishing the discussion before shipping it since it's > quite clearly separable. I'd suggest shipping that as a separate intent if > that's the way the conversation goes. > > I appreciate Philip's comments as well, and I'm happy to see that y'all > have already put up a PR to add CSP support. I think we should probably > alter the CSP spec to make your PR more clear, but that's not something I > think we ought to block on. > > I'll also note that the TAG just put this on their agenda for this coming > week. If concerns are raised there, I would appreciate us addressing them > thoroughly before shipping. > > -mike > > > On Thu, Oct 7, 2021 at 4:53 PM Yutaka Hirano <yhir...@chromium.org> wrote: > >> >> >> On Thu, Oct 7, 2021 at 5:51 PM Yutaka Hirano <yhir...@chromium.org> >> wrote: >> >>> >>> >>> On Thu, Oct 7, 2021 at 5:38 PM Philip Jägenstedt <foo...@chromium.org> >>> wrote: >>> >>>> On Thu, Oct 7, 2021 at 10:04 AM Yutaka Hirano <yhir...@chromium.org> >>>> wrote: >>>> >>>>> Thank you! >>>>> >>>>> On Thu, Oct 7, 2021 at 4:45 PM Philip Jägenstedt <foo...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Tue, Oct 5, 2021 at 3:20 PM Yutaka Hirano <yhir...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 4, 2021 at 10:04 PM Philip Jägenstedt < >>>>>>> foo...@chromium.org> wrote: >>>>>>> >>>>>>>> On Fri, Oct 1, 2021 at 9:27 PM Yutaka Hirano <yhir...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Philip, >>>>>>>>> >>>>>>>>> Sorry for the belated reply. Comments inline: >>>>>>>>> >>>>>>>>> On Thu, Sep 30, 2021 at 7:31 PM Philip Jägenstedt < >>>>>>>>> foo...@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Hi again, >>>>>>>>>> >>>>>>>>>> I've made a full pass of the intent now. I have a lot of >>>>>>>>>> questions, but am pretty convinced we should ship this, it's just a >>>>>>>>>> matter >>>>>>>>>> of what things need to block that, and what things can be left until >>>>>>>>>> later. >>>>>>>>>> >>>>>>>>>> Comments inline... >>>>>>>>>> >>>>>>>>>> On Mon, Sep 27, 2021 at 6:55 AM Yutaka Hirano < >>>>>>>>>> yhir...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> >>>>>>>>>>> yhir...@chromium.org, vasi...@chromium.org >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> >>>>>>>>>>> https://github.com/w3c/webtransport/blob/main/explainer.md >>>>>>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> >>>>>>>>>>> https://w3c.github.io/webtransport >>>>>>>>>>> >>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ >>>>>>>>>>> >>>>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-quic-datagram/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I skimmed https://github.com/w3c/webtransport/issues/ and see >>>>>>>>>> multiple issues filed by other browser vendors. Are any of the >>>>>>>>>> remaining >>>>>>>>>> issues ones that could change the API's shape or behavior? It would >>>>>>>>>> be good >>>>>>>>>> to resolve any such issues, since they won't be possible to address >>>>>>>>>> once >>>>>>>>>> the API is locked in by sites depending on it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I believe we've addressed issues that may require breaking >>>>>>>>> changes. You can see open >>>>>>>>> <https://github.com/w3c/webtransport/milestone/1>/closed >>>>>>>>> <https://github.com/w3c/webtransport/milestone/1?closed=1> issues >>>>>>>>> for the initial launch (this intent). I shared our plan >>>>>>>>> <https://docs.google.com/document/d/1X9-a03rtm0FqTW01nG6e7f91NAguGEv37mP964HrJlk/edit#heading=h.v9yxozj8naro> >>>>>>>>> at a WG meeting in May >>>>>>>>> <https://www.w3.org/wiki/WebTransport/Meetings#WebTransport_Bi-weekly_Virtual_Meeting_.2316_late_-_May_25.2C_2021> >>>>>>>>> and >>>>>>>>> we've been working to find and resolve such issues since then. >>>>>>>>> >>>>>>>> >>>>>>>> I see, creating a milestone for this is really handy! Are the >>>>>>>> remaining issue in https://github.com/w3c/webtransport/milestone/1 >>>>>>>> not blocking then, even issue #349 >>>>>>>> <https://github.com/w3c/webtransport/issues/349>? >>>>>>>> >>>>>>> >>>>>>> *Except for issue #349* we have consensus on discussions. As Victor >>>>>>> commented in this thread, we can ship WebTransport *except for * >>>>>>> customeCertificationHashes >>>>>>> <https://w3c.github.io/webtransport/#dom-webtransportoptions-servercertificatehashes> >>>>>>> if >>>>>>> needed. >>>>>>> >>>>>> >>>>>> If custom certificates is a nice-to-have then shipping without it >>>>>> seems fine to me. That would mean removing serverCertificateHashes from >>>>>> the >>>>>> dictionary, right? I ask because the spec also says something >>>>>> about NotSupportedError when the protocol doesn't support it, but it >>>>>> seems >>>>>> better to behave as if the feature doesn't exist at all. >>>>>> >>>>>> >>>>> The property is protected by WebTransportCustomCertificates >>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webtransport/web_transport_options.idl>, >>>>> so when we enable only WebTransport, the property will be invisible. >>>>> >>>> >>>> Great, thanks for confirming! >>>> >>>> >>>>> Looking through some other issues: >>>>>> >>>>>> - Can https://github.com/w3c/webtransport/issues/59 be resolved >>>>>> for the WebPKI case? If CSP currently has no effect, then adding it on >>>>>> later could be hard because some sites could already be using CSP that >>>>>> would block it, and those sites would be broken by adding CSP support >>>>>> later. >>>>>> >>>>>> >>>>> Yes I think so. We check the "connect-src" directive. It is tested as >>>>> csp-fail.https.window.js >>>>> <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-fail.https.window.js> >>>>> and csp-pass.window.js >>>>> <https://github.com/web-platform-tests/wpt/blob/master/webtransport/csp-pass.https.window.js> >>>>> . >>>>> >>>> >>>> That's good, the risk I was worried about doesn't exist then. Would you >>>> consider that this behavior is required by some spec, even though it's not >>>> mentioned in https://w3c.github.io/webtransport/? If not, then do you >>>> think it's reasonable to prioritize the spec work for this before this >>>> reaches stable? >>>> >>> >>> This behavior should be specified, and yes I think that effort should be >>> prioritized. I'm happy to work on that. >>> >>> >> >> I made a PR for this: https://github.com/w3c/webtransport/pull/367 >> >> >>> >>>> >>>>>> - https://github.com/w3c/webtransport/issues/175 sounds editorial >>>>>> but doesn't have that label. If any code would change as a result of >>>>>> fixing >>>>>> it, should this be done before shipping? >>>>>> >>>>>> I think this is to describe our current protection and won't affect >>>>> implementation. >>>>> >>>>> >>>>>> >>>>>> - https://github.com/w3c/webtransport/issues/236 has no >>>>>> discussion, could it have any impact on implementation? >>>>>> >>>>>> This is about how to describe algorithms in the spec in terms of >>>>> threading, and this won't impact implementation. >>>>> >>>> >>>> Again, thanks for confirming! >>>> >>>>> -- >> 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/CABihn6HK5uwpsnVpZurqhgtzMOb%3Ddee17Aakf9COanf_E-8ioQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6HK5uwpsnVpZurqhgtzMOb%3Ddee17Aakf9COanf_E-8ioQ%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/CAKXHy%3DdUMf59AFFVnTCYvq4h919xFJf6-9%2BOU%3DT%2B80NyD6a_RQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdUMf59AFFVnTCYvq4h919xFJf6-9%2BOU%3DT%2B80NyD6a_RQ%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/CAL5BFfWXezTr_63-fHJZ4A3YaEui17WxY0Aw-ARRUDmvDqyqKA%40mail.gmail.com.