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.
