container-shell VS BrowserBox

Very nice. I'll def. check it out.

I've created https://github.com/jrz/container-shell myself, which has a similar mindset, but is based on docker and is just a single bash script.

Not really, you'd still need a proper chroot / etc.

Check out https://github.com/jrz/container-shell

Just use orbstack, it gives you https and hostnames.

Shameless plug: https://github.com/jrz/container-shell in combination with orbstack. Isolated dev environment, easy to use, local tools, https

Check out https://github.com/jrz/container-shell it is one of the use cases. Not a VM but a docker container

This is great. I want to add WebWebView to the list and show 100% compatibility, because we run Chrome on the server and open a portal to it via an iframe. You can see it running here: https://browse.cloudtabs.net/signupless_sessions and code here: https://github.com/BrowserBox/BrowserBox - But we have yet to release a developer API. Seeing this, we will double our efforts!

Is that right? Could be a recent acquire if it's DOM mirroring.

I heard CF acquired S2 a few years ago, and what S2 did is they created a WebAssembly binary that composited the browser SKIA draw instructions on the client, and streamed the SKIA draw instructions from the server. Not without its issues, but certainly useful.

What we do is just stream pixels to the client. Yes it's expensive in terms of bandwidth, relatively. But the advantage is simplicity. And with a close server and bandwidth trending faster and cheaper, with the increasing drive to video consumption across media, I don't see bandwidth as an issue.

If you're interested, our code is on GitHub: https://github.com/BrowserBox/BrowserBox

Click through for a version on a server close to you that you can play with now.

Source code here: https://github.com/BrowserBox/BrowserBox

This demo is probably not really ready for a widespread audience, but luck it I’m just posting it anyway

> Edit: parent commenter seems to be promoting their product. Looks like a random remote browser, perhaps avoid entering important credentials there.

True. Maybe I should have put a full disclosure? I thought it was obvious, but I get if it wasn't. I'm sorry for not being more clear!

It's a good point to advise people to avoid entering important credentials in something that probably looks untrusted. I'd also advise that at this stage as we have no SLAs for now, and are just testing this SaaS-to-be demo of this source-available product:

https://github.com/BrowserBox/BrowserBox

Thank you for pointing out the reasonable and important security concerns. Although I should have probably done that myself, I was just so eager to help!

Aside: I am surprised tho that you were unable to even login on your VPN. I would think that the IP blocks we run the browser form and those of a VPN would be in the same category of 'cloud IPs', so why should it work on CloudTabs but fail for you directly on a VPN? Who knows?

These are difficult problems and perhaps the modern web has developed at a pace that older tech like RDP has not kept pace with. But Guacamole bucks that trend. The video shows how far it has come.

Guacamole is good, and I love that it's clientles and works in the browsers, but VNC lacks sound so you need to do that separately. Also the input lag when remote frames increase in frequency is challenging.

If you're looking for something lighter weight and possibly smoother and faster (albeit non-free software with a non-commercial option), check out BrowserBox: https://github.com/BrowserBox/BrowserBox

Solving input lag, and maintaining responsiveness across a range of bandwidth situations has been one of our priorities and I think we've mostly achieved.

We've accomplished this through a combination of sensible heuristics for congestion control, and using WebRTC with a fallback to WebSockets when faster. We also have audio out of the box, no set up required!

However there's always room to improve, which is why it makes it so exciting to work on. Depending on how close you are to a server you may encounter lag issues, too. Check out a free live demo of it working here (sorry, signup is not supported yet!):

https://browse.cloudtabs.net/signupless_session

Some other problems we solve that are not always so easy to configure with Guacamole (and are harder to do with an RDP layer in general), but much easier for us as we virtualize the browser itself are first class mobile support.

Obviously that's an issue with remoting desktops from small form devices in general, but if a browser is all you need remotely then we got your back! :)

Same time, BrowserBox will not be for everyone. It all depends on what you need. Get on touch if you are interested!

Run your browser on a remote machine? Using say BrowserBox: https://github.com/BrowserBox/BrowserBox

Full disclaimer: my company develops it.

This sucks. Supply chain is such an issue.

Even tho we don't currently target any npm releases, I make use of socket.dev to monitor my project by creating an npm release for it. But my project BrowserBox (lightweight virtualized web browser) only uses ~800 dependencies including all descendents, with only 19 top-level deps (cool your heels non-JavaScript folks, this is comparatively lightweight for a full stack boing).

I'm considering just snapshotting all 800 deps into a @browserbox namespace at npm. And then tracking any vulnerabilities discovered and patching the fixes.

It sounds crazy, but that's where we are. At least that way I "own" all the dependencies and can guarantee (up to company security at least) that we don't have supply chain vulns on the Node/JS side.

https://socket.dev

https://github.com/BrowserBox/BrowserBox