Show HN: Free open-source isolated browser for security | Hacker News Reader

Show HN: Free open-source isolated browser for security

github.com

71 pointsgraderjs32 comments

I don't get the licensing fees, at 1069$/year per user you could put each user on a powerful VM with GPU instead.

And I'm not talking under-powered VM, I mean 8-CORE, 48GB RAM, 400GB NVME SSD, 2Gbit connection, NVIDIA Tesla V100 16 GB... [0]

Pricing makes no sense!

[0] https://www.ovhcloud.com/en/public-cloud/prices/#397

Sorry the pricing needs revision.

Here's some guide-lines, under 17$/mo (350$/mo, 50 users).

Then you'll be able to compete with Cloudflares Browser Isolation feature.

https://www.cloudflare.com/teams/browser-isolation/

The pricing is pretty ridiculous from what I've just seen. That's a lot of money when you can just put it on metal yourself.

I agree. It needs to be revised. Thanks! ;p ;) xx

So under the hood it's chromium headless and you are streaming screenshots back using an extension

Curious why not run normal chromium and vnc the whole screen back using a web client such as novnc, would have solved most of your "Normal Browser UI things not yet implemented"

Not an extension. Just your browser, no download needed. So a "clientless" remote isolated browser. it runs headless Chrome, yes (but eventually I want to repurpose it to support other browsers that can be driven by DevTools/WebDriver protocol).

Short answer is because a lot of the work of this was building a custom "head", so having a browser engine without a head made sense. Slightly more detailed answer below... :) ;p xx

I might experiment with xvfb chrome and vnc in future. Other people certainly have success with this, e.g Reflect (YC S20)[0]. Maybe I got here accidentally. Original purpose was for mapping web app structure, and recording and replaying of web action sequences (automation) from any device. As most of the time the browsers were going to replay without anyone using them having xvfb seemed unnecessary. And doing the mapping and recording in one platform (real chrome + xvfb) then replaying in another I thought would risk many unnecessary, difficult bugs. Also having my own wire protocol based on DevTools, rather than use what a VNC web client uses, I believed would assist in more reproducible recordings and playback for automation.

Also I liked the flexibility and control provided by headless+devtools to change the UI, easily work on mobile, custom handlers for tasks like file upload and other modals, as well as the control over the viewport streaming. On streaming, I experimented a lot to get something working across a range of bandwidths, and settled on: a per-frame ack (to avoid congestion), frames over webrtc or binary werbsocket channels, and periodically switching to whichever of webrtc of websocket is faster.

I also want it to be really scalable. And I thought that headless+devtools would be much less resource heavy than chrome+xvfb, but I have no hard data on that and can't find any.

Plus I just liked the challenge. Plugging in Chrome+xvfb+VNC just seemed too easy, and I wanted something "meatier" (apologies to vegetarians, I'm on my way there, 'Proteinier'?) I could dig my hands into :)

[0]: https://news.ycombinator.com/item?id=23897626

Yo dawg. I heard you like browsing the web, so I put a web browser in your web browser so you can browse the web while you browse the web.

Exactly!! :P ;) xx I need to add that meme to the page :p :)xx

Jesus, please don't. The memey-ness is detracting from your presentation, a bit.

Knock it down 25%, unless its 100% genuine. Seems a bit forced from here.

Are you aware of pure-JS in-browser VNC protocol implementations such as http://guacamole.apache.org/ ? This works over websockets, so even encryption is covered. On the server side, run a Xvnc, fullscreen chrome without window manager or decorations. As the OP said, this should give superiour performance, responsiveness and features. And no need for a client side browser plugin.

Another thing you could look into is https://www.brow.sh/ -- they also have a pretty good performance and feature coverage. Maybe there's something your project can learn from them :-)

Yes, that's a good idea thanks! I'm really impressed by these web VNC projects, like guacamole and novnc. One thing I think I could learn is how do they send the frames?! They seem to achieve some interesting compression. I think their framerates are higher than mine, and also responsiveness. I definitely could learn something from them. For features, they're not really superior because I probably need all that control, and browser internals instrumentation I get with devtools protocol. E.g how do I upload a file over VNC? But it's a great idea, and thanks for sharing it with me! :P ;) xx

For brow.sh it's kind of a sad project. I mean because it's so popular, with > 13k stars, but the poor guy's only making USD44 a month from this work. I feel so sad to see that. It's very niche, and too niche and restricted for what I'm doing, but one thing I can learn from them is not to be them. I don't want to be doing this labor of love and putting in all that work, and then at the same time asking for donations and only getting 44 a month.

I like the text thing but it's just not what I'm looking for with this. I mean there might be but I don't think there's anything more I can learn from it :P ;) xx

I just tested out https://www.kasmweb.com/demo.html

They use a custom web VNC client with WebP. Definitely they have higher perceptual framerate and slightly higher responsiveness (actual lag) but the responsiveness is about the same. The real difference is the higher perceptual framerate. I think this is because of how VNC works by sending rectangles of only the changed region instead of the entire screenshot in WebP as I do.

When you compare the framerate on scrolling, or on full screen video, there's not much difference between the Kasm Web demo above, and my demo. With that said, there's definitely room for improvement in my framerate. And I could improve responsiveness with geodistributed endpoints (right now, I'm just using a server in Ohio).

So in future I could add support for checking the changed region, and sending only that region (possibly using the chrome LayerTree to only get and send the changed layers). So I could do that to increase framerate, while still getting all the benefits of my approach, such as full control of browser UI, seamless text pasting, file upload, co-browsing and seamless working on mobile. None of these things are supported by Kasm (at least in the demo above).

However, my focus is not on improving framerate right now. It's on building other features on top of this platform (such as the co-browsing support I added recently), and marketing.

Also I noticed both brows.sh and the Kasm web VNC demo take a long time to load. My app loads basically instantly, and has essentially the same responsiveness, making it highly useful for all kinds of work, as long as you are OK with the lower framerate.

I could also easily "increase" framerate by decreasing the image quality, and I'm considering adding a slider for that.

One thing that really impressed me about the Kasm demo was the audio was instant. I haven't been able to work out how to get rid of the 3 - 13 second lag I get with my pulseaudio / parec / lame setup. I wonder how Kasm is capturing and sending audio !! :P ;) xx

not related to the product itself, but what's with the quotes around the commit messages? (well, if "OK" can be named a 'message':) Does this come from some weird shell which doesn't strip quotes from git commit -m "OK" or so? A script which incorrectly double-quotes?

Correct on both counts. Somehow I know where I'm up to and I work on this alone so only for very important milestones or fixes do I include details. Normally, I'm just "saving my work". My custom script[0] is:

  set +e;
  message="$1"
  git submodule foreach --recursive 'gut "'"$message"'" || :'
  git add .; git commit -m '"'"$message"'"'; git pull; git push;
  set -e;

and my goto "save work" command like is `$ gut OK` :)

perhaps you can help me fix that script so I can use multiword commit messages without the quotes??? :) ;p xx

[0]: https://github.com/i5ik/environments/blob/master/commands/gu...

Not really an experienced bash user, but just dropping the extra quotes would work?

    message="$1"
    git commit -m "$message"

You'll have to pass the words in quotes though. Which I'd prefer because it's the common way. Otherwise you'd use message="$@"

Cool thanks! :)

I think the README could do with some use cases too, it's difficult for me to figure out when I would need to embed a browser in a browser, let alone pay for it.

Yeah, that's fair. I don't know how to market it. People encourage me into the security space, or the co-browsing space. People have also asked about process integration, where you want to include a 3rd party process as part of your app's flow without leaving the main app.

Before you figure out how to market it, you need to figure out who your user is (in other words: "who to market it to"). Seems right now you're not quite sure, maybe "security" or maybe "co-browsing", but if you want your marketing to be really effective, you need to know exactly who your message is suppose to resonate with, and then you can figure out the right message to market.

Thank you. I don't know. I'll have to figure it out. I'm taking a break from coding on this from now, to spend some time on marketing. I have this piece of tech, and not much idea who to sell to, or how to reach out to them. So far the only success I've had is with people reaching out to me. "Blind luck" in bound ;p:) xx

I prefer virtualization of Qubes OS. It allows to use any browsers and even has Whonix working out of the box.

Reminds me of Browservice: https://github.com/ttalvitie/browservice/

(which I discovered via Michael MJD's YouTube channel: https://www.youtube.com/watch?v=5MjZdKtv9ak)

Thanks for the link! :) Ah, yeah, this was very cool. I remember seeing it a while back.

Typo in the readme:

clientless, opne-source dual-licensed

Thank you

Is this open source Mighty?

Hahaha. NO mate, but good marketing copy (thanks for the idea;)).

I believe Mighty works mighty different. They have a focus on crystal clear ultra fast video streaming of the viewport (I'm not sure of their setup, but I've seen suhail tweet about GPUs and one tweet of an image of a "MPEG compression textbook"). I've considered experimenting with ffmpeg as well, but I'm satisfied with my current solution's usability and responsiveness, and low lag over a range of bandwidths, which I prioritize over high framerate, and for what I originally wanted it for a high frame rate didn't matter.

People have often commented that the frame rate is too low, or they would like me to make them a "co-browsing / remote browser video streaming" system to stream videos or watch them together. I just think doing streaming really well at high volume is both incredibly expensive and very difficult. I do this alone and I'm coming to the end of my (very gratefully received) GCP "cloud for startups" free credits, so "I have no plans to announce at this time" about doing ffmpeg or not :)

Just going to point out the obvious and say a co-watch remote browser definitely wouldn't work with Netflix. I love the confusion on people's faces when they try to do it over Zoom ("Why is the video black?"). Yay Widevine?

This is cool! Thanks for bringing that to my attention. I didn't know that and had never tried netflix until your comment just now. First I tried with Firefox, then with Chrome UAs, and tried importing a libwidevine.so. Nothing works, and Netflix says the error is a missing CDM component.

I suppose that's better that it doesn't work. I don't think Netflix / Spotify would be cool with that. It's a little disappointing to not me able to test out Netflix on this, but less risky :P ;) xx

That's caused by hardware acceleration ... I have not tried it. But I'd say make sure you are on a desktop using desktop zoom app and then a web browser for Netflix and turn hardware acceleration off. I can't imagine how widevine could stop that. Zoom would have to be working with Netflix to make it happen

> That's caused by hardware acceleration ..

Eh, no, this is because of DRM. The DRM that browsers now offer (wtf) allows browser applications to black out themselves if they detect things like screen recording. Not sure exactly how the implementation works (as DRM is generally a black box, on purpose), but it definitely is on purpose and not really related to hardware acceleration.

The API Zoom is using for screen sharing is probably the same API you'd use to record the screen, so when Netflix detects that, they chose to black out the content.

Reply on news.ycombinator.com