I don't think it would be hard to implement the standard API in terms of the app layer but it wouldn't be compatible with many apps written with the assumption that they are targeting Chromium. There are so many both subtle and substantial differences between browser engines.
Conversation
So, realistically, there has to be a Chromium-based WebView implementation used by many applications. It's part of the standard attack surface. Using any other browser engine for the web browser means having 2 browser engines being heavily used. I can't really see this changing.
1
I can see Firefox eventually catching up in the security areas where it's lagging behind, but there's so much usage of Chromium elsewhere. On Android, a major positive is that this is generally via the automatically updated WebView with a stable app API.
1
I would like to have the option of including Firefox as the default browser in the engine, as both the user-facing browser and WebView, but I don't think that's realistic due to lack of browser compatibility. Sticking to web standards doesn't avoid all the distinctions either.
1
I wouldn't actually want that in the near future, but it would be nice to have options open in the future. For now, I definitely think a Chromium base is a much better choice, but I wouldn't have contributed so heavily to Rust if I didn't think that was a long-term game changer.
1
I can't consider shipping 2 browser engines though. It's just not at all sensible based on the security goals of my work. So, even if I thought some far future version of Firefox or another browser engine (seems unlikely) was a better option, it would be worse to expose both.
1
So, that's a big part of why it was so appealing to me for a project like Brave to seemingly be starting on the path of doing substantial privacy enhancements for Chromium. The progress died out though, and it's now clear to be it's not a core focus / goal + the approach sucks.
1
You mention the Tor Browser wants to get as much code upstream into Firefox and have a diff as small as possible to make it far more maintainable and stop endless churn from destroying their downstream work. I care about this a lot too, and I spent a lot of time upstreaming.
1
My perspective of Brave's approach is that they do the opposite. A larger difference is appealing to them and they use a difference license so you can't just take code from it and upstream it. The way the patch set is maintained is a complete mess, more like a messy fork.
1
It's not a rebased patch set design to be clean, lean and easy to port between each version very quickly along with upstreaming the patches. It's a mess of commits and a lot of the code is messy / ugly too. I have major issues with how they did some of the implementation work.
1
The main issue is that I've just been totally put off by their hostile attitude towards not having Play Services (despite Google supporting it) and their entire core focus which is building what I see as a sketchy as hell model for browser-based ads with a cryptocurrency token.
This did not exist for Brave on Android when I recommended it. The implementation ended up literally using SafetyNet attestation as a form of DRM (Brendan totally freaked out that I called it this but I do think it's entirely fair) to prevent people from not actually viewing ads.