A browser in electron? At this point just use chromium - makes no difference.
Anyway, use firefox or librewolf. Stop enabling the chromium monopoly!
Anyway, use firefox or librewolf. Stop enabling the chromium monopoly!
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.
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.
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.
If you want to read more into the current state of electron security research, see https://blog.electrovolt.io/
Or Safari of course, it's really a great browser if one's on the Mac.
The venerable iCab or new Orion from Kagi shows what's possible here.
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.
And much more
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.
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.)
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.
(I'm a paying customer, FWIW).
[0] https://blog.kagi.com/status-update-first-three-months#futur...
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"
is a red flag IMHO
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."
Amen to that, FF & the rest for the win!
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".
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.
[1] https://www.electronjs.org/docs/latest/tutorial/security
[2] https://github.com/minbrowser/min/blob/7aba03fb645334366f9ec...
[3] https://github.com/minbrowser/min/issues/554#issuecomment-38...
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.
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.
https://github.com/black7375/Firefox-UI-Fix/wiki/Show-Off-Yo... https://github.com/black7375/Firefox-UI-Fix/pull/511