Transmission of an apk is compressed so having a library uncompressed in the apk like Chromium doesn't waste bandwidth. The apk uses a bit more space on the device, but less than having it both compressed in the apk and extracted alongside it. Firefox's design choice is terrible.
Conversation
Firefox (fennec) is in semi-maintenance mode -- you should check to see whether Fenix has the same behavior and report it as an issue if so.
github.com/mozilla-mobile
tools.taskcluster.net/index/project.
2
1
2
Is this still Firefox but just replacing the mobile integration with something new?
2
It throws away their Android app code and replaces it with a more modern codebase written in Kotlin without bad legacy decisions. It uses Gecko via a new modular library aimed at offering an alternative to the Android WebView.
wiki.mozilla.org/Mobile/GeckoVi
1
1
Not so sure "Because GeckoView is a standalone library that you bundle with your application, you can be confident that the code you test is the code that will actually run." is a feature though. Automatic WebView updates without app involvement + always on sandbox is great.
2
I'd say having webview at all is a misfeature. Non-browser apps should never be embedding browsers; this should be grounds for ban from store. It's essentially phishing for credentials.
1
Most Android browsers are WebView frontends. Firefox's own Focus browser started out as one, but now they're moving to using GeckoView as a replacement for the WebView primarily as a dogfooding thing. The WebView itself isn't really a browser, just a web rendering engine though.
1
Each app's usage is a separate instance. It's usually a shortcut to cut costs by avoiding the development of a proper native app. Instead, they reuse web development work for portions of the app on both Android and iOS. There are whole app development frameworks built on it.
2
A use case that I had for it was to build a PDF Viewer leveraging the hardened Chromium rendering stack. It has a fully static set of code and style properties (enforced by CSP), so RCE would need to happen via the small subset of the browser rendering engine within the sandbox.
1
1
As opposed to using one of the many native PDF rendering libraries written in C like libpoppler, along with much more directly exposing the GPU stack, font rendering stack, etc. which are much less hardened than the way it's exposed in Chromium since it's for untrusted content.
I think that's a decent approach to handling extremely complex document formats. Rather than having a separate native rendering stack for each one, it's more than fast enough to convert them on the fly to a web page, without actually generating / running any untrusted JS or CSS.
1
I was very disappointed that Mozilla abandoned github.com/mozilla/shumway because it could have become a great way of handling archived Flash content like old games within a browser without additional attack surface. Instead people will keep using Flash long after it's unmaintained.
1
Show replies
This is why we need a memory-safe C implementation, even if it has 10x overhead. The alternative is running everything through a fucking browser engine with 1000x overhead.
2
1
6
Show replies