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