Bug 1818754 Comment 14 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

Note, changing needinfo as no response from rjesup@jesup.org
MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. ~There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?~ Yes. We appear to support WebTransportReceiveStream

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

Note, changing needinfo as no response from rjesup@jesup.org
MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. ~There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?~ Yes. We appear to support WebTransportReceiveStream

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

4. `WebTransportReceiveStream` states in spec
   > A `WebTransportReceiveStream` is a `ReadableStream` providing incoming streaming features with an incoming unidirectional or bidirectional WebTransport stream."

   Really? It seems to only be returned by the `WebTransport.incomingUnidirectionalStreams` property? The incomingBidirectionalStreams returns a different object. Is this a typo in the spec or am I missing something?

Note, changing needinfo as no response from rjesup@jesup.org
MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. ~There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?~ Yes. We appear to support WebTransportReceiveStream

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

4. `WebTransportReceiveStream` states in spec
   > A `WebTransportReceiveStream` is a `ReadableStream` providing incoming streaming features with an incoming unidirectional or bidirectional WebTransport stream."

   Really? It seems to only be returned by the `WebTransport.incomingUnidirectionalStreams` property? The `incomingBidirectionalStreams` returns a different object. Is this a typo in the spec or is it that `WebTransport.incomingUnidirectionalStreams` will include a read stream for the `incomingBidirectionalStreams` as well?

Note, changing needinfo as no response from rjesup@jesup.org
MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. ~There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?~ Yes. We appear to support WebTransportReceiveStream

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

4. `WebTransportReceiveStream` states in spec
   > A `WebTransportReceiveStream` is a `ReadableStream` providing incoming streaming features with an incoming unidirectional or bidirectional WebTransport stream."

   Really? It seems to only be returned by the `WebTransport.incomingUnidirectionalStreams` property? The `incomingBidirectionalStreams` returns a different object. Is this a typo in the spec or is it that `WebTransport.incomingUnidirectionalStreams` will include a read stream for the `incomingBidirectionalStreams` as well (i.e. you could read from a bidirectional stream using either the WebTransportREceiveStream, or the `WebTransportBidirectionalStream`?)

Note, changing needinfo as no response from rjesup@jesup.org
MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

1. ~There is a data compatibility in [`WebTransport`](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport#browser_compatibility) that indicates Chrome supports BYOB readers. Does FF also support these readers?~ Yes. We appear to support WebTransportReceiveStream

2. I tried to get some clarification of how `serverCertificateHashes` work in https://github.com/w3c/webtransport/issues/508 - a useful response that did not answer my questions. Can you help?
   Specifically, the user of this API sets the set of certificate hashes when they create the `WebTransport`:
   - My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct? 
   - Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.

3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    ```js
   //String containing SHA from website
   const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 

   // Convert SHA-256 string to Uint8Array
   const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
   
   const transport = new WebTransport(url, {
     serverCertificateHashes: [
       {
         algorithm: "sha-256",
         value: sha256Array 
       }
     ],
   });

4. `WebTransportReceiveStream` states in spec
   > A `WebTransportReceiveStream` is a `ReadableStream` providing incoming streaming features with an incoming unidirectional or bidirectional WebTransport stream."

   Really? It seems to only be returned by the `WebTransport.incomingUnidirectionalStreams` property? The `incomingBidirectionalStreams` returns a different object. Is this a typo in the spec or is it that `WebTransport.incomingUnidirectionalStreams` will include a read stream for the `incomingBidirectionalStreams` as well (i.e. you could read from a bidirectional stream using either the WebTransportREceiveStream, or the `WebTransportBidirectionalStream`?)

5. Any chance of a technical review of the newly documented methods: https://github.com/mdn/content/pull/26529#issue-1691765529 ?

Note, changing needinfo as no response from rjesup@jesup.org

Back to Bug 1818754 Comment 14