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.

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...

https://github.com/black7375/Firefox-UI-Fix/wiki/Show-Off-Yo... https://github.com/black7375/Firefox-UI-Fix/pull/511