GeckoView

From time to time I receive suggestions from people that I change Privacy Browser to use Mozilla’s GeckoView instead of Android’s WebView to render pages. Instead of responding to each of these communications individually, I thought it helpful to write a general post covering this subject and explaining why I am not now considering doing so (although I am always open to it in the future if it becomes in the best interest of Privacy Browser to do so).

First, a little bit of background is necessary. The Android Open Source Project contains a standard system library called WebView that renders HTML content. It is programmatically similar to TextView, ImageView, EditText, or any of the other standard views that are included in Android. Many apps that users might not realize use this library to handle complex layouts. If WebView is removed from Android a large number of apps will crash unexpectedly.

In the open source world, there are two large pedigrees of code for rendering HTML content: WebKit (and its forks) and Gecko. Gecko is the engine developed by Mozilla and used in Firefox. Years ago, when Apple decided to make Safari they looked around at the existing code bases. They could have used Gecko, but they decided to fork KHTML and KJS (developed for KDE on Linux and used in Konqueror) and formed WebKit. When Google decided to get into the browser world they also built on WebKit instead of Gecko. Eventually they forked WebKit and created Blink. Opera used to have their own engine, but they eventually dropped it to use Blink (through a customized version of Chromium ). Edge recently did the same thing.

Android’s WebView was originally based on WebKit, but it switched to Blink beginning with Android 4.4 (KitKat, API 19). Originally, WebView was only updated with Android releases. But beginning with Android 5.0 (Lollipop, API 21), Google refactored the code so that WebView could be updated via an APK through the Play Store. Beginning with Android 7.0 (Nougat, API 24), Google allows different apps to provide the WebView library. Because the current WebView is built from the same code base as Chromium, by default the Chrome package provides Android’s WebView (if it is installed). Otherwise, the Android System WebView package provides it. I do not know why, but this Chrome behavior stopped with Android 10 (API 29) and Google went back to using the Android System WebView package to provide WebView by default.

WebView is limited in the privacy controls it exposes to developers. For example, it isn’t possible to enable some JavaScript commands and disable others. It isn’t possible to disable WebRTC while JavaScript is enabled. It isn’t possible for some tabs to proxy through Orbot while other’s don’t. It isn’t possible to customize the CSS of a website without having JavaScript enabled. It isn’t possible to customize the user agent on resource requests. And it isn’t possible to spoof a large majority of fingerprinting information, like screen size, the system font list, and the canvas hash. Because of this, in the 4.x series of Privacy Browser I intend to create a rolling fork of WebView called Privacy WebView. This rolling fork will be composed of a set of minimally invasive patch files that add additional privacy controls without breaking API compatibility for existing commands. These patches will be rebased with each release of WebView. It is an ambitions project, and it will be quite time consuming, but it has a number of advantages.

1. It is a lot simpler than creating an entirely new rendering engine.
2. It will be API backwards compatible with Google’s WebView, which means that users can set it as the default WebView provider for all apps on their device.

Some people have suggested I consider using Bromite SystemWebView or GeckoView instead. Those who like GeckoView are usually primarily attracted to the idea of removing as much Google as they can from their lives. Although I am generally in favor of that idea, I do not feel that GeckoView is a good fit for Privacy Browser for the following reasons.

1. GeckoView is not API compatible with WebView. This means a significant portion of Privacy Browser’s code would have to be rewritten (there are a lot of little bugs in getting a rendering engine to work correctly with things like domain settings). Not that I am opposed to refactoring code, but there has to be a significant benefit at the end of the tunnel to make it worth it.
2. GeckoView does not expose a significantly greater portion of the privacy settings I need than Android’s WebView. As such, I would still be stuck creating a rolling fork of GeckoView with the same level of time commitment.
3. Because GeckoView is not API compatible with WebView, a custom fork could not function as a drop-in replacement for Android’s WebView. Although this is not an absolute necessity, it is one of the nice things I am trying to accomplish with Privacy WebView.
4. I don’t trust Mozilla much more than I trust Google. As a long time user of Firefox since the days it was called Phoenix, I have watched them go downhill and consistently make decisions that are not in the best privacy interests of their users. For example, if they really cared about user privacy they would incorporate their blocklists from Firefox Focus into the main Firefox product and apply them to all websites. But they won’t do this because they make hundreds of millions of dollars every years through their search contracts, and the search companies are not going to pay them that type of money if the tracking of users’ searches are blocked.
5. I have significant concerns about Mozilla’s commitment to the Android ecosystem. If I rebase Privacy Browser on GeckoView, and down the road they decide it isn’t in their strategic interests to maintain it, I’ll be up the proverbial creek without the proverbial paddle.

As I mentioned at the top of this post, I am open to changing my mind about GeckoView (or any future rendering engine). But it doesn’t currently look like a good match for Privacy Browser.