The README lists CloudFlare remote browsers as a similar tool, so I did a price comparison. BrowserBox looks like the more expensive option. I'm seeing $1,000 per seat with a minimum of 50 seats as the lowest tier (for commercial use) [1]. CloudFlare remote browsers is a $10/user/month add-on [2]. BB has a perpetual license, so it becomes the cheaper option if you've got >=50 users for >8 years. You'll also need to self-host BrowserBox, so there's additional cost and complexity to consider.
I think a feature comparison would help show why someone should pay that premium. What does BrowserBox have that the others are missing?
Edit: Clicking "Purchase" shows that the pricing is actually $50,000 for a pack of 50 seats, so 51 users would need 100 seats at $100,000. That's misleading.
I was thinking about this SaaS price: 10/seat/month.
I mean honestly we could run SaaS instances of Pro for a fraction of this cost, with 24/7 availability, and even less if you "amortize" it over a pool that supplies an instance on-demand.
Cloudflare’s S2 browser isolation tech should get a solid nod here. S2 was a Seattle startup that figured out how to stream the DOM from a remote headless browser to the client, delivering a very smooth experience that is far superior to RDP or VNC. One of their smartest acquisitions IMHO.
Is there an open-source/self-hosted alternative or something that's friendly to extended families, small/tiny businesses etc.?
I see so many use-cases for browser isolation but haven't found a well-working option that doesn't need a full-time admin to set it up, isn't call-for-pricing or doesn't have streaming quality issues.
I did look at Browserbox some time ago and found it very promising, but alas the quality/performance (compression) was too subpar for non-tech users, even when run locally on the same machine.
Yeah that's an issue, I grant you that. I'm open to Pro for extended families (Personal Pro), or tiny business, but I don't have any concrete pricing/terms in mind. Want to email us to tell us what you want, and we can see if it's something we can do? support@dosycorp.com
I am reminded also of Opera Mini back in the day. It did not stream the DOM, but they were rendering pages on their servers and then using fancy compression techniques to deliver the rendered page to your mobile phone. This was a godsend back in the bad old days of slow mobile phone internet.
I am talking about the Java ME application. Not the more recent browsers they’ve made.
> It was primarily designed for the Java ME platform, as a low-end sibling for Opera Mobile
> […]
> The functionality of the Mini mode is somewhat different from a conventional Web browser, with the amount of data which has to be transferred much reduced, but with some loss to functionality. Unlike straightforward web browsers, Opera Mini fetches all content through a proxy server, renders it using the Presto layout engine, and reformats web pages into a format more suitable for small screens. A page is compressed, then delivered to the phone in a markup language called Opera Binary Markup Language (OBML), which Opera Mini can interpret. According to Opera Software, the data compression makes transfer time about two to three times faster, and the pre-processing improves the display of web pages not designed for small screens.
Interestingly I found that someone has written a script to convert OBML to HTML. Their intended use-case for the script is to make pages saved with Opera Mini viewable in other browsers. But to me the main interest is that I would like some day to make something similar to Opera Mini on my own, and the README of the conversion script has some technical details about OBML.
> because OBML files are the output of Opera's HTML rendering engine, many elements are pixel-positioned according to the original device's screen size and font metrics. Because many J2ME devices had custom fonts (optimized for low-res screens), it's possible that your computer will show the same text as too-tall or too-wide, and lines may overlap.
> […]
> OBML does not have <a href=...>, i.e. you cannot actually have text that is also a link. Instead the engine outputs text and links as two separate layers – first it places the actual text at position (X,Y), then overlays it with "link" rectangles at position (X,Y,W,H).
> […]
> OBML does not have styled widgets the way HTML would. The style is actually pre-rendered, and those pretty 3D effects are made out of pixel-positioned lines and rectangles. Even button gradients are pre-rendered and drawn as a series of 1-pixel thin lines.
Opera Mini was absolutely amazing. I remember being able to browse the web for a whole month on a 30 or so MB data cap and never even getting close to exceeding it. It also supported an unbelievable number of devices, some of them barely capable of properly running any J2ME application, let alone a web browser.
> [...] I would like some day to make something similar to Opera Mini on my own [...]
That would be great! Unfortunately I think today's websites might make this even harder than when Opera Mini was popular, but the original could handle some amount of JavaScript server-side execution surprisingly well.
Also, your post just made me try Opera Mini again – unbelievably, it still seems to be working on my iPhone! The app does not look like it's available anymore, but there must have been an update recently enough to still allow it to run on my device without obvious UI stretching or Apple incompatibility/deprecation warnings.
> I am reminded also of Opera Mini back in the day.
I can definitely confirm that Opera Mini was one of the more usable browsers back in the day. I think I remember using it on a few S60 Symbian devices and when sites worked, they did so really well and you could open dozens of tabs with no problems. I actually miss those Nokia phones and computing back then, hah.
I used Opera Mini (not Opera Mobile) on a few Android devices as well, because the built in browser was too sluggish in comparison. I recall about 3 open pages causing issues on an Android 2.0 or 2.1 device, though that problem more or less persisted to some newer budget devices, too.
It is just with my newer devices that I've switched to Firefox on the mobile and find it largely sufficient nowadays (though now Chrome would also be okay).
You might get the same functionality running playwright with novnc on a remote server because that is all that this is, a remote headless browser, connected to a node server that communicates to the headless browser with the Chrome DevTools Protocol over a websocket, with a <canvas> element embedded in the clients browser which sends all captured events like mousemove and mousedown to the node server, and lastly renders a stream of images from the headless browser into the client browser inside the <canvas> element. [0]
Had to admit I came to the same conclusion when I read this part of the readme:
> The NC license permits "use by any charitable organization, educational institution, public research organization, public safety or health organization, environmental protection organization, or government institution is use for a permitted purpose regardless of the source of funding or obligations resulting from the funding."
But on reading the license, personal noncommercial use is fine too. It would have helped me if that info had been in the readme!
I have been following a company named Hyperbeam (mentioned in the link) and a few others that have browser in browser capabilities because here are use cases in XR where it comes in handy to access 2D web content without hitting a lot of CORS and other issues [1]. I will definitely add this to a watch list. Good luck with the project !
All I want to do with a browser that I can't do normally is disable CORS. Which genius decided that a webserver on localhost was infinitely more trustworthy than a file:// url?
You two have this entirely backwards. It’s the Same-Origin Policy that is stopping you from doing what you want. CORS is a way of loosening up the security to make more things possible. CORS doesn’t – and can’t – stop you from accessing anything. If you “disable CORS” in your browser, guess what? You’re going to be able to access less stuff.
This is needlessly pedantic, and you know it. The same-origin policy makes lots of things a real pain in the ass, and that there is no escape hatch for those times I know that there are some missing headers on my responses doesn’t make sense.
What OP obviously meant was a way to disable same origin policy checks.
It isn’t anything of the sort. If they think the problem is CORS, they are going to put all their effort into trying to figure out how to disable CORS. This will not help them in the slightest. What they want, in effect, is to have a configuration that is as if CORS is on all the time, which they would never think to do if they think it’s CORS stopping them from doing what they want.
> What OP obviously meant was a way to disable same origin policy checks.
Yes, and they showed absolutely no knowledge of the fact that the SOP even exists. They think it’s CORS doing it. Pointing out this is backwards and pointing out what is actually causing their problem is helpful, not pedantic.
Congratulations on figuring out what I meant by a simple one line frustrating comment I made while I was walking to the toilet where I couldn't be bothered to set up a 2 paragraph explanation of precisely what I was talking about.
Are you still referring to accessing a file:// resource? Wouldn’t it be enough to run “python -m http.server 8000” in the desired directory? This sounds simple and quick to me. Or am I missing something?
I ran into some of these concerns when working on a sandbox feature where users select their own files to use in an iframe.
Once in production, sometimes you want the user's browser to serve these local files to itself, from blobs and/or the local file system, meaning a server or CLI isn't feasible.
This should be better from a privacy standpoint since files stay completely client-side, but CORS difficulties end up encouraging developers to push files to the server at least temporarily instead.
> This should be better from a privacy standpoint since files stay completely client-side, but CORS difficulties…
Isn’t this privacy tradeoff directly at odds with security? i.e. local access would also open the door to malicious sites accessing the local file system?
I can understand the dev-time frustration with CORS, but removing it just reintroduces a whole category of security issues.
Maybe there is something better, but whatever replaces it would need to include similar restrictions.
>Isn’t this privacy tradeoff directly at odds with security? i.e. local access would also open the door to malicious sites accessing the local file system?
Look at docker for analogy. Sometimes you just need a volume to use locally, but you don't necessarily need to access files that already exist. Consider the use cases of /tmp/ as well, for instance.
This sounds unrelated to the use case described by the parent, in which they want to serve specific files that exist.
But setting that aside, bypassing CORS to achieve this seems analogous to unlocking your front door/gate before leaving for the day in order to grant access to a delivery driver.
It’ll work, and the driver can deliver your package, but it’ll also let random and potentially malicious passers-by into your home without restriction, so who knows if your home will be intact when you return. A theoretically functional solution that doesn’t really work in the real world.
Some other solution that behaves more like a temporary file store sounds better, but the tradeoff I mentioned is specifically about CORS.
In the case I was referring, we loaded files as blobs in the browser's local storage, allowing us to run a web worker as a persistent local cache server.
This involved managing Firefox's admirable response doctoring policies, though.
All other browsers would let a web worker modify the incoming response to a request before forwarding it to an iframe, but FF absolutely refused it and required that the modified response get constructed anew in its local context, meaning locally created or injected content could not be mistakenly trusted as origin content.
Not everyone has Python or any other web server installed and being able to just double-click an HTML file and access all the web features without any online or native component would unlock so many new use cases.
This is perfectly fine for trusted sites, and I've used it a lot in the past for a few, but it disables cors for everything, and that's a bit too much.
What I want is unrestricted access for my code, and that the sites keep the sandbox.
What I do nowadays is start a server that has basic auth and zero cors, that I can send commands to from my scripts, like, fetch me this resource without cors, or download this to this folder, etc.
This goes a lot farther than disabling CORS checking: it turns off all same origin policy enforcement.
So, ex, if site A opens a tab on site B (and so gets a reference to it), site A can read and modify anything on that page. Or, ads loaded in cross-origin items could read and modify anything on the containing page.
It's fine for testing, but don't log into any real accounts in this profile!
Even more ridiculous is the HSTS requirement for localhost, which inspired me to share the techniques in https://github.com/ip2k/I-Dont-Care-About-HSTS-For-Localhost for automating a bit of the frankly ridiculous and idiotic process required to work around this. Who the heck needs a REAL SSL cert for local web dev, and why is it so hard to permanently override that?!
You can disable this by running Chrome with —-disable-web-security. If you only need this to access local files, you can do —-allow-file-access-from-files
Even more ridiculous IMO is the requirement for a REAL AND VALID SSL CERT for localhost. I made https://github.com/ip2k/I-Dont-Care-About-HSTS-For-Localhost to share some of the frankly ridiculous techniques required to work around this in temporary and more permanent ways.
Forced HSTS, Certificate Transparency checking and limiting key features to "secure contexts" (including the way those are defined) were truly the worst decisions in recent web history...
A local webserver doesn't allow you to open every file on your file system, and there's no guarantee that a particular ip address is a local web server. If you really need it, run python -m http.server in /. That starts a local file server at port 8000.
It looks to be an implementation of "browser in a browser". Originally the project seemed to handle usually unsupported apps, like IMAP clients in the browser. I assume they have a server running, and JS libraries that act as a shim for IMAP et al control via websockets. Also appears to create usable web-based proxies for modern security-controlled websites which would break on legacy web-proxy methods.
Not obtuse at all! It’s actually not so easy to describe what this is and it took us a while to come up with correct language, and understanding of how to express it even after we knew what it was and had built it: it took us some time to figure out how to communicate that.
To answer you: I believe these instrumentation/automation protocols/methods like Selenium/W3C WebDriver Protocol/Remote Debugger Protocol, do not themselves provide user interfaces for controlling their functions, but rather expose APIs.
BrowserBox itself uses such a protocol under the hood, but also provides a user interface (that funnily enough looks like a regular browser~~because I wasn’t creative enough to invent a better set of UX interactions/affordances than those already expressed in regular web browser, heh :)).
In effect, BrowserBox turns the browser experience into a client server application. And BrowserBox is to those instrumentation/automation APIs, as a front end Client is to a Web application API.
That’s a slight simplification because BrowserBox contains a significant server component, however, it’s a useful way to think about it.
Great! I just started using it to access some sensitive accounts (Google/Facebook Ads Platform) on Azure instances. I travel a lot so always need to isolate my accounts in Cloud instances to not get banned (for having a high-risk profile due to the high number of IP adresses). I used to access my accounts through RDP but super slow, this is making it so much smoother
> high-risk profile due to the high number of IP adresses
Another solution might be to proxy your web traffic through a part of your controlled infrastructure. Also useful if the destination blocks requests unless the source is whitelisted. I use ssh port forwarding for this.
Since you've mentioned Facebook Ads Platform, I'm guessing you're using BrowserBox commercially. Did you have any thoughts on the pricing? A $50,000 license seems quite steep for a "faster RDP".
I mean...theoretically...if you could back-port the client to work on the old rendering engine this uses, sure. When I initially developed this in 2018, I was testing it on an iPhone 4!
So, at least for a time, it was able to run on very old tech.
Web scraping automations often get stuck on some thing like a captcha or the page has changed and BrowserBox Pro let you attach to that running chrome automation instance, see the actual page that it got stuck on, and inspect that in remote version of dev tools (even from mobile!). This could let you quickly investigate and diagnose the issue and come up with a fix, all live.
Can you clarify the license history? It looks like this is formerly Open Source, but now uses a commercial license. I'm not a lawyer, but anyone who prefers Open Source software may be able to fork the software at an earlier commit under the earlier terms.
Why so many license changes? Given the $1000 per seat license cost, I'm not sure this is a great look.
I’m not sure if they can, but i would prevent that if i could.
> … why license changes…
Ha, you may be right! I don’t know. I guess I was just duped about the other licenses and the types of protections they can offer. I wasn’t informed and, I don’t know, I guess I was just trying to figure out a business model.
Okay, I want to clarify something here: I didn't mean that I would prevent people from using the old versions. Seems some people think that.
I thought the guy meant "to use the old licenses on the new code." Reading it again, I see. So, what I actually mean is, "I'm not sure if they can use the old licenses on the new code. But, I would prevent that if I could." Which is totally valid and I would do that--I can do that.
It seems somehow the other meaning has created lots of crazy ideas for people, and they've gone on a tangent, which you can see in the sibling thread here. It's not my fault, but I see how I haven't probably made it clear enough there: I'm sorry for not making it clear.
Ultimately, I think having those licenses in the past is a silver lining for customers, especially because people can access this old code, and it's not affecting our revenue with Pro or people who want to pay for the standard edition somehow. Because this old code and old licenses do not sync to the latest, don't give access to Pro, and it gives people a chance to have a taste and build on that. It's really just another part of the funnel.
And, I think the whole variety of licenses there is sort of a silver lining. So, I don't know where people got the idea that we're against having that or something like this. It's not like that. So, just understand.
Not really--because we're not worried about old commits usage; providing a sample fosters innovation in this emerging market. The vast differences between old code, and our Regular and Pro versions means it doesn't impact Pro revenue. Initially releasing under open-source licenses was positive, and we later transitioned to controlled licensing as the product became popular and evolved, enhancing our business model.
With the piracy comment I see where you went wrong: https://news.ycombinator.com/item?id=35501855
You think I'm saying that people using old code with old licenses is piracy.
What I'm really saying is that there's always piracy... so who cares about old code, old licenses and people using it? Doesn't matter.
\__
But with your "dishonest ... pretending never oss" comment, I don't see how you got that wrong.
I mean, you're the one who's being dishonest and pretending there, it looks like:
The licenses are present in the commit history! I'm not being dishonest about, or hiding, or pretending about anything.
And I even confirm it above: https://news.ycombinator.com/item?id=35499733
> … formerly OSS …
Mm, that’s correct.
So I don't know where you went wrong there, and I don't know where people have got these crazy ideas from, but it's not my problem. So please don't blame it on me! OK?
No, but I have learned a bit about software licensing to be able to meaningfully engage in making run of Minio, so this is real info.
Specifically, most open licenses have a clause like this:
(from GPL3) ...and are irrevocable provided the stated conditions are met ...
Which is the bit that means you can't decide after the fact that at this point in time the software was not licensed under GPL3, this is to protect from I guess license-entrapment, which is sort of what you'd like to do.
However, even when this irrevocability is unmentioned, there's US precedent[1] that consideration is exchanged in the use of a FOSS license, which TLDRLEGAL means that a license not mentioning irrevocability is likely revocable only for violation of its conditions.
So after saying it's "not worth using", "license entrapment", "clickbait"-- I mean you sound really unhappy about this, you sound super guilty ... like you hate that you have to pay for this, and you're super nervous about the legal stuff. Why all the crazy projections otherwise?
So anyway, then you go on, to diminish our work as only "pptr on ws", and lie that me standing up for myself and our company against that is "snark" -- then you continue to explain our business to us:
> ... 1000/seat ... don't care to self-host things ...
You have no idea about our market. You really have no idea at all.
You certainly have no idea what I wanna do, but you have no idea what our customers want.
They don't wanna trust this critical security thing, their browsing activity to a SaaS provider, right? That's sometimes a difficult sell. Or impossible. So they would rather, or they need to, have it on their own systems. Plus, you can get cost reductions: perpetual is 5 years of updates. That's 200 per year, just dollars over SaaS, and we can customize it way more than SaaS.
> ... I won't give shitload money ...
Yeah, you won't give it because you don't have the money, right? That's what you're upset about. Maybe you're just guilty that you're using the license wrong, and scared now you got to pay.
Look, maybe this was all an innocent mistake, and you've overreacted. OK, it happens. I get it. I mean, it doesn't excuse saying all these crazy lies but I'm sure it seems scary to find out you were doing something illegal and you didn't mean to. If that's the case, and you're just blowing up over this, I encourage you to get in touch with us: support@dosycorp.com and you can sort it out--we can figure something out--before it becomes a big problem. OK? So don't worry. Like I said, we're not interested in litigating, there's no business model in that. That only alienates customers.
But I mean if you're just coming on here for a fight, and have no idea about this, look man, we don't deal with abusive customers anyway, we don't want your money. You don't have it, but we don't want it. So it's not a problem.
There's enough good people who have money, and this is not a shitload anyway. Thank you! Best of luck. I look forward to your email if that's the case :p xx ;p :D
We need to make something very, very clear because it seems people have just gone nuts here, so: time to clarify.
Ever since the top comment here about licenses changing, people have gone crazy on this thread. This reaction is misguided because the issue they're reacting to doesn't exist; it's not real.
There are two cases to consider:
1. You're an individual using BrowserBox standard. None of this affects you. Thanks to the polyform strict license, you can just use it for personal use.
2. You're a company operating legally. None of this affects you either; you won't have any problems with the license changes.
There is no bait and switch here. The license changes are clear, and there's a considerable amount of time since it changed. The only people who would have a problem with the changes are those trying to illegally use the old licenses with the new code--but before this thread came up, I would have thought there weren't a huge number of people trying to do that. Anyway, this "fraudulent license use", is what I mean when I say "invalid and revoked." We would actively try to stop them from doing that.
We understand if the language used has confused people or if it has been misinterpreted. The language could have been more clear, and I apologize for not making it so.
However, any language we've used when changing the license always just means we're changing it--and trying to give notice of changing it!--and means that the previous licenses are invalid and revoked from that point forward. We never said it's retroactive. And when we talk of "previously released versions" we mean that the new license does not just apply to source code, but to the binaries, NPM packages, and so on, as we go on to specify. Again, from that point forward. And again, language could be more clear, we're never saying it's retroactive--and we're doing nothing wrong by changing the license. So please stop trying to say that we are!
So now that we've clarified that, the more troubling thing is as follows: People have just gone crazy here, which is weird because the only ones who would be shitting themselves about this would be companies who are trying to illegally use old licenses with new code. But why would they be so dumb? And then so dumb to reveal their fear at their own illegality online? Well, I guess criminals are dumb.
The old licenses, revoked and invalid for over a year, don't give you access to any of the new code, and don't give you access to Pro. There's a long way from the old code, to the new code, and an even longer way to Pro. We are not worried about these old licenses, we think it's a good thing that people have had in the past a variety of ways to integrate our journey's development snapshot, and continue to do so if they want to use the old stuff. It's just another part of the funnel, and is in line with our intention which we originally had to give people a sampler. But we changed the licenses to figure out a business model. But people are acting like this is a massive issue for us, but it's not: none of this affects our Pro revenue. And this old code is so far from that, people are not getting anything of the current value of that anyway. We're not worried about it, but people are acting like it's this massive thing, which is weird. So I think they're just projecting.
Even if you actually believed we retroactively changed it somehow, you would be confident in the legal protection, so you wouldn't care...unless you were trying to illegally use old license with new code. So, nothing justifies the insane crazy level of abuse and fake accusations on this thread from other commenters. The only ones who would think this would be a problem, would be the ones using this illegally--so please shut the fuck up! Because you're just revealing yourselves, and we don't want to sue you. We don't want to have to.
We're shocked, because before this thread we didn't know anyone was really trying to do that. I mean, we know there's always piracy, but we see these hysterical comments coming from people at companies in Canada, and it's really nuts.
The hysteria surrounding this issue is a fake, crazy problem that people have invented, which is baffling--because it only seems to reveals they want to do something illegal with the code, which is crazy.
Why have people gone berserk on this thread? I don't know. The main point to remember is that you wouldn't care unless you were doing something illegal with this. Perhaps the illegality of what they're trying to do is what's making people nervous, and that's what we're seeing from these hysterical commenters.
I suppose "going nuts" in this context is me letting you know that your desire to prevent use of your old commits under your old license is not legally possible, Not sure why you feel the need to turn a bunch of info I gave you into fuel for a flamewar.
I haven't considered and won't ever consider using your software, it's completely out of my wheelhouse (as you sort of tried to use as an insult?) I just commented to try and help you understand the license situation.
I think a feature comparison would help show why someone should pay that premium. What does BrowserBox have that the others are missing?
[1] https://dosyago.com/
[2] https://www.cloudflare.com/plans/zero-trust-services/
Edit: Clicking "Purchase" shows that the pricing is actually $50,000 for a pack of 50 seats, so 51 users would need 100 seats at $100,000. That's misleading.