Writing your own browser is up there with rolling your own cryptography in terms of the security risk. It is effectively a mini-OS that runs untrusted code. It can't protect your privacy if it has...
Writing your own browser is up there with rolling your own cryptography in terms of the security risk. It is effectively a mini-OS that runs untrusted code. It can't protect your privacy if it has security holes in any codecs or the JavaScript sandbox allowing hostile websites to attack your machine.
So, open source and good intentions aren't enough. Before trusting a browser I want to make sure they have security experts vetting the architecture and looking for security holes as an ongoing process. And that pretty much means only established organizations, sorry to say.
Min doesn't have any documentation of their security approach or who is behind it so I assume they're amateurs. If you run this it should probably be on a machine where you don't run anything else, and don't log into websites you care about.
So, since it's based on electron which is based on chromium, should it not be secure as such unless it made some core changes which created some loophole?
So, since it's based on electron which is based on chromium, should it not be secure as such unless it made some core changes which created some loophole?
Not necessarily. Depends on your security / privacy theater but simple telemetry on top of bare chromium can defeat the purpose of not using chrome over this from a privacy perspective. There is a...
Not necessarily. Depends on your security / privacy theater but simple telemetry on top of bare chromium can defeat the purpose of not using chrome over this from a privacy perspective.
There is a modern trend that equates open source with privacy friendly / top-notch security and this is absolutely false. Even big deal projects like openssl are not immune to big security issues like heartbleed.
Open source means that you have the means to audit how secure/private an app is because you have the means to build said app. The licenses themselves (GPL, MIT, ...) say that their software is provided as is and has no warranty of any form. Anything beyond that is trust: Trust that the developer does not introduce malicious features, or bugs, or lets contributors introduce them. This applies not only to code but to infrastructure used too: code repositories, compilers, build tools, etc.
Software security is a very deep very dark rabbit hole.
Not everyone needs to review open source for it to be vastly superior to closed source products. Much like vaccination, auditing provides herd immunity. But unlike vaccinations, herd immunity can...
Not everyone needs to review open source for it to be vastly superior to closed source products. Much like vaccination, auditing provides herd immunity. But unlike vaccinations, herd immunity can be acheived with even a tiny number of auditors.
Both suffer the trust problem, but with closed source products auditing isn't even an option.
I trust open source products 100x more than closed software. Not because I personally audit them, but because the possibility is there.
That openness tends to result in rapid fixes as well. OpenSSL's heartbleed bug only existed for two years, and time between discovery and patching was 6 days. Microsoft has frequently had to release patches for every OS, including ones that are long out of support, because of a severe bug that has been around for ages.
Open source software has the potential to be more secure but the software needs to be important enough that experts are taking a serious look at it. I'm doubtful that Min has received that...
Open source software has the potential to be more secure but the software needs to be important enough that experts are taking a serious look at it. I'm doubtful that Min has received that attention yet.
Also, most open source software isn't as high risk as a web browser.
My comment probably came out too aggressive. I use an open source OS that I don't review, in fact I don't review code for security as I'm not knowledgeable enough to spot anything. I usually just...
My comment probably came out too aggressive. I use an open source OS that I don't review, in fact I don't review code for security as I'm not knowledgeable enough to spot anything. I usually just trust organizations enough to run their code, or use some form of virtualization. Trust is perfectly fine if you are aware of its drawbacks.
Check out the report called Roads and Bridges. It gives some perspective on the case of openssl and other open source projects in the same space. Many important projects have very low manpower and companies don't tend to contribute back unless it makes some financial sense for them. There aren't that many eyes auditing stuff for the common good.
So for vaccination, herd immunity is when a sufficiently high percentage of the population is vaccinated (IIRC >95%) that the remaining population retains the benefits, as the odds of transmission...
So for vaccination, herd immunity is when a sufficiently high percentage of the population is vaccinated (IIRC >95%) that the remaining population retains the benefits, as the odds of transmission are so low that people who can't take a vaccine for some reason are still protected.
Open source software functions in much the same way, except the threshold for 'protecting the herd' is much lower. Only a small handful of users would need to review to provide massive benefits. The more auditors, the better and the more protected all users are.
By contrast, a closed source program will not likely have many, if any auditors. Any that do exist will likely operate in secret, and nobody will really be aware of how long a security bug goes unpatched. This is most evidenced by the fact that in 2014, IE had more CVE than Chrome and Firefox combined..and most of those were more severe.
Large, for-sale closed-source platforms are risky because the companies have a distict financial incentive to only fix discovered problems. After a product ships, companies don't want to spend any more work on it unless sales drop.
Small closed source platforms are even risker, as there really isn't any way to genuinely trust them.
As @skybrian mentioned, Min likely hasn't hit the threshold of auditors to make it 'more safe' due solely to being open source. However, that is likely irrelevant until they get a sufficiently large userbase to justify spending time attacking them and not just Chromium/Electron. And they're likely more secure and trustworthy than another random company tossing out a free closed-source browser.
Although, at this point in time, using anything that isn't Chrome-based is likely more secure, simply because monocultures are more susceptible to massive problems than diverse ecosystems (see also: Spectre/Meltdown and Intel server monoculture). And Chromium is a BIG target right now.
Web browsers aren't a monoculture and all the major browsers get significant attention from security researchers, including incentives like bug bounties and hacking contests, as well as folks like...
Web browsers aren't a monoculture and all the major browsers get significant attention from security researchers, including incentives like bug bounties and hacking contests, as well as folks like the Project Zero researchers looking for holes. They also get frequent security updates.
There probably are some security differences due to architecture and goals but I think it's hard to tell as someone who isn't a security expert which is most secure, and it can change over the years as they make security improvements. I think Firefox had a big architecture change recently?
So I don't think there's a simple argument showing which is best. Being a bigger target gets both positive and negative attention.
Picking something that gets hardly any attention at all seems pretty risky though, because maybe the first hacker who happens to look will find something easily?
Addressing this specifically: I can't think of a single software program, paid or not, that does a provide a warranty. Most closed programs also offer addons like: No refunds We can change these...
their software is provided as is and has no warranty of any form.
Addressing this specifically: I can't think of a single software program, paid or not, that does a provide a warranty.
Most closed programs also offer addons like:
No refunds
We can change these terms any time, if you don't agree stop using.
Binding arbitration
Class action waiver
We can revoke your license for any reason
So, for most closed software, it's pretty much the same or worse, unless you also buy a specific support contract as well.
You still have to be very careful when using electron to load untrusted content. There have been many security bugs in electron-based apps. Think of it like this: Even if you use somebody else's...
You still have to be very careful when using electron to load untrusted content. There have been many security bugs in electron-based apps.
Think of it like this: Even if you use somebody else's crypto library, you still need to use the tool correctly. (For example, Zoom encryption was using AES in ECB mode, which is a huge no-no).
Using Electron means that they haven't rolled their own engine, but how they use it can still leave them vulnerable to security bugs.
Although being built on trusted components helps, Electron uses a less secure architecture than Chrome: This isn't to say they couldn't have secured it in other ways. I haven't looked at what they...
When working with Electron, it is important to understand that Electron is not a web browser. It allows you to build feature-rich desktop applications with familiar web technologies, but your code wields much greater power. JavaScript can access the filesystem, user shell, and more. This allows you to build high quality native applications, but the inherent security risks scale with the additional powers granted to your code.
With that in mind, be aware that displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle. In fact, the most popular Electron apps (Atom, Slack, Visual Studio Code, etc) display primarily local content (or trusted, secure remote content without Node integration) – if your application executes code from an online source, it is your responsibility to ensure that the code is not malicious.
This isn't to say they couldn't have secured it in other ways. I haven't looked at what they did and would be surprised if they didn't make some attempt. But it doesn't happen automatically.
The individual project developers are responsible to keep things up to date and to follow best security practices since Electron has greater access to the system resources due to its nature as a...
The individual project developers are responsible to keep things up to date and to follow best security practices since Electron has greater access to the system resources due to its nature as a desktop app platform. Therefore, Electron apps don't necessarily inherit the security of Chromium. Plus there is at least a six week delay between the Electron release cadence (once every 12 weeks) and Chromium (once every 6 weeks).
@parsley's comment about trust and open source is great
Call it gut feeling, but I'm a little skeptical of that claim. Is there a known security vulnerability regarding Chromium's memory management? Or are you speaking strictly in terms of historical...
Call it gut feeling, but I'm a little skeptical of that claim. Is there a known security vulnerability regarding Chromium's memory management? Or are you speaking strictly in terms of historical CVE count?
From what I've seen Chromium has a much more thorough sandboxing approach than Firefox, mostly as a benefit of being a younger browser. Their extensions API was much stricter than XUL, and that seemed to be the right call as Mozilla eventually copied their API. Google also has Project Zero on their side, which is one of the leading security research teams on the planet right now.
Chrome always seems to do fairly well at CTF events. Not perfect, but as the most popular browser and thus the biggest target, they seem extraordinarily good at security.
We did that for other reasons; having a permissions model was just a nice bonus. This is true. How it gets interpreted depends on who you talk to. At one extreme you have the security hardening...
Their extensions API was much stricter than XUL, and that seemed to be the right call as Mozilla eventually copied their API.
We did that for other reasons; having a permissions model was just a nice bonus.
From what I've seen Chromium has a much more thorough sandboxing approach than Firefox, mostly as a benefit of being a younger browser.
This is true. How it gets interpreted depends on who you talk to. At one extreme you have the security hardening maximalists (for the lack of a better term) who deem anything that has less hardening as "insecure." On the other, you have the Pale Moon crowd who for some reason refuse to believe that defense-in-depth offers any value. As with most things, the "right" or "best" way depends on multiple factors and usually is a point on a shade of gray somewhere in the middle.
Google also has Project Zero on their side, which is one of the leading security research teams on the planet right now.
Sure, but P0 does not focus exclusively on Google products.
I do love an answer from the "horse's mouth". Thanks for offering your insight! And for what it's worth, I like and use both browsers quite often. My answer didn't come from any sort of "fanboy"...
I do love an answer from the "horse's mouth". Thanks for offering your insight!
And for what it's worth, I like and use both browsers quite often. My answer didn't come from any sort of "fanboy" position. Modern browsers are a marvel of engineering, and both teams have done exceptional work.
That's great! Last weekend I witnessed a big fanboy fight on r/Firefox that had no upside. It's important to try to remain objective in these kinds of debates and try to acknowledge where the...
That's great!
Last weekend I witnessed a big fanboy fight on r/Firefox that had no upside. It's important to try to remain objective in these kinds of debates and try to acknowledge where the other side has merits.
You're half right, Chromium is superior in certain ways having been built on some newer technologies and concepts but also retains some fatal flaws from the core C/C++ programming that in my...
You're half right, Chromium is superior in certain ways having been built on some newer technologies and concepts but also retains some fatal flaws from the core C/C++ programming that in my opinion make it more vulnerable than Firefox - not to mention a recent Windows update broke Chrome's sandboxing security since the developers coded some OS-level dependencies (not 100% sure on how that situation worked out, feel free to fact check me in case I'm wrong). There's a reason most of the truly security-oriented projects like Tor Browser utilise Firefox if you ask me.
I do remember reading about a Windows update breaking sandboxing. I guess there's some blame to share on that one. I'll give the article a read. Thanks for backing up your claim.
I do remember reading about a Windows update breaking sandboxing. I guess there's some blame to share on that one.
I'll give the article a read. Thanks for backing up your claim.
Some Google-fu returned the official Chromium project's statement on memory management, here you go :) https://www.chromium.org/Home/chromium-security/memory-safety At this point I think they're...
At this point I think they're just looking to rewrite the entire thing with something more modern like Rust, the amount of effort they'd put into patching the existing C/++ vulnerabilities probably wouldn't give such great returns.
The Forbes article above seemed a little too "technopanicy" to me, but this link was fantastic. I haven't seen their "rule of 2" page before, and that also made for a good read. I wonder it...
The Forbes article above seemed a little too "technopanicy" to me, but this link was fantastic. I haven't seen their "rule of 2" page before, and that also made for a good read.
I wonder it they'll follow Mozilla's lead in replacing components of the browser bit by bit. It seems to have worked well for them. That makes me curious about interop in the build process, seeing as it is generating one executable in the end.
I haven't used Rust yet but it seems to be doing some really good things for the industry.
Interesting take, while I do like the idea of a new browser entering the market to escape the botnet, the problem of security flaws is something that I didn't realize.
Interesting take, while I do like the idea of a new browser entering the market to escape the botnet, the problem of security flaws is something that I didn't realize.
Found it. I'm diggin' it. I'd like to have it open in private mode by default, but for now I just bound the "new tab" command to "new private tab." Oh, and an option for setting default fonts...
Found it. I'm diggin' it. I'd like to have it open in private mode by default, but for now I just bound the "new tab" command to "new private tab." Oh, and an option for setting default fonts would be nice.
Three questions of anything presenting itself as a viable alternative to the incumbent players in the browser arena: Will it render most sites similarly enough? Will it execute JS similarly...
Three questions of anything presenting itself as a viable alternative to the incumbent players in the browser arena:
It looks alright, but with the lack of extensions (you can use userscripts), I don't really see the benefit. it tiles! I still don't quite see the benefit. The UI is somewhat minimal and all that,...
For anyone using Yabai, this won't tile. It looks alright, but with the lack of extensions (you can use userscripts), I don't really see the benefit.
it tiles! I still don't quite see the benefit. The UI is somewhat minimal and all that, but the UI is pretty much the same size as Chrome with the bookmark bar.
Writing your own browser is up there with rolling your own cryptography in terms of the security risk. It is effectively a mini-OS that runs untrusted code. It can't protect your privacy if it has security holes in any codecs or the JavaScript sandbox allowing hostile websites to attack your machine.
So, open source and good intentions aren't enough. Before trusting a browser I want to make sure they have security experts vetting the architecture and looking for security holes as an ongoing process. And that pretty much means only established organizations, sorry to say.
Min doesn't have any documentation of their security approach or who is behind it so I assume they're amateurs. If you run this it should probably be on a machine where you don't run anything else, and don't log into websites you care about.
So, since it's based on electron which is based on chromium, should it not be secure as such unless it made some core changes which created some loophole?
Not necessarily. Depends on your security / privacy theater but simple telemetry on top of bare chromium can defeat the purpose of not using chrome over this from a privacy perspective.
There is a modern trend that equates open source with privacy friendly / top-notch security and this is absolutely false. Even big deal projects like openssl are not immune to big security issues like heartbleed.
Open source means that you have the means to audit how secure/private an app is because you have the means to build said app. The licenses themselves (GPL, MIT, ...) say that their software is provided as is and has no warranty of any form. Anything beyond that is trust: Trust that the developer does not introduce malicious features, or bugs, or lets contributors introduce them. This applies not only to code but to infrastructure used too: code repositories, compilers, build tools, etc.
Software security is a very deep very dark rabbit hole.
Not everyone needs to review open source for it to be vastly superior to closed source products. Much like vaccination, auditing provides herd immunity. But unlike vaccinations, herd immunity can be acheived with even a tiny number of auditors.
Both suffer the trust problem, but with closed source products auditing isn't even an option.
I trust open source products 100x more than closed software. Not because I personally audit them, but because the possibility is there.
That openness tends to result in rapid fixes as well. OpenSSL's heartbleed bug only existed for two years, and time between discovery and patching was 6 days. Microsoft has frequently had to release patches for every OS, including ones that are long out of support, because of a severe bug that has been around for ages.
Open source software has the potential to be more secure but the software needs to be important enough that experts are taking a serious look at it. I'm doubtful that Min has received that attention yet.
Also, most open source software isn't as high risk as a web browser.
My comment probably came out too aggressive. I use an open source OS that I don't review, in fact I don't review code for security as I'm not knowledgeable enough to spot anything. I usually just trust organizations enough to run their code, or use some form of virtualization. Trust is perfectly fine if you are aware of its drawbacks.
Check out the report called Roads and Bridges. It gives some perspective on the case of openssl and other open source projects in the same space. Many important projects have very low manpower and companies don't tend to contribute back unless it makes some financial sense for them. There aren't that many eyes auditing stuff for the common good.
Could you expand on this a bit?
So for vaccination, herd immunity is when a sufficiently high percentage of the population is vaccinated (IIRC >95%) that the remaining population retains the benefits, as the odds of transmission are so low that people who can't take a vaccine for some reason are still protected.
Open source software functions in much the same way, except the threshold for 'protecting the herd' is much lower. Only a small handful of users would need to review to provide massive benefits. The more auditors, the better and the more protected all users are.
By contrast, a closed source program will not likely have many, if any auditors. Any that do exist will likely operate in secret, and nobody will really be aware of how long a security bug goes unpatched. This is most evidenced by the fact that in 2014, IE had more CVE than Chrome and Firefox combined..and most of those were more severe.
Large, for-sale closed-source platforms are risky because the companies have a distict financial incentive to only fix discovered problems. After a product ships, companies don't want to spend any more work on it unless sales drop.
Small closed source platforms are even risker, as there really isn't any way to genuinely trust them.
As @skybrian mentioned, Min likely hasn't hit the threshold of auditors to make it 'more safe' due solely to being open source. However, that is likely irrelevant until they get a sufficiently large userbase to justify spending time attacking them and not just Chromium/Electron. And they're likely more secure and trustworthy than another random company tossing out a free closed-source browser.
Although, at this point in time, using anything that isn't Chrome-based is likely more secure, simply because monocultures are more susceptible to massive problems than diverse ecosystems (see also: Spectre/Meltdown and Intel server monoculture). And Chromium is a BIG target right now.
Web browsers aren't a monoculture and all the major browsers get significant attention from security researchers, including incentives like bug bounties and hacking contests, as well as folks like the Project Zero researchers looking for holes. They also get frequent security updates.
There probably are some security differences due to architecture and goals but I think it's hard to tell as someone who isn't a security expert which is most secure, and it can change over the years as they make security improvements. I think Firefox had a big architecture change recently?
So I don't think there's a simple argument showing which is best. Being a bigger target gets both positive and negative attention.
Picking something that gets hardly any attention at all seems pretty risky though, because maybe the first hacker who happens to look will find something easily?
Makes sense, thanks for the explanation! Though not certain I agree the analogy holds, the point certainly does.
Addressing this specifically: I can't think of a single software program, paid or not, that does a provide a warranty.
Most closed programs also offer addons like:
So, for most closed software, it's pretty much the same or worse, unless you also buy a specific support contract as well.
Well said. I feel like this needs to be stickied at the top of all Reddit's tech/software/privacy-related subs :P
You still have to be very careful when using electron to load untrusted content. There have been many security bugs in electron-based apps.
Think of it like this: Even if you use somebody else's crypto library, you still need to use the tool correctly. (For example, Zoom encryption was using AES in ECB mode, which is a huge no-no).
Using Electron means that they haven't rolled their own engine, but how they use it can still leave them vulnerable to security bugs.
Although being built on trusted components helps, Electron uses a less secure architecture than Chrome:
This isn't to say they couldn't have secured it in other ways. I haven't looked at what they did and would be surprised if they didn't make some attempt. But it doesn't happen automatically.
The individual project developers are responsible to keep things up to date and to follow best security practices since Electron has greater access to the system resources due to its nature as a desktop app platform. Therefore, Electron apps don't necessarily inherit the security of Chromium. Plus there is at least a six week delay between the Electron release cadence (once every 12 weeks) and Chromium (once every 6 weeks).
@parsley's comment about trust and open source is great
Chromium has its own issues in terms of security/memory management, if you're really concerned about it then Firefox is the way to go.
Call it gut feeling, but I'm a little skeptical of that claim. Is there a known security vulnerability regarding Chromium's memory management? Or are you speaking strictly in terms of historical CVE count?
From what I've seen Chromium has a much more thorough sandboxing approach than Firefox, mostly as a benefit of being a younger browser. Their extensions API was much stricter than XUL, and that seemed to be the right call as Mozilla eventually copied their API. Google also has Project Zero on their side, which is one of the leading security research teams on the planet right now.
Chrome always seems to do fairly well at CTF events. Not perfect, but as the most popular browser and thus the biggest target, they seem extraordinarily good at security.
We did that for other reasons; having a permissions model was just a nice bonus.
This is true. How it gets interpreted depends on who you talk to. At one extreme you have the security hardening maximalists (for the lack of a better term) who deem anything that has less hardening as "insecure." On the other, you have the Pale Moon crowd who for some reason refuse to believe that defense-in-depth offers any value. As with most things, the "right" or "best" way depends on multiple factors and usually is a point on a shade of gray somewhere in the middle.
Sure, but P0 does not focus exclusively on Google products.
I do love an answer from the "horse's mouth". Thanks for offering your insight!
And for what it's worth, I like and use both browsers quite often. My answer didn't come from any sort of "fanboy" position. Modern browsers are a marvel of engineering, and both teams have done exceptional work.
That's great!
Last weekend I witnessed a big fanboy fight on r/Firefox that had no upside. It's important to try to remain objective in these kinds of debates and try to acknowledge where the other side has merits.
You're half right, Chromium is superior in certain ways having been built on some newer technologies and concepts but also retains some fatal flaws from the core C/C++ programming that in my opinion make it more vulnerable than Firefox - not to mention a recent Windows update broke Chrome's sandboxing security since the developers coded some OS-level dependencies (not 100% sure on how that situation worked out, feel free to fact check me in case I'm wrong). There's a reason most of the truly security-oriented projects like Tor Browser utilise Firefox if you ask me.
Gordon Kelly also covered some of this a few days ago - https://www.forbes.com/sites/gordonkelly/2020/05/26/google-chrome-critical-security-vulnerability-warning-firefox-update-chrome-browser/
I do remember reading about a Windows update breaking sandboxing. I guess there's some blame to share on that one.
I'll give the article a read. Thanks for backing up your claim.
Some Google-fu returned the official Chromium project's statement on memory management, here you go :) https://www.chromium.org/Home/chromium-security/memory-safety
At this point I think they're just looking to rewrite the entire thing with something more modern like Rust, the amount of effort they'd put into patching the existing C/++ vulnerabilities probably wouldn't give such great returns.
The Forbes article above seemed a little too "technopanicy" to me, but this link was fantastic. I haven't seen their "rule of 2" page before, and that also made for a good read.
I wonder it they'll follow Mozilla's lead in replacing components of the browser bit by bit. It seems to have worked well for them. That makes me curious about interop in the build process, seeing as it is generating one executable in the end.
I haven't used Rust yet but it seems to be doing some really good things for the industry.
Interesting take, while I do like the idea of a new browser entering the market to escape the botnet, the problem of security flaws is something that I didn't realize.
This seems like a nice browser, I will check it out later. Also, did you make it or did you find it online somewhere?
Found it. I'm diggin' it. I'd like to have it open in private mode by default, but for now I just bound the "new tab" command to "new private tab." Oh, and an option for setting default fonts would be nice.
Three questions of anything presenting itself as a viable alternative to the incumbent players in the browser arena:
I can't find answers to these regarding Min.
For anyone using Yabai, this won't tile.It looks alright, but with the lack of extensions (you can use userscripts), I don't really see the benefit.it tiles! I still don't quite see the benefit. The UI is somewhat minimal and all that, but the UI is pretty much the same size as Chrome with the bookmark bar.
Is there any way to install min on linux os that don't support deb or rpm?