Chrome 130: Direct Sockets API
chromestatus.com
chromestatus.com
Direct Sockets API > Permissions Policy: https://wicg.github.io/direct-sockets/#permissions-policy
docs/explainer.md >> Security Considerations : https://github.com/WICG/direct-sockets/blob/main/docs/explai...
Isolated Web Apps seems like it mitigates majority of the significant concerns Mozilla has.
Typically today, a user must agree to install a package that uses L3 sockets before they're using sockets other than DNS, HTTP, and mDNS. HTTP Signed Exchanges is one way to sign webapps.
IMHO they're way too confident in application sandboxing but we already know that we need containers, Gvisor or Kata, and container-selinux to isolate server processes.
Chrome and Firefox and Edge all have the same app sandbox now FWIU. It is contributed to pwn2own ever year. I don't think the application-level browser sandbox has a better record of vulns than containers or VMs.
So, IDK about trusting in-browser isolation features, or sockets with unsigned cross-domain policies.
OTOH things that would work with Direct Sockets IIUC: P2P VPN server/client, blind proxy relay without user confirmation, HTTP server, behind the firewall port scanner that uploads scans,
I can understand FF's position on Direct Sockets.
There used to be a "https server for apps" Firefox extension.
It is still necessary to install e.g Metamask to add millions of lines of unverified browser code and a JS/WASM interpretor to an otherwise secured Zero Trust chain. Without a Wallet Browser extension like Metamask explicitly installed, browsers otherwise must use vulnerable regular DNS instead of EDNS. Without Metamask installed, it's not possible for a compromised browser to hack at a blockchain without a relay because most blockchains specifically avoid regular HTTPS. Existing browsers do not support blockchain protocols without the user approving install of e.g. Metamask over PKI SSL.
FWIU there are many examples of people hijacking computers to mine PoW coins in JS or WASM, and we don't want that to be easier to do without requiring confirmation from easily-fooled users.
Browsers SHOULD indicate when a browser tab is PoW mining in the background as the current user in the background.
Are there downgrade attacks on this?
Don't you need HTTPS to serve the origin policy before switching to Direct Sockets anyway?
HTTP/3 QUIC is built on UDP. Can apps work with WS or WebRTC over HTTP/3 instead of sockets?
Edit: (now I can read the spec in question)