On the contrary, it makes a significant difference vs Chromium. Using Electron means having jettisoned a number of security protections that Chromium offers while exposing the system to the attacks those are designed to stop.
In design terms, this is a wonderful, beautiful, laudable project in pursuit of a great purity of vision.
In security terms, this is an exercise in recklessness. It's irresponsible to even suggest that people should try using it.
This seems like a good start to understanding Electron security and why using it to do what the documentation expressly states is unwise might be less than optimal.
Can you give a specific example of what is wrong with Min's security configuration, assuming it is following Electron best practices. Asserting that the security model is bad and linking to Electron's security tutorial is not helpful.
For my own part, I find the introduction that specifically warns that Electron is not a web browser and should not be trusted to handle potentially malicious code from over a network to be clear enough. I understand that this is an opinion that not everyone will share.
For a single specific example, look at the information on permissions and compare to how min handles them. I also see no functionality that attempts to determine if code is malicious or not. Chrome does have measures in it to do this.
That said, I need to be clear. The matter at hand is not a matter of mere configuration and cannot be addressed by better configuration of Electron. Chromium was designed and built to run in a very hostile context. Electron has been built to run in a much more trustworthy context. There is no amount of configuration that will turn the latter into the former because it is not purely a difference of configuration.
Electron's security model is not bad in any absolute sense. It's designed for a particular context and set of scenarios. Dropping it into a very different one with very different needs makes it a poor fit for the job at hand. You may as well descend into a volcano with a home stove potholder.
I hope this has clarified matters. I understand that some people will be very discouraged by the stance I have taken on this. I have no desire to crush their dreams, only to ensure they make good and wise decisions around security.
First and foremost, electron runs on often outdated versions of chromium which are vulnerable to known 0days.
Electron RPC also makes it really easy to get RCE if you don't implement it properly, and most JavaScript developers don't implement it properly. Electron also does not have anywhere near as much security research into it.
I switched to Safari last year. The battery life improvements over Chrome makes it worth. It’s been a solid browser experience and I haven’t gone back to Chrome for anything. I wish I could add Kagi as a default search.
I use kagi and had not even heard that they have their own browser. Why would why use that over one of the "big three" (FF/Chrome/Safari) with serious corporate security teams backing them?
edit: Okay so it's webkit based, mac only, with built-in adblocking, which sounds nice, but honestly the idea that it can easily install extensions from both chrome and firefox sounds like a security nightmare to me.
The fact that the only mention of security in their FAQ is to conflate it with privacy
"Most browsers regularly "phone home" dozens or even hundreds times. Each request poses a security risk"
Telemetry can be a security risk from a standpoint of exposing PII to a hostile actor.
Full text for reference:
"Each request poses a security risk, no matter what information it sends, by potentially exposing your IP address and your browser fingerprint. Telemetry can also inadvertently leak personally identifiable information or corporate intelligence."
Kagi's Orion runs Firefox and Chrome extensions, including on iOS, and of course works with Kagi search, which is enough better that it's worth switching from Google/Bing/DDG.
---
EDIT to add, on iCab, it's been updated as of 2020, which unfortunately finally dropped the legacy Macs, but does support modern filter lists:
iCab 6.0 (September, 28th 2020)
iCab 6.0 is completely rewritten, therefore there’re many new features and existing many old features have changed. The new release uses the newer modern web engine of the macOS which is much faster and smoother than the classic engine that was used by older iCab releases. It also supports more web technologies.
Because the modern web engine had too many limitations under macOS 10.12 and older, the minimum macOS release for the new version of iCab is therefore macOS 10.13. Older macOS releases are no longer supported. This has the advantage that iCab can now rely on many native macOS features which are only available in newer macOS releases.
iCab now uses the native „Tabs“ feature of the macOS, so the tabs in iCab will now behave just as the Tabs in all other Apps using the native Tabs feature (like Safari Mail, the Finder etc). All the capabilities of the macOS to manage tabs are fully available in iCab as well.
iCab is now using the native filter capabilities of the modern web engine of the macOS. Therefore the filter manager is completely new. The new filter manager supports the popular filter lists from AdBlock Plus, Easylist, uBlock and compatible. The filter manager window provides a few links to web sites where you can find these filter lists. using the „Add“ or „Subscribe“ links on these sites can directly import these filter lists, but you can also simply download these lists into a file and then use the „import“ feature of the Filter Manager to import these files.
iCab 6.0 supports syncing of tabs, bookmarks, reading list, filters and search engine via iCloud. The iCloud sync is compatible to iCab Mobile for the iOS platform, so you can now sync all this data between iCab for the Mac and iCab Mobile for the iOS as well.
The new web engine provides more control over audio and video playback. It is possible to immediately stop all audio and video playback with a certain menu command. But it can also make sure that audio and video playback only occurs on the active tab.
Modules of the module manager can be put into the status bar, so these modules are directly accessible very fast and comfortably.
The App supports private tabs which do not save any private data (Cookies, Caches etc). Private tabs are marked with a red border around the address field.
>Kagi search, which is enough better that it's worth switching from Google/Bing/DDG.
But highly unlikely to be better enough to justify paying a subscription for it (for most people, anyway), so it's always going to be confined to a small niche of users.
Here's a Venn diagram of two "worth it" reasons, not mutually exclusive:
I'd argue if you live in first world, earn a living from tech, even if you don't care whether you pay for things vs. be tracked, it's worth the subscription, in the sense of, it's enough better to be worth paying for as a better tool, not just because there's no gaming of the SERPs above the fold. The Lenses are impressive, but it's not just that, the results are what one used to appreciate from web search. After getting used to the quality, the lower quality of Google or the Bing derivatives like DDG will frustrate you.
If you dislike adtech or value privacy, it's worth the subscription, because there are no ads and no tracking. (Also, unlike neeva, to which I also subscribe, it's not an ad-alternative model from former ad-tech people.)
Does everything need to be a billion dollar business?
Globally, I can easily see enough users sign up to sustain the small team. Their blog post [0] mentiones they calculate they need 25,000 subscribers to sustain themselves.
One might argue this should be a fork of Chromium, not Electron. Chromium comes with native tabs and a bunch of other useful parts, without the security issues that Electron exposes.
> One might argue this should be a fork of Chromium, not Electron.
Fair enough point. One reason it's Electron, I assume, is that it's much easier for typical developers to build than forking Chromium. I've been there. I've hacked at building a touchless-controlled browser that uses hand gesture and speech recognition to interact with the web. I can cobble something basic together in Electron, but it's much more intensive to get off the ground forking Chromium (though you're right the native tabs and useful parts would be helpful).
> without the security issues that Electron exposes.
Another reasonable point. For reference, here's an overview of security from Electron itself.[1] Security issues are one reason I haven't pursued the touchless browser more actively. I don't know if it's a dealbreaker, but it's not my area of expertise and I'd need to get seriously up to speed before releasing anything.
From a glance, it does look like Min is trying to follow good security practices, such as having BrowserView webPreferences default to "nodeIntegration: false", "contextIsolation: true", etc.[2] And in the issues the maintainers seem aware of security issues, eg:
> Making internal pages have the same privileges as the browser UI would be nice, although it's kind of difficult to implement. You could add nodeintegration to the webview tag, but I think there's a pretty big risk of accidentaly loading a regular webpage with nodeintegration enabled if we do that, which would be bad.[3]
Ideally there wouldn't be such a large Chromium (and Chromium-based) monopoly on browsers, but overall I'm still glad to see projects like this trying to create different UI options.
This isn't a fork of Electron. It is an Electron-based app, and as such the Electron project maintains the core functionality of the browser and Min just presents a unified interface and feature set.
They didn't say "fork of Electron", rather Electron is essentially "Chromium - browser UI" so they are saying there is a simplification to be made in an app that is "Chromium - browser UI + browser UI"
Flagging that the phrase "this should be a fork of Chromium, not Electron" is ambiguous between "this shouldn't be a fork of Electron" and "this shouldn't be Electron".
The phrasing is ambiguous, I agree. However, as forking Electron to make Min wouldn't make any sense, and the replier knew this, reading it to mean that seems like a mistake to me. The fact is that it can be very difficult to write things that aren't ambiguous at some level (albeit that isn't the case here), so the reader has to make a good-faith effort to understand.
I wouldn't be surprised if you could find a add-on to get close to that. I used one for Firefox in the late 00s that gave a similar minimal effect, just not as extreme.
Today browsers are one of the most important pieces of security software on our machine. They have a huge surface area, act as a sandbox for gobs of untrusted code and many of us conduct our most sensitive work in them (online banking etc). I'd be hesitant to use any browser that doesn't have the team behind it to quickly manage threats and maintain high quality code.
Sadly, modern browsers don't allow add-ons to significantly alter the UI, so you'd never see an extension like this today.
You can do some neat stuff with userchrome in Firefox (not as an add-on) but it'll break after basically every update. There's no infrastructure in place to update the userchrome in sync with the browser, and Mozilla appears to be hostile towards the whole feature.
There are decent reasons for all of this, but it means the only way to experiment is to basically make your own app, as Min did.
Yeah, when I saw that, I decided not to bother even checking it out. Your app has to be really essential if you expect me to used a bloated, glorified web app.
Anyway, use firefox or librewolf. Stop enabling the chromium monopoly!