Two days ago, a proposal to add "unsafe-webtransport-hashes" to the Content Security Policy specification was merged.

https://github.com/w3c/webappsec-csp/issues/683
https://github.com/w3c/webappsec-csp/pull/791

Here is how I understand the proposal, based on reading it and the documentation for WebTransport. I'm by no means an expert on WebTransport - I had never heard of it before today.

WebTransport is intended to replace Web Sockets; it allows a website to connect to a server over HTTP/3.

One feature of WebTransport is serverCertificateHashes, which is passed as an argument when creating a new socket.
serverCertificateHashes allows a website to bypass the normal public key infrastructure, instead telling the browser what certificates to trust.
It does this, as the name suggests, by providing the hashes of the certificates.

There is, of course, an inherent risk which comes with replacing the existing PKI with DIY. Allowing websites to restrict usage of this feature helps mitigate some of this risk.

This proposal builds on the existing connect-src CSP policy, which controls technologies like XHR, Fetch, etc.

If a website does not set connect-src in its Content Security Policy or doesn't have a CSP, then it can use serverCertificateHashes as it wishes.

However, if it sets connect-src, then serverCertificateHashes is disallowed.

That is where unsafe-webtransport-hashes comes into play. A website can allow specific certificates to be used with serverCertificateHashes by specifying the hashes of those certificates in unsafe-webtransport-hashes, which is part of the CSP and falls under connect-src.

So, as I understand it:

• no CSP or no connect-src: can use any certificates in serverCertificateHashes
• connect-scr set but no unsafe-webtransport-hashes: can not use any certificate in serverCertificateHashes
• connect-scr is set and contains unsafe-webtransport-hashes: only certificates allowlisted in the CSP are allowed for serverCertificateHashes, all others denied

All of this is based on reading the issue thread and doing a little background research. I probably got some of it, or all of it, wrong.
Point being; it is an interesting but very niche proposal.

#WebTransport #WebSecurity #ContentSecurityPolicy #CSP

WebTransport is almost here to allow UDP-like exchange in the browser

https://developer.mozilla.org/en-US/docs/Web/API/WebTransport_API

#HackerNews #WebTransport #UDP #Browser #Technology #Future #Internet #Development

日刊IETF (2025-10-20) 第1部
https://qiita.com/tetsuko_room/items/9c33402203a38a7d4a2f?utm_campaign=popular_items&utm_medium=feed&utm_source=popular_items

#qiita #IPv6 #ietf #WebTransport #internet_draft #日刊IETF

1/

WebTransport seems interesting.

https://developer.mozilla.org/en-US/docs/Web/API/WebTransport

However, this seems like a poor design choice (by the creators of WebTransport):

"Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers."

...

#WebTransport

The new 0.16 version of the open source Node.js multiplayer framework, #Colyseus, is introducing #StateView, experimental support for #WebTransport, and more.

https://gamedevjs.com/tools/colyseus-0-16-released/

#gamedev #gamedevjs #node #nodejs #OpenSource #update