I don't see any other RBI / CBII vendor open sourcing their platform and in the security industry "closed source" can create issues.
But what about business defensibility?
I agree. Open sourcing removes the trade secret aspect that could make a defensible business.
At the same time, a determined hacker would already have my source code. A hacked "free wifi" connection here, a bit of social engineering there, and my so-called "competitive advantage" could be easily removed. Access to GitHub, Gitlab, other accounts would prove no obstacle for someone motivated, and open sourcing is a way to remove the advantage any small group of parties has by keeping it secret.
For the CE release, I deleted the Git history (it became too difficult to deal with branch rewrites trying to remove all the cruft and deployment secret keys etc).
But the actual current working repo for the non-free version has ~ 2400 commits[0]. And the repo that I forked that from (~ 7 months ago), I'd closed 238 issues, and the repo I forked that project from I closed 200 issues. Those previous repos are all my work built from the ground up within this last ~12 months as well. The current working repo has closed 124 issues.
And it's actually a little bit over 1 year, and if I count the Gitlab contribs show there, it's over 5500.
So, yeah it's been about 2000 hours I think. Working full time every week day and most weekends, and often longer than regular hours (but also dividing the work up in the day into sprints because that's how I manage myself to work best).
Main audience is people and organizations who are having problems with malware and cyber attacks.
Business model I am still working on, but it's a mishmash of licensing (+ maintenance, for hybrid / on-prem) and pay per seat (for cloud-based). Could be other ways to provide value.
Yes! I requested an invite and reached out to Suhail on Twitter (I actually interviewed at Mixpanel ~ 18 months ago before I knew anything about MP or MA) about a technical question about MA that I got to thinking about from my experience building BG but didn't hear back from them.
Mixpanel was a cool interview. I remember the question was about data structure for a rank system (it was a heap). The office in SF is beautiful, and the lunchtime catered food, was great.
I guess I'd have more to say about MA if I knew more about it! I did not try it yet and I don't know how they make Chrome faster in the cloud and deliver a seamless broadcast of the screen to the user, but with enough smart people, I'm sure it's possible.
As I said in a previous comment, I definitely think the future is mreo 'app virtualization' in the cloud, in some sense perhaps MA is starting at the beginning of that curve.
> I definitely think the future is mreo 'app virtualization'
Why would you think that? Where do you see this trend? Their app looks incredibly stupid to me and it is hard to imagine any large number of people that would use it.
Your project aims to provide security, which is an interesting goal, that I think security-conscious people would want to use.
But to virtualize a browser... for performance? For browser apps (which are already "virtualized" desktop apps, of sorts), trading off enormous amounts of bandwidth, for what, cheap RAM sticks that are getting cheaper by the month and faster SSDs for quick swap? For what usage case? That one guy who happens to have a chromebook but needs to run 100 tabs actively?
You could just run "unload tab" extension already...
Or like just have a desktop that you VNC into... Which all of the people that need this have been doing for decades...
I'm sorry to give you a link but I addressed this here[0]. The TL;DR is computing advances will allocate disproportionately to the big cloud providers, consolidating centralized/server compute which, coupled with 5G and AI, will lead to high-bandwidth experiences streamed to comparatively "thin" devices.
For that being said, I agree that virtualizing apps "right now" is stupid outside a niche unless you have some secret sauce (like Mighty must, otherwise why?), because it's too much overhead.
Preserving resources is why I run headless, and that's why I avoided WebRTC/VNC/video instead of judiciously sent screenshots only on change.
>consolidating centralized/server compute which, coupled with 5G and AI, will lead to high-bandwidth experiences streamed to comparatively "thin" devices.
this will also give absolutely new meaning to "deplatforming" which will now mean that not only you can't post on some social media website but you can't use any computer at all.
It might be work stopping the browser 'loading' itself inception style with some kind of blacklisting of loadable urls - I assume you already have something to protect against SSRF type attacks on the platform itself.
Sorry, I need to restart it. I resized the instance, then forgot. Hold on a couple minutes while the queue of browsers rebuilds on restart. Thanks for letting me know :)
Edit: It's getting kind of slammed, right now. I might need to resize it up again in a while.
Edit2: Alright, I have to resize it, it needs more power. Hold on while it comes back up. Queue is rebuilding @23:13 ET.
Could someone write a few sentences about what it is and how it works, and why it is significant? I see neither this post, the GH repo, nor its website really says much of anything on the subject. I only see info about why it’s being open sourced and how to set it up. If someone were to go to all that trouble, I am surprised they would stop short on just providing basic info.
Sure, BrowserGap is a remote browser isolation product. RBI means accessing the public internet through a browser that runs in the cloud, rather than through a browser that runs on your device. This helps protect you from attacks on the web.
Wow, that's awesome! Seems like it opens a lot of powerful possibilities.
I am a pretty technical person but also didn't know (and couldn't find) info on what RBI is and how it can be used - would love to see this information highlighted on GH and the website.
And, if you're interested, read on for more detail.
It works by providing a thin client over the web that you connect your regular browser to. The thin client provides an interface to a remote browser that you interact with the browser the public internet.
This is significant because the internet is a cesspool of attacks. Malware, ransomware, virii, tracking, exploited PDFs, ways to deliver device zero days over the web, browser zero days. All these things can lead to the security of your device and network being compromised, causing significant inconvenience, distress and loss for you.
BrowserGap and the RBI methodology acknowledges that not all threats can be detected and neutralized (such as by virus scanners), in order to face that reality, RBI adopts a "isolation" posture towards threats, effectively isolating them in the remote machine and preventing them from reaching your device.
With BrowserGap, in order to render the content of a web page, the only thing we send to your device form the remote page is pixels. So no HTML, CSS, JavaScript, etc from your browsing is ever executed on your device.
Cloud-based internet isolation is another name for this security practice and it is an emerging industry. Symantec recently acquired a company in this space, and Menlo Security was awarded[2] an agreement to build a CBII prototype for DISA, after a June 2018 request for RBI solutions that could eventually serve 60% of DoD's ~ 3 million users[0][1].
I mean, in theory the web is a cesspool of malware, but with reasonably good content blocking (I’m not even in the completely-disable-JS crowd) and conscious avoidance of shady sites, I managed to pretty easily stay clear of all attacks so far, at least over the past decade.
Those way more paranoid than me still have the option of using local VMs/containers without too much compromise. Then the attacker really needs an exceptional exploit chain to escape all the way; it’s hard to imagine any group blowing such a valuable chain on a drive-by.
So, why would anyone sacrifice the ability to interact with text, resolution, color accuracy, frame rate, etc. to reduce the minuscule chance of drive-by attacks (assuming otherwise reasonable opsec)? Extremely high value targets?
But then, why would extremely high value targets trust a MITM? (Self-hosting apparently changes that to some extent.) Also, even if you run your browser in the cloud, that browser could still be hacked and leak sensitive information or actively modify traffic, no? So this isn’t even bulletproof for high value targets.
I'll tell you the value of this software. I can build software for non prod environments and allow my developers/testers access. for instance, with wordpress, domains are hardcoded into the database leaving you with risky sed commands against mysqldumps. With this I can launch wordpress into its own environment where www.foobar.com resolves but I can run all dev code there.
I currently use a proxy and have instructions on how to use FoxyProxy to access each env's environment. This will provide for a much nicer UX where you simply click a link and you're brought to a virtual tab in that env. I'm sure some things will break, so the proxy is a backup, but for 90% of our work I think this is amazing!
Solves any app problem where you have the same hostname per environment
> sacrifice the ability to interact with text, resolution, color accuracy, frame rate, etc.
it’s very much an understatement... Pretty sure your devs/testers won’t appreciate the experience. Frontend devs in particular can’t possibly work with this.
I fail to see why it’s hard for you to spin up (possibly gated) dev/staging instances; certainly much easier and much less resource intensive than something like this.
Anyway, your use case only makes sense when the code can be self-hosted, but apparently this product / product category has customers before the source is opened up, and that’s what I’m curious about.
Customer base is people and organizations who are having problems with malware and cyber attacks.
> Have you tried using this? When I said
> sacrifice the ability to interact with text, resolution, color accuracy, frame rate, etc.
> it’s very much an understatement... Pretty sure your devs/testers won’t appreciate the experience. Frontend devs in particular can’t possibly work with this.
I totally agree the image quality can be much improved. So I'm really sorry you had this experience today trying it out!
Would you be unwilling to mail me cris@dosycorp.com and I can contact you if and when I have image improvements to share?
Initially, I used JPEG for all clients, then for clients with browsers that support WebP (chrome) I switch on WebP since the quality increase is a LOT (but WebP in FF looks pixelated, so I hope I can find a way around that), even tho the bandwidth is the same.
For Safari and iOS the quality is on JPEG. It sounds like it has sacrificed the ability ot interact with text, resolution, color accuracy and frame rate, etc. I'm really sorry about this.
Some people seem okay to roll RBI out in a test deployment, without the code being open-sourced. I can't speak directly for them, but I assume that Symantec (who bought FireGlass Browser), Menlo, WEBGAP, Light Point, Ericom, Authentic8, Citrix all have some customers even tho they are not OSS. I think that, often, as long as the contract provides the ability to examine the code if required (due diligence) even without publishing it openly, sales happen.
It sounds like you're unfamiliar with RBI, is that right? This is still an emerging industry so it makes sense to me that even if you are in security you are unfamiliar with RBI.
Appreciate the detailed response. Over the past few years I've seen a couple of similar remote browser services and was curious who actually need it, glad you shared firsthand knowledge.
Now I can see that while this would probably be an overkill security-conscious individuals, it might make sense for organizations because there are always employees who can be easily tricked into clicking anything. I do wonder whether it's more effective and productive to instead enforce host-based blocking + browser-level content blocking + lightweight virtualization (like Windows Sandbox? Not sure how well it works since I'm a Mac user for the most part), but I'm in no position to evaluate for organizations.
Having checked Symantec's website, they seem to advocate falling back to a remote browser when the site is potentially risky, which sounds reasonable.
> then for clients with browsers that support WebP (chrome) I switch on WebP since the quality increase is a LOT
Yeah, I first tried the service on my iPad Pro, image quality was terrible. I have since tried it again in desktop Chrome and it's definitely passable. That's unfortunate.
Anyway, I'm probably not in the target market, but best of luck to your business.
Interesting hearing you know about RBI. Did you evaluate any of the other services? What did you feel about them?
I definitely think the approach you say (host level blocking, content blocking and some lightweight virtualization, like Edge/Windows Sandbox, or a local VM) is a valid one that reduces risks.
I think it comes down to considering, when attacks inevitably occur, where do you want to be doing the cleanup? Zapping a few containers, or instances in the cloud and starting them frehh, or decontaminating the local machines and network?
Sorry about the typo (in my comment below)! I couldn't edit it past the edit horizon. I meant,
> Genuinely curious: who's your customer base?
Anyway, thank you so much for being interested in this product, especially for helping make the space for me to speak about the type of customer, the risks they face, and their reasons for adopting BrowserGap. I really appreciate your time on this!
At my 30 second glance I saw both problems and solutions with using it. But if didn’t use software based on problems, we wouldn’t get anywhere :) It’s open source so my mind is leaning toward crack it open and fix the shortcomings for the use case
Thanks for this feedback, you make some great points which I really appreciate you taking the time to make. And your experience of being malware free is mostly my experience as well.
It sounds like with reasonably good content blocking a person can avoid all attacks, and it looks like using local VMs/containers mean then the attack needs an exceptional exploit chain to escape all the way, and it's hard to imagine any target being caught in a drive-by.
I agree. Also, internet-based attacks are a real problem for many businesses and organizations. For example, in 2016 Singapore government mandated that RBI had to be used because of ongoing attacks.[0]
How can it both be true that most people avoid any attacks whatsoever (and therefore that most simple measures are sufficient) while at the same time, malware is a real industry inflicting real damage on organizations?
I think of malware as an "industry" and as a collection "criminal enterprises" and from that viewpoint the malware industry has certain goals and markets it seeks to penetrate. If you don't find yourself in one of those target groups, that's a good thing. If you do, then you probably are already exploring RBI or CBII to some extent.
So your logic is correct and it looks like you are simply not in the target group.
At the same time, I think categorizing the only victim of web-based malware that can benefit from RBI/CBII as "extremely high value targets" is misleading. Perhaps the finance department in a Fortune 500 company is an "EHVT", but there's a lot of web-based attacks that succeed at targeting businesses and organization units of many different sorts, and the costs inflicted are significant and important, not just to "EHVTs".
Your concern about trust and the cloud is valid, and perceptive, as is the solution you propose (self-hosting). Self-hosting is indeed the right choice for many. That's one reason I think OSS has a role to play in RBI/CBII.
Even if the security is not significantly enhanced over a content blocker, tracking using JS will be much harder (assuming the cloud device is randomized in some way).
Question: why have the protocol based on pixels when you could use vanilla css and html? Like SSR, you could render the page with js remotely and capture the live html/css render to display. Of course, this process would be tricky as you'd also have to look for iframes and also generate bake out its render too. While much more complex, it would be far more efficient than sending back a pixel video stream.
It's too complicated. The complexity in the code leads to more opportunities for bugs and exploits and more maintenance cost. Also it breaks the isolation model since you can do all sorts of crazy exploits just with HTML and CSS (animation event listeners for XSS etc).
I investigated this path after PoCing the original (you can see the code in a directory plugins/appminifier and public/voodoo/src/plugins/appminifer, I think) but there's all sorts of interaction issues that arise when you attempt to filter the HTML in this way.
Efficient in terms of what? Bandwidth, from a certain point of view but you lose the "source of absolute truth" that a screenshot is, and at the cost of interaction quirks. Also, not necessarily CPU efficient, as you have to do a lot of bookkeeping to transmit events to the right places and keep the local tree in sync with the remote tree.
The main reason I avoided it was the security holes introduced by breaking the strict isolation model of pixels, and the complexity.
You're welcome to fork and improve on the work begun in appminifier! If you go down that path, just know, there be dragons, and good luck!
The entire point of this project is to bypass the browser rendering engine locally and risk exposing all of its bugs, zero days, vulnerabilities, tracking etc. If you would be just copying HTML, that would give a regular old proxy server. This project is about security, not just hiding the ip address.
> it would be far more efficient than sending back a pixel video stream
Yes it would also deliver back exactly all the vulnerabilities to you that this project was specifically made for protecting against... Are you sure you have read its description? The whole point is to do dumb pixels that can't be exploited.
Great work, and so great of you to open-source this - I really hope you keep it that way!
Would be really cool to set this up and set the server up to do some proxy-hopping to make IP tracking more difficult as well, regardless of client device and when roaming.. While I'd be more leaning towards self-hosting, if you set this up as a subscription service, your users will also benefit from sharing the same pool of IPs (though I imagine you'd also face issues with getting flagged/blacklisted/CAPTCHAd a lot through abusers and bots, that will be significant work to polise if you go that route).
Darn... I'm working on almost exactly the same project. The big challenge is getting access to server hardware that is actually meant for webbrowsing. Not only are AWS et al expensive, they primarily offer "webservers" which are optimized for very light not very CPU intensive workloads and needless to say they also don't offer hardware accelerated video decoding.
Hey! Sorry for taking so long to get back to you. I saw your comment and wanted to respond, and I have been very busy today because of this post.
Thanks for sharing your feeling about this.
It looks like you're working on almost exactly the same project, and that the big challenge is getting access to server hardware for webbrowsing, because not only are AWS etc expensive, they primarily offer "webservers" optimized for very light not very CPU intensive workloads, and needless to say they also don't offer hardware accelerated video decoding.
Wow! Sounds like you're doing something interesting. Are you uninterested in collaboration? I was thinking of ways to make the video better, but right now I'm basically just using DIY "MJPEG" over websocket.
As for the server hardware, I was decided to join the Stripe Atlas program at the start of 2017, and from that I was able to get 5K in AWS credits, and then more Google Cloud credits, and I also applied to IBM and Digital Ocean on my own and got credits from them as well.
So, so far I have been able to develop and then demo this (like today) without significant monetary cost.
I also have some tips for you, because resource usage was one of my concerns, but TBH I find Chrome headless actually always uses less CPU than I imagine. It's all about the page that it is rendering. The page determines everything, but Chrome itself is very light. So when I've budgeted for like 1 CPU per user, it's actually possible to get much more than that. And memory is the big thing that Chrome does lightly, it uses barely any RAM even with 100s of users on a machine. I was surprised by that. 100 users running Chrome and only ~ 20 Gb of RAM used.
Also, regarding video, because I'm avoiding expensive video encoding (just sending screenshots) I avoid the CPU load of doing that. I've experimented with doing more processing of the frames, but it just throws the load way off.
I chose to keep it simple and I'm pleased with that. At the same time, I want to explore ways to improve image quality.
I did an experiment a while ago with streaming chrome to twitch from a gpu-enabled ec2 node and it worked quite well. Was able to stream a webgl experience at 60hz.
We have a webgl app (hubs.mozilla.com) we wanted to determine the viability of doing cloud streaming of remotely.
here's some personal notes from this. i didn't work on containerization, just raw VM setup. had to get x11 up and running and then set ffmpeg up for hardware streaming.
Hmm, I'm not sure if people in the western world can use it but in South Korea (with a 1Gbps network) this is basically unusable.
It has too much latency, text doesn't get entered, scrolling doesn't work, etc... Is the experience from US similar? Or is this just b.c. of server latency?
If you're talking about the free/demo version, it's hosted in a US-East GCP instance and the author said elsewhere in the thread that it's under heavy load, i imagine a self-hosted instance would work well.
Okay, much better now. I’m writing this comment in the Cloud Browser on my iPhone! :-)
It’s now ‘usable’, but definitely not a good environment. Scrolling is unbearable, and once you start scrolling it doesn’t stop, so it’s a pain to navigate.
Hahah! That's awesome to hear you're writing it in the Cloud Browser on your iPhone!
But I'm really sorry about the scrolling. Sounds like it's unbearable. I need to fix that!
I added a "fast mode" for scrolling where if you scroll more than 40% of the screen in one go, it accelerates the amount, so you could try scrolling smaller, but I don't feel that's a satisfying solution for you. Scrolling is really important to get right, I'm very sorry about that!
If you want, email me at cris@dosycorp.com and I will work on it and let you know.
Edit: I've had other reports about Safari / iOS being really unusable today. I just tried turning up the image quality for iOS / Safari it should make things better.
I just want to let everyone know there's also a version for Asia-pacific (in a HK Google datacenter) that will probably be faster if you're not in a US timezone.
A while ago I wrote something very similar - https://fasterbadger.com - see discussion at https://news.ycombinator.com/item?id=9679464 - based on PhantomJS - didn't put nearly as much work into it though, it's still very much in prototype stage - the goal was different though, not so much for privacy but for browsing JS- and CSS-heavy sites (e.g. most news sites) on legacy devices/phones, especially where bandwidth is at a premium.
I'm looking at your app and I love the long scroll feature. How did you do that? It's so cool how you can scroll down the page natively, and the image updates, that's really incredible.
And I'm reading the initial discussion, and it's ... in 2015! Wow, how did you do this back then! I think thing's are so much easier now with all the features in the protocol.
I am really interested in how you did this and I love the site. It's very cool and I prefer it to my own work in many ways. Would you be a terrible idea for you to contribute to BrowserGap?
About half way through development, I was travelling and buying 4G data sims and I also thought I needed to use it for that (easily use 50Mb just on a news site).
So I made a HTML only version (no images, just stripped back HTML, you can see the work in the various 'appminifier' subdirectories somewhere in the repo). It saved me data, but introduced lots of quirks. At some point I realized it was too difficult, and I was committed to another idea with it, rather than this low bandwidth, so I stopped working on that feature.
Also, I love the Open in new tab? feature you have. This really rocks. It made me so happy to see this work! Thank you so much for sharing with me. :)
I wanted to get a scrolling feature like you have and I couldn't think of a way to make it work. If yow could do that in BG I'd love it!
Liked your product from your previous submission and liked this one as well. I think it can help some people where censorship is present, but not particularly for me.
Interested to hear about professional use cases for this kind of tool. I am working on a cloud-based sandbox browser very similar to the OP here: https://www.sandboxbrowser.com/
My target audience is software developers, QA engineers, and Ops people who want a predictable isolated browser environment for doing various forms of testing / hacking.
Cool idea at first, but on second thought, how is it supposed to mitigate internet threats? Users need to download files, open them with local apps, upload local files. All necessary channels for RCEs and exfiltration are still there. Current malware codebase might get stuck with it, but it's a matter of time and adoption. Other threats like clickjacking, cryptomining, phishing would just work as before.
First up that is some great feedback and raises a lot of really good points.
I don't know if you're missing anything but this feedback about files is on point. I really appreciate it. And I'm surprised no one raise this until now. Thank you for your time thinking about this and for making the space for me to speak about it.
> Users need to download files, open them with local apps, upload local files.
Ideally, user's don't download files, they use the Secure remote file viewer[0] (which currently handles PDFs, DOC/X, XLSX, etc), so that helps with exploits from there (such as the Chrome zero day from PDFium that recently occurred). No configuration is required, it automatically jumps in whenever a download starts.
Also, because the browser is running in the cloud, that "download" actually only happens between the web and the cloud. The file literally goes down to a temporary directory on a server in the cloud, before being sent to the secure file viewer. That file never touches the client's device or network. And the secure file viewer only sends pixels to the client, because it converts all documents to images, and then, the browser sends a screenshot of that page. So it's like... two layers of images.
Anyway, that helps mitigate the RCE threat from exploited file objects, browser and device zero days. And no HTML,JS,CSS from the browsed page is ever sent to your device.
As for opening with local apps, that's debatable with things like G Suite and Office 365. But we can integrate with a corporation's SWG (secure web gateway) and file policy so BG doesn't degrade their existing security, but it does provide an extra layer.
As for uploading that is absolutely required, otherwise many things would be unusable. I don't pretend that BG provides any sort of malware or virus scanner (mainly because there is not download), but as for uploads, it's possible to integrate into an organizations' existing SWG technology to gate-keep content that leaves, and also white and black list accessible sites.
> Current malware codebase might get stuck with it, but it's a matter of time and adoption.
I agree that to some extent, security is an ongoing "arms race". But there seems to be limits to what malware can achieve through the exploitation of pixels sent to the device. It puts a big limit on their attack vectors.
It sounds like there's no point taking any steps, because malware can always find a way through. When you say something like this, I feel like I'm wasting my time talking security, because it looks like you'd never adopt a mitigation anyway.
> Other threats like clickjacking, cryptomining, phishing would just work as before.
That's a great point. I don't think this tool can prevent against social engineering threats like phishing, fraud and deception. It may even may them worse by allowing users to feel "more secure" and therefore act more rashly.
No tool provides perfect protection, but BG can reduce the attack surface and isolate and contain many threats away from the device and network of the client. In the case of clickjacking, older browsers can be vulnerable because of CSP headers, but with BG you always proxy through the latest chrome.
As for cryptomining that will simply not work well at all. We have monitoring software that puts hard limits on CPU, memory and bandwidth for each browser and each user. Please, go ahead and try it.
Remote file viewer is a good idea. The hard part is convincing users to a workflow where they can't save their files, only view or print them. There are tons of software with tons of proprietary file formats. One day you'll have to give up and allow downloading.
But I see a certain segment of small business users who have everything cloud-based, where this might take off.
I've seen a couple of them during my consulting gigs. They don't want to own any infrastructure and don't want to keep IT staff to maintain it. They indeed use G Suite, Office 365 and cloud varieties of line-of-business apps: order processing, inventory, accounting etc. If an app doesn't have a suitable cloud alternative, it's moved to VPS and accessed via RemoteApp (at this point you apparently get some IT guy).
They keep client PCs as "thin" (read "cheap") as possible. They don't have a "SWG" or "file/firewall policies" or anyone who can implement and enforce it. It's just stock desktop AV software perhaps with some initial tuning. And this resource-hungry beast is there only to scan incoming files for the ransomware-of-the-day, either downloaded from the Internet or copied from USB thumb drives. If they could deny users from downloading anything, disable thumb drives and drop AV entirely, they'd be much happier, especially that poor IT guy.
The risk you point out is extremely true. That's one reason why corporate/paid deployments are single-tenant. So everyone (not hundreds, it's more compartmentalized than that) on an instance belongs to the same company, or if desired, the same unit.
Even in this free demo, every user has their own browser process, with its own uid owner, and that OS uid has its own limited permissions.
At the same time, it's not an insignificant risk at all and you raise a very good point, which I'm surprised no one brought up before. Thank you for bringing it to everyone's attention.
An instance is a single point of failure, it's also less attack surface. To some extent, that's a tradeoff. Relative to all devices and network infrastructure in a typical company that access the public web, there's less attack surface if all web access funnels through a BG instance. On the other hand, it's a concentration of the risks into one place. My belief is that makes it easier to manage, and that the "gap" between the client infrastructure and devices and the cloud (through which only pixels, and a wire protocol of user intent pass), makes it more secure than accessing the public web directly.
Even tho it's a single point of attack, a compromise of a cloud machine, is not the same as a compromise of a device in a company intranet, or a mobile phone of someone in the company. In order to exploit the user's local machine or their organization's network, an attacker would still need to convert any instance access they had into access of a company device or network. This could happen through attack vectors in the pixels for the screen view (less likely) or through compromising the source code that serves the thin client (more likely). This is why monitoring of source code integrity is important. Open Source is an important part of that.
At the same time, in these free demo versions the browsers only exist for 10 minutes, and, exactly as you say, hundreds of strangers are all browsing from the same machine together.
TL;DR - It's a tradeoff of centralized infrastructure. There's less attack surface, but there's also a single point of failure.
Also, if you want to responsibly dislcose any security vulnerabilities you discover, please report to cris@dosycorp.com and if you want I can acknowledge you here https://github.com/dosycorp/vulnerability-reports
Good point, let me temporarily switch the default search provider to DuckDuckGo. This will take a while to propagate to the browsers.
A workaround in the meantime is to enter a URL in the box instead.
Edit: Switched to DDG as default search provider for this. Back up at 21:24 PST.
Edit @23:00 PST: I've opened an issue with Google Cloud Support (the system is hosted on GCP even tho it is cloud-agnostic) and I don't expect they will be able to provide a resolution because this is probably the CAPTCHA behaving correctly.
BTW, it could be the AI team getting some more data, who knows? ;)
Somehow tho I think whatever we do is simply a drop in a bucket for them.
Surprisingly usable, considering it's on the other side of the globe. Personally I don't see myself having a use for it, but I'm sure it could find its users.
Two thing I noticed. You have to enter address including "http(s)" to avoid searching it in DDG. And more annoyingly I couldn't select text on web page.
Just tried the demo on your website and it seems to be quite slow and unresponsive. If this a load issue?
Also it gives me a feeling that I'm not in control of what's happening on the screen. Could you please let me know how is this solution better (or more secure) than using remote desktop with disposable VMs?
I'm sorry about that! That's sounds like a really terrible experience you had trying this out today. It must feel really uncomfortable to not be in control of what's happening on screen.
There's a couple of factors that could be playing into this. Primarily it's likely just the application itself. It is more slow, and less responsive than using a regular browser on your device.
The frame-rate is capped very low, the image quality is lower, and there's more lag to each interaction since it involves (at the very least) a WebSocket round trip and a screenshot.
Secondly, you could be affected by geography, which has a very significant effect. If you are close to the primary server (US East, Virginia) you'll have a faster more responsive experience.
In a few minutes I'll have the HK server (Asia Pacific) back up ( I was just resizing it down, it was seeing significantly less use than the US server), and if you're closer to that you can try there.
Also, the free demo has many caps (so as to control costs). I cap the outgoing bandwidth of each user to a very low 3Mbit/s, and I use multiple ways to cap CPU usage, including (in extreme cases) killing the process. All of this means that if the page you are using wants to eat a lot of CPU (happens sometimes) then the app will slow right down for you (to preserve resources for everyone else on the system).
I can say confidently that it is not about the number of users. We had More 100s at peak before and a single browser still felt snappy. So if you're getting slow down I think it is (to summarise), either:
- You are experiencing the app for the first time, it is different to using a normal browser, interactions are slower and more choppy (but page loads should be as fast or faster).
- The page you are browsing is hitting the resource monitoring and being downregulated.
- You are link-wise far from the server (which is often, but not always, related to geography).
If you're interested to give it another try I'm at another time I'm happy to arrange that. Would you be unwilling to leave your email at this form, and I can let you know a quieter time? Also, if you just email me at cris@dosycorp.com and let me know your approximate location, I can set up a server near you and we can attempt to work out any leg issues still occurring.
Hey HN, thanks for all the love on this, and for helping me think about other use cases for and how to communicate about this product. I really appreciate this!
Also, I noticed I spent a lot of time maintaining the demo instances (resizing). In a real deployment the number of users per machine is pretty much static, but here I've had to deal with scaling and spikes.
It occurred to me today that I could probably put the free demos behind a load balancer (smaller basic machines, and scale them up or down), so that I don't have to manually resize the instance.
I've taken down the two demo sites (free & hk) for now, while I work on the load balancer setup. Should be back up in a couple hours.
I have not worked out how to geographically load balance both of those from a single domain based on which you are closest too, but I want to see if these new smaller instances in load balanced target group pools can scale to take the load like a larger instance.
The load balancing setup I used today has issues, which you can see if you're using it now (very slow).
Namely, load balancing and scaling based on CPU is not a good metric, because new instances (which are still serving multiple users), will keep absorbing new users before the metric is triggered, and even when it is triggered, a new instance will take a while to spin up and build some browsers, so scaling lags too far behind load and the effect is existing instances get and stay overloaded.
So, I have an idea for a new autoscaling system that puts 1 tiny machine per user, but it will take some reconfiguring. So, in the meantime, I'm switching back to the old system (massive instances, vertical scale).
I'll do that now and the servers should switch to the new system in about 30 mins.
Just had a quick check, some web page will fail the click event(mouse click won't do anything).
on the other hand I have been using novnc to do similar things for my own testing purposes(running chrome inside chrome remotely), it worked very well for me so far.
Thanks for the report, it's very valuable and thanks for pointing me to noVNC, it looks great!
I'm very serious about usability issues, would it be impossible for you to provide some examples of sites where the click failed and what you clicked on?
I try to get those things fixed ASAP because the experience of using is so important, I think it should be as familiar to a regular browser as possible.
Bleak future flashed in front of my eyes - Google Chrome v100 - browser runs on google's cloud, you are just being streamed view to your Chrome Client™. So secure and you are so out of control.
For better or worse, I think the economics of it mean this is what will happen in future.
As it gets possible to build very large and powerful computers more cheaply, they'll still be expensive and only the biggest corps will deploy them. And the experience deliverable from virtualized apps in those clouds will be vastly better than anything that can be run on a device. Considering the impact and requirements of AI only makes this more likely.
So after briefly becoming all about "edge computing" and "fat clients" in the recent past, I think the future is going to see a swing back toward massive centralization. This will also only be compounded by the next advances in wafer process and quantum, and the increases in bandwidth to allow richer experiences over 5G.
Our pocket devices might be "supercomputers" but the real supercomputers are still going to be in the cloud and capable, I think, of running everything.
TL;DR - the next big advance in computing tech will disproportionately allocate towards the cloud rather than the device, is my bet. And we'll all have "dumb" terminals streaming us VR/AR + AI experiences all the time.
Disclaimer: that future is not why I made this, I still think it is some time off and it just seems obvious this will happen. Rather than becoming all about "more powerful devices, less powerful servers", I think the future will be the other way round. :)
I don't doubt it for a second, but if you can make one happen why _not_ the other? if you already have a very powerful video compressor with low latency, why not do hosted applications?
Totally makes sense because you unconstrain yourself from supporting all web-browsers, rolling out features gradually, and it unconstrains you from javascript too.
Imagine instead of google docs you had microsoft excel but surrounded by a browser window, everything else is the same. I know people would pay for that. (even if I personally prefer google docs)
As I understand it, it's like an extreme sandbox -- a completely separate computer (or a VM) where all the web stuff happens (javascript etc), which just ships pixels to your computer (phone/laptop etc). Ideally the complexity of the client software is low, i.e. not a web browser, and there is strict site isolation (VMs) at the sandbox side to prevent leakage from one site to another. I'm a little vague as to how this implementation works.
So this is nothing to do with a VPN as such, but of course you could host it in the cloud, or run a VPN to a cloud endpoint.
What I used to do was launch a browser in an Xvnc or RDP session in a VM somewhere. Then do all my browsing from there. Later, I worked somewhere where RDP was blocked so I started using Guacamole (RDP/VNC over websocket).
What this author is providing is a similar and all-in-one npm solution for the above. Also has use-cases outside of secure runtime environments...
Hey Cris! I saw your email in another thread and I was gonna reach out but for different reasons! My background is software dev with an emphasis on systems infrastructure and release management. I’ve worked enterprise and startups and my niche right now is M&A transitions. Look out for my email later today!
Perhaps I'm off target, but how would this compare to guacamole? We've looked at guacamole as a potential solution to our problem. We need our user to log into a third party system with their username) password. Then we want to take over and drive the session selenium-style.
Sounds like you want someone to log in to a remote system then take over and drive it selenium style. Is that right?
Well, I'm hearing you right, then this (BG) is definitely a potential solution for your problem. I think it would be lighter weight than Guac since it only runs a browser (not a whole desktop).
My email is cris@dosycorp.com ... Would you be unwilling to talk more?
I have a few questions.
Does it update the whole screen each time something is changed on the page?
How have you got rid of Google captcha? I didn't get any while I was using it.
Yes, it listens for LayerTree.layerPainted events, and queues a screenshot on that. It also queues screenshots on other things, such as on "clicks", "scrolls" and a few other interactions.
After Screenshots are queued, they're throttled to a low framerate, and then each frame is compared with the last sent, before it is sent to the client, and dropped if there's no change.
I got rid of CAPTCHA by changing the search provider to DDG.
Thank you for your comments, I really appreciate it! :)
Not flash, but PDF and DOCX/XLSX should work okay.
I have not thought about Flash, but I totally get the point you make. It looks like it would be very useful as they are big attack vectors and usually not supported on mobile.
> This makes little sense, it doesn't protect you from exploits, they just run on the cloud instead.
I am in no way endorsing this product (or the category of products), but it is incorrect to say that it doesn't protect you from exploits.
It protects against your machine being compromised, and while the browser VM can be compromised, it can theoretically be ephemeral, possibly even only having the lifetime of a single tab (some products in the space does this IIRC).
It's all just a matter of what your threat model is.
> If this is something you really want for some reason, why not just RDP/VNC/Chrome Remote Desktop back to your office/home network.
You could make a minimal linux VM with only a web browser, keep good discipline and never do anything else on it, and RDP into it.
However, these products commonly provide much smaller attack surface than such a setup, and combined with something like VM-based tab isolation, you wouldn't be anywhere near the security features of such a product.
Perfect prevention of breaches isn't possible, you must assume compromise. Therefore part of your strategy must be the isolation and containment of an attacker's ability to do damage.
For concerns regarding what you say, it's true. The worst case is a browser zero day that escapes the browser, enables privilege escalation, and goes on to compromise the entire client instance and lurks in the server catching everything. That's definitely a possibility on the free demo.
However, for real deployments there are several layers of mitigation. On the most drastic end, we run each browser and server pair inside its own docker container. In that case, the exploit must, first escape the browser -> escape the Docker container -> gain code execution -> gain privilege escalation -> compromise whole instance.
I would never say it's "impossible" but I would say that we have brought effective defenses against that.
Another layer of mitigation is that each browser is totally scrubbed each time it is used. This is a tradeoff as we lose all session cookies and cache data, but we can do this, if required. You can even scrub it yourself while using it (right click/top hold to get the context menu, and select "Wipe everything".
A further layer of mitigation is we completely reprovision / scrub the entire server every hour / day / week.
I think you are getting the idea.
By separating the client's devices and network from DMZ where "web work" occurs, and containing the attacks within this "air gapped" satellite, we greatly limit the attacker's scope to cause harm, plus we greatly increase our ability to deliver mitigation at any scale and schedule we choose.
Another advantage of this is, you don't need to download anything, RDP/VNC requires some extra app or setup, this is just connect to a web site and you're good to go.
You can self host to manage trust. Organizations typically want to partner with a provider even if they do self-host or go hybrid, because they don't want to manage everything themselves.
Hey, this is super cool and interesting! Are you using puppeteer to do this? Might be cool to partner on some of it if you’re looking into that (I run browserless.io).
I don't use puppeteer. I use Chrome DevTools Protocol heavily tho. I started using chrome-remote-interface but hit limits in what it can do with Targets (specifically, flat session mode) and the latest versions of the API. Now I just use the WebSocket directly.
Thinking back to when I started this I initially just wanted to keep everything simple and so I avoided putting in a large and high-level lib like pptr, and went with chrome-remote-interface.
I looked at pptr and IIRC at that time (~ 12 months ago) there was not a clear way for me to handle multiple tabs (a key "real UI" use case). The same goes for Cyrus' lib too.
With Cryus' lower level lib I could hack around that, by doing my own target and session management, but at some point in the last couple months I hit a wall with chrome-remote-interface. Cyrus' lib was not up to date with the latest ToT API (specifically flat session mode) and I worked out I could replace the entirety of chrome-remote-interface with some simple code that sent messages down a WebSocket, saved a Promise (by message id) and returned it, and resolved that promise when it received back a message tagged by corresponding id. It was also simple to write an 'on' function to add listeners for various events. So that was that.
Basically, the DevTools protocol is a well specced, well tested, simple protocol and all these libs (like pptr and chrome-remote-interface) began simply as wrappers around the WebSocket, with an API to map function calls to protocol messages and add listeners for events. PPTR has evolved into much more than that now, and during the same time period, I evolved my own "BG protocol" atop the CDTP (Chrome DevTools Protocol). It became easier to deal with the single source of truth that CDTP is, and get the full expressibility of the latest ToT protocol than deal with the limitations and abstractions of other things built atop that.
Specifically, PPTR did not (and I believe probably still does not, tho I have not deeply checked) an easy way to control and manage multiple tabs. And even if it does, I'd have no use for it, because I already have the code that does all that anyway. Scanning PPTR docs now I see that I prefer the abstractions, naming, etc of the CDTP protocol itself, rather than the ones PPTR provides. Like I said, the CDTP protocol is very comprehensive, consistent and makes a lot of sense, and I know it very well. For me and my use case, it's just a better fit.
The way I think about this is not that "PPTR" has some problem, it's that the "BG protocol" and PPTR (et al) are trying to solve (basically) fundamentally different problems. PPTR (et al) try to provide a clean developer experience for common tasks related to browser use cases (such as automation, getting screenshots, PDFs, testing, etc). That's a particular domain, and not exactly the same as what BG protocol does. BG protocol attempts to provide as realistic and familiar as possible experience of using a browser (when you're actually controlling a remote browser through the CDTP). That's not entirely the same domain, because some things that users want, are not required in automation, and some things that automation does are not required or done by users.
One of the ways I code is by picking the right tool for the job, and if that tool doesn't exist, or no longer works, I build the tool. I want to work with tools that fit right. So for this domain and use case BG protocol is a better fit than PPTR.
pptr and BG both use Chrome DevTools to communicate with the browser, so there's that commonality.
I haven't looked extensively at the pptr source but I imagine both pptr and BG do some bookkeeping of state related to the sequence of commands (BG certainly does), rather than a purely "stateless" command queue.
For instance, for some things you need to keep track of which session is associated with which target. For other command sequences (such as Runtime.evaluate) you need to know which execution context to evaluate in. And you can keep track of open execution contexts by tracking various Runtime domain events (such as executionContextCreated, executionContextDestroyed, etc).
So to provide a sophisticated level of interaction with the page, some amount of chattiness and state is required for the protocol on top of the DevTools wire protocol.
What I'm getting at is, if there are hurdles, they will likely emerge from the different ways in which pptr and BG handle state and that chattiness to achieve particular user intents.
Also, BG does not require pptr to do automation. It's possible to simply record and replay (again with a further layer of book-keeping that's too involved to get into here), the BG command sequence (which itself is a superset of the DevTools protocol).
All the same, I've often thought about providing a functionality to "export to puppeteer" (or to nightmare, or to phantomjs, etc) in terms of getting a transcript in a widely used format that people can take and run anywhere. That's one thing that excites me about pptr X BG.
In any case, automation is not something that is currently provided in the CE, but it's in the paid version at https://browsergap.xyz
If you mean running the VM locally, then that has a risk of any exploits being able to escape the VM, and attack your machine directly.
That seems less secure than facing the risk of any exploits being able to escape the hypervisor in the cloud, someohow come through the text protocol connection to your computer, and exploit you there.
The extra layer of security provided by the remote cloud is important.
If, on the other hand, you mean using Guacamole to connect to a desktop running headless in the cloud, I'd say that's a similar level of security to BrowserGap.
For screen readers you could run it server side. Then stream audio/video to the client.
Although I dont think this is the best sution to the problem. A better solution would be to run the browser with a hardware abstraction layer, like a virtual machine.
Wow, that is far! It might have been the 10 minute time limit I put on the free version. It used to be 30 minutes but today there were hundreds of people and many people getting told it was already full, so I tried to let everyone have a go.
But, haha, I'm really glad that little modal dialog bubbled up the layers! XD It's kind of crazy when you think about what's happening ~~ you're chaining 7 browsers in row, using each to automate the next. It's crazy! Haha! XD
You really got me with this, it's so funny! Thanks for giving me a huge smile.
It's just pixels out. It's very basic. It's just screenshots and compressed with WebP (if client supports), and adjacent frames are dropped if they are the same.
How is the user agent set? I'm trying out the free demo (free.cloudbrowser.xyz), and two different browsers (Chrome and Firefox) produce different and consistent user agents.
Could that cause any issues with browser-specific features? I'm not sure what browser/renderer you are actually using, but if I'm using something different, there could be a mismatch in advertised capabilities (through the user agent).
Thanks a lot for your time on this report, and I'm really sorry about that! It sounds like the screen is pixelated and unusable. That must be very annoying!
I don't have an iPhone next to me right now, and I have not tested in Safari for about a week. Would you mind sharing a screenshot?
I know that because iOS Safari does not support WebP, I'm just using JPEGs which means the quality is worse there.
As a short term workaround, I'll now turn up the JPEG quality. This will take some time to propagate to browsers.
Again, I'm very sorry you had this experience today! I will test on iOS and improve the usability. I've had other reports that scrolling is terrible in iOS.
I'm just adding the iOS issues to the GitHub repo now. It could be great to contribute your screenshot to there! :)
Someone else already mentioned being hit by Google captchas and the developer of this service said that he switched to DDG as the default search provider. Nevertheless I tried Google and kept working through 15 (yes, fifteen) captchas in a row and Google still wouldn't let me through, and then I gave up. What the hell? Surely even after 1 captcha, Google should be amply convinced that I'm not a robot and let me did a single search.
Can anyone explain the purpose of Google putting up an apparently impossible barrier like that? Is it because my searches are comingled with dozens of other people attempting Google searches at the same time from the same IP address? Or Google decided to blacklist his IP address?
That is a "feature" of ReCAPTCHA, and I believe there might even be a patent on it. The idea is that if you are sure it's a bot and want to deny them access you still waste their resources by making them solve impossible captchas.
As a non-chrome user things have been getting a lot worse lately. I've also noticed more and more pages using recaptcha even there's no clear way for bots to spam content.
Are people really that eager to send google all traffic information? Is this really the best solution? Couldn't one for example parse the actual content that the bots are trying to create and filter/ban them based on that? I believe spam detection is quite effective these days.
This whole captcha hell is making web really annoying for normal users and mostly just benefits google.
Thats really good feedback, thank you for your time on this.
Also, that's terrible! I'm so sorry for you that you had that experience today. You must feel pretty angry to sit through 15 CAPTCHAs!
I have to solve the CAPTCHA problem. I'm sorry I can't explain why this happens or how the CAPTCHA system works. I don't know anything about it.
I'm OKAY with the occasional CAPTCHA, but I'm not satisfied that people are getting hit like this.
I've been told that VPNs have a solution to this (since they need to deal with their clients getting faced with CAPTCHAs as well) but I'm sorry I have not reached out to any VPNs yet about this because, last time this problem occurred[0], after an hour or two I checked and it stopped happening, and there were no more CAPTCHAs. So last time I did not have to change the default search provider to DDG.
I'll send an email to NordVPN now and ask them if they have any idea what I can do.
Google detected you were not running Google Chrome (with which they can easily profile you) so you end up being punished for that. Which leads to Google Chrome being the preferred product. They made up some punishment system and reason to cover that up.
Just kiddin'. Sometimes, I end up having to do unreasonably more captchas. The reason is that the system verified I am human, and it wants me to cooperate with it for free in order to authenticate more captchas. Machine learning, they call it. I call it un(der)paid labour. Never had 15 in a row though, so I suppose the already mentioned reason is more plausible.
Not just for remote browsers, but even any browser other than Google Chrome it triggers a lot of captchas and even renders a lot of sites hosted behind Cloudflare unusable - which is a lot.
Just try doing a reverse phone number search on truecaller.com. It will work flawlessly on Chrome but use FF or any other browser and recaptcha will fail you saying you're a bot (at least happens to me evey time I've tried). Same for many other sites where you see that "Checking your browser" page.
So even though I want to use FF I can't since most of the web is unusable because of this stupid Recaptcha unlesw you're using Google Chrome :(
>Nevertheless I tried Google and kept working through 15 (yes, fifteen) captchas in a row and Google still wouldn't let me through, and then I gave up. What the hell? Surely even after 1 captcha, Google should be amply convinced that I'm not a robot and let me did a single search.
Google probably identified you as computator prior to the capcha but that profile had no value for seemingly impossibly.
>Can anyone explain the purpose of Google putting up an apparently impossible barrier like that?
Your video will play automatically (after these fourteen short messages from our sponsors)
Why am I open sourcing this?
I don't see any other RBI / CBII vendor open sourcing their platform and in the security industry "closed source" can create issues.
But what about business defensibility?
I agree. Open sourcing removes the trade secret aspect that could make a defensible business.
At the same time, a determined hacker would already have my source code. A hacked "free wifi" connection here, a bit of social engineering there, and my so-called "competitive advantage" could be easily removed. Access to GitHub, Gitlab, other accounts would prove no obstacle for someone motivated, and open sourcing is a way to remove the advantage any small group of parties has by keeping it secret.
How do I self-host it?
There's instructions on the repository page.