I really liked Chrome SSH extension but now I've returned to using the ssh command line client on all three platforms.
The issue is wiring up the browser-hosted application with a custom network inside the browser. It's a truly interesting but highly disruptive concept and I'm curious how it will play out. Perhaps in the future every program will statically compile its own TCP stack and talk over RAW sockets, but... that's sort of throwing away everything BSD and Linux and Windows achieved over the last few decades in terms of OS abstractions.
Funnily enough, the Chrome SSH extension uses pNaCl which is wasm-like in a roundabout way (non-ISA dependent bytecode running in the browser). So it's really not so different from what tailscale is doing.
Perhaps in the future every program will statically compile its own TCP stack and talk over RAW sockets
A surprising number of common applications already do this.
I ran into a recent bug[1] caused by a Windows update where TLS handshakes would randomly fail. But this only presented in a few apps. Browsers and .NET apps were all completely unaffected because they don't use the OS level functionality to handle TLS.
Yes, I know pnacl very well- I used it as a sandbox for an idle cycle harvester that ran in the background of Google servers. It was never a workable technology (even when we did heroics to make it work) although many of the ideas were good.
TLS is different from TCP. TLS support might be provided by an OS, but it's certainly something an application can link in since it's really just a byte translator with some additional complex logic. TCP is an OS-level protocol for all the reasons that history chose it (having your network device and network protocol in the same ring).
Fair enough. I guess I just assumed that if the OS provided your TCP socket you'd also rely on it to provide TLS, but I'm sure I'm missing a lot of the nuance of why you'd mix and match.
Comments
I really liked Chrome SSH extension but now I've returned to using the ssh command line client on all three platforms.
The issue is wiring up the browser-hosted application with a custom network inside the browser. It's a truly interesting but highly disruptive concept and I'm curious how it will play out. Perhaps in the future every program will statically compile its own TCP stack and talk over RAW sockets, but... that's sort of throwing away everything BSD and Linux and Windows achieved over the last few decades in terms of OS abstractions.
Funnily enough, the Chrome SSH extension uses pNaCl which is wasm-like in a roundabout way (non-ISA dependent bytecode running in the browser). So it's really not so different from what tailscale is doing.
A surprising number of common applications already do this.
I ran into a recent bug[1] caused by a Windows update where TLS handshakes would randomly fail. But this only presented in a few apps. Browsers and .NET apps were all completely unaffected because they don't use the OS level functionality to handle TLS.
[1]: This is a link to the KB that fixed the issue, which was introduced in the 22H2 cumulative update (search for "SEC_E_ILLEGAL_MESSAGE"): https://support.microsoft.com/en-us/topic/october-25-2022-kb...
Yes, I know pnacl very well- I used it as a sandbox for an idle cycle harvester that ran in the background of Google servers. It was never a workable technology (even when we did heroics to make it work) although many of the ideas were good.
TLS is different from TCP. TLS support might be provided by an OS, but it's certainly something an application can link in since it's really just a byte translator with some additional complex logic. TCP is an OS-level protocol for all the reasons that history chose it (having your network device and network protocol in the same ring).
Fair enough. I guess I just assumed that if the OS provided your TCP socket you'd also rely on it to provide TLS, but I'm sure I'm missing a lot of the nuance of why you'd mix and match.