4 ms·

Found a short blurb of theirs: "BrowserBox powers multiple use-cases, including: in-app browsing, co-browsing, remote isolated browsing, easy 3rd-party embeddi

by tux1968 3y ago

Found a short blurb of theirs: "BrowserBox powers multiple use-cases, including: in-app browsing, co-browsing, remote isolated browsing, easy 3rd-party embedding, and human-in-the-loop robotic RPA monitoring and interaction." Essentially, it is remote desktop for the browser, converting rendered pages into images that are transmitted to the client instead of html. The demo shows interacting with Youtube and watching a video.

keepamovin 3y ago
Thanks! Definitely the README could be more clear. It's a product that sits at the nexus of a few different things. Just briefly some companies that are doing somewhat similar things (I may have missed some, there are a lot!): - Cloudflare (from S2): https://www.cloudflare.com/products/zero-trust/browser-isolation/ https://www.cloudflare.com/products/zero-trust/browser-isola... - RemoteHQ: https://www.remotehq.com/ https://www.remotehq.com/ - HyperBeam: https://hyperbeam.com/ https://hyperbeam.com/ - Ericom: https://www.ericom.com/ericom-isolation/ https://www.ericom.com/ericom-isolation/ - Symantec/Broadcom (from FireGlass): https://www.broadcom.com/products/cybersecurity/network/network-protection/web-isolation https://www.broadcom.com/products/cybersecurity/network/netw... Cybersecurity uses: - defensive cybersecurity: remote browser isolation is another layer to protect against browser zero-days from compromising your devices and network. So called "zero trust" approach of assuming compromise. - email attachment and link opening: people can open email attachments in the secure document viewer and open dodgy looking links without risking their local workstation - pentesting and malware analysis: researchers can investigate potential malware from a distance Process integration and automation: - you can embed browsers in your website in a way that circumvents iframe restrictions. This can make it easier to build dashboards and integration portals. - you can use BrowserBox Pro to attach to your running Puppeteer / Playwright or other Chrome instances and interact with them in real time. People find it useful for debugging automation issues and getting them unstuck from bot-tests and errors. It's like driving manual for a challenging stretch on your FSD! Remote work: - co-browsing as a way to collaborate: you can have multiple people interacting with a web site in real time. Userful for remote teams who need to debug an issue or discuss content and design - co-browsing as a way to socialize: some people enjoy doing watch parties and syncing up their viewing with friends - co-browsing as a way to educate: trainers use it to deliver interactive lessons and as a way to monitor and aid development skills in apps VPN and remote desktop: - people use it as a way to circumvent country specific blocking by spinning up a VM in another zone and accessing the content they want from there - people use it to access web-based apps, which in some areas have largely replaced desktop apps. It's like a lighter weight remote desktop in that case. Random and miscellaneous use cases: - honestly we're quite surprised at the way people use it sometimes. One of the first customers wanted it as a way to manage multiple online personas for their own privacy. Somehow they preferred that to having multiple local browser profiles. Currently I wouldn't say it's particularly optimized for any of these subsets. But it's a great starting point for people building any of these applications. While we have a rough idea, as shown above, now we're in the process of asking people exactly how they use it and deciding if we should narrow our focus to a particular customer set, or keep it broad, and build out multiple feature domains in parallel.
- marban 3y ago
  So you could also build a low-fi BrowserStack or Lambdatest with this?
  - keepamovin 3y ago
    Hopefully so. Those products support a lot of combinations that we don't tho. We're basically just chrome. Theoretically you could port the protocol to Playwright, but it'd be rough. Don't do it.
    - MrMarkItDown 3y ago
      You listed a ton of use-cases, what's the most prominent one in your opinion?
      - keepamovin 3y ago
        Our customer base is split: - 50% cyberdefense (web isolation) - 40% automation/process integration - 10% miscellaneous other. In the last category the most prominent is circumventing local internet restrictions. You didn't really ask about the following, but I think it's interesting: at least that's what our customers tell us their use is. As we haven't (yet) launched hosted service, and currently don't track usage analytics, we don't actually know for certain if these uses are legit, but they seems so. That's paying customers. I estimate around 250% more people are using it "black", so either ripped off the source code before we went open source (there were a few hacks that seemed like they might have been breaches that could have accessed source code), or just using it unlicensed right now. I'm not sure what those folks use it for either. We get hundreds of git clones every day~~we probably should be tracking that, but we don't have a good idea how to do it without borking the privacy expectations people have! We've had reach outs from places that we can't easily do business with as well (like Iran). I don't understand the cloak-and-dagger interest (besides the fact that we may be the only source-available product out there (although there's Neko, and other similar things with different targets, so shrug)), maybe it's just corporate espionage, rather than hacking to use. It seems more likely that an orthogonal technology (using chrome headless, rather than RDP, DOM mirroring, or some custom browser engine), like we do, would be more attractive to a competitor than to a customer, as if you really need a similar solution and don't care about the finer points, you can just set up RDP pretty easily. That's one of the things that convinced me to go open-source, because it limits the asymmetric advantage that anyone who hacked us for source code may have had. But I also figured we were halfway there with a limited-feature product, so may as well go all in. It's too early to say if it's the right choice or not! :)

keepamovin 3y ago

Thanks! Definitely the README could be more clear. It's a product that sits at the nexus of a few different things. Just briefly some companies that are doing somewhat similar things (I may have missed some, there are a lot!): - Cloudflare (from S2): https://www.cloudflare.com/products/zero-trust/browser-isolation/ https://www.cloudflare.com/products/zero-trust/browser-isola... - RemoteHQ: https://www.remotehq.com/ https://www.remotehq.com/ - HyperBeam: https://hyperbeam.com/ https://hyperbeam.com/ - Ericom: https://www.ericom.com/ericom-isolation/ https://www.ericom.com/ericom-isolation/ - Symantec/Broadcom (from FireGlass): https://www.broadcom.com/products/cybersecurity/network/network-protection/web-isolation https://www.broadcom.com/products/cybersecurity/network/netw... Cybersecurity uses: - defensive cybersecurity: remote browser isolation is another layer to protect against browser zero-days from compromising your devices and network. So called "zero trust" approach of assuming compromise. - email attachment and link opening: people can open email attachments in the secure document viewer and open dodgy looking links without risking their local workstation - pentesting and malware analysis: researchers can investigate potential malware from a distance Process integration and automation: - you can embed browsers in your website in a way that circumvents iframe restrictions. This can make it easier to build dashboards and integration portals. - you can use BrowserBox Pro to attach to your running Puppeteer / Playwright or other Chrome instances and interact with them in real time. People find it useful for debugging automation issues and getting them unstuck from bot-tests and errors. It's like driving manual for a challenging stretch on your FSD! Remote work: - co-browsing as a way to collaborate: you can have multiple people interacting with a web site in real time. Userful for remote teams who need to debug an issue or discuss content and design - co-browsing as a way to socialize: some people enjoy doing watch parties and syncing up their viewing with friends - co-browsing as a way to educate: trainers use it to deliver interactive lessons and as a way to monitor and aid development skills in apps VPN and remote desktop: - people use it as a way to circumvent country specific blocking by spinning up a VM in another zone and accessing the content they want from there - people use it to access web-based apps, which in some areas have largely replaced desktop apps. It's like a lighter weight remote desktop in that case. Random and miscellaneous use cases: - honestly we're quite surprised at the way people use it sometimes. One of the first customers wanted it as a way to manage multiple online personas for their own privacy. Somehow they preferred that to having multiple local browser profiles. Currently I wouldn't say it's particularly optimized for any of these subsets. But it's a great starting point for people building any of these applications. While we have a rough idea, as shown above, now we're in the process of asking people exactly how they use it and deciding if we should narrow our focus to a particular customer set, or keep it broad, and build out multiple feature domains in parallel.

marban 3y ago
So you could also build a low-fi BrowserStack or Lambdatest with this?
- keepamovin 3y ago
  Hopefully so. Those products support a lot of combinations that we don't tho. We're basically just chrome. Theoretically you could port the protocol to Playwright, but it'd be rough. Don't do it.
  - MrMarkItDown 3y ago
    You listed a ton of use-cases, what's the most prominent one in your opinion?
    - keepamovin 3y ago
      Our customer base is split: - 50% cyberdefense (web isolation) - 40% automation/process integration - 10% miscellaneous other. In the last category the most prominent is circumventing local internet restrictions. You didn't really ask about the following, but I think it's interesting: at least that's what our customers tell us their use is. As we haven't (yet) launched hosted service, and currently don't track usage analytics, we don't actually know for certain if these uses are legit, but they seems so. That's paying customers. I estimate around 250% more people are using it "black", so either ripped off the source code before we went open source (there were a few hacks that seemed like they might have been breaches that could have accessed source code), or just using it unlicensed right now. I'm not sure what those folks use it for either. We get hundreds of git clones every day~~we probably should be tracking that, but we don't have a good idea how to do it without borking the privacy expectations people have! We've had reach outs from places that we can't easily do business with as well (like Iran). I don't understand the cloak-and-dagger interest (besides the fact that we may be the only source-available product out there (although there's Neko, and other similar things with different targets, so shrug)), maybe it's just corporate espionage, rather than hacking to use. It seems more likely that an orthogonal technology (using chrome headless, rather than RDP, DOM mirroring, or some custom browser engine), like we do, would be more attractive to a competitor than to a customer, as if you really need a similar solution and don't care about the finer points, you can just set up RDP pretty easily. That's one of the things that convinced me to go open-source, because it limits the asymmetric advantage that anyone who hacked us for source code may have had. But I also figured we were halfway there with a limited-feature product, so may as well go all in. It's too early to say if it's the right choice or not! :)