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.

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.

Join the Conversation

7 Comments

    1. Hund, I currently use Firefox on Linux as my daily driver. I used to use Konqueror, but it got a little long in the tooth without being actively maintained.

      Part of the reason I started Privacy Browser is because I didn’t feel like I had any options I really liked. Once I finish the 4.x series of Privacy Browser for Android I am going to start working on Privacy Browser for desktop operating systems. The details are not fully fleshed out, and are subject to change, but currently I am thinking I will develop it using the Qt framework (the same framework used by KDE). Doing so will let me use one code base that runs on Linux, Windows, and macOS.

      https://www.qt.io/

      QT contains a HTML rendering engine called Qt WebView based on WebKit. I think there is some possibility they may accept the changes I need into the upstream source code, especially if I am willing to help maintain them, so that I don’t need to end up maintaining a separate fork of the the rendering engine on desktops.

      https://doc.qt.io/qt-5.11/qtwebview-index.html

      1. That sounds nice. 🙂 I currently use a Qt-based Vi-like web browser that uses QtWebEngine which is called qutebrowser.

        It’s a great browser, but I like having two browsers. One for the everyday stuff like reading this blog and visiting online forums and a secondary web browser that’s somewhat hardened for the shady part of the web where I don’t want to be tracked, like when shopping. 🙂

        What’s the benefit of using QtWebView over QtWebEngine? I don’t know enough to have an opinion myself.

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

    They actually recently added tracking protection and content blocking to classic Firefox.

    And I would trust Mozilla more than Google. They are at least trying to make privacy browser. And they don’t have in their terms of service that they can publicly display your content (as Google has):

    > When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content.

    Also, Google recently made the decision to block ad blockers which will have an impact on almost all browsers on the world (because they all use Chromium). What if they someday decide to make even worst decision which will then have an impact on the whole web?

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

    They will probably continue developing GeckoView. Their new Firefox for Android (Fenix) will be based on it, so they will probably continue maintaining and developing it.

    1. > They actually recently added tracking protection and content blocking to classic Firefox.

      There is a lot of money to be made by pretending to sell privacy. The changes Mozilla recently made to Firefox don’t go nearly far enough. Just enough that they can pretend to care about your privacy.

      Mozilla makes almost all their money by selling the default search engine setting to the highest bidder. Those search engines make their money by embedding ads in the search results. I have no problem with the idea of having ads in my search results, but all the current major search engines include highly invasive tracking in their ads. That is where I do have a problem. As long as Mozilla makes their money from the search engines, they will never implement serious privacy protections that would block the tracking of those ads, because nobody is going to pay them $400 million a year to be the default search engine if their tracking is blocked.

      > And I would trust Mozilla more than Google. They are at least trying to make privacy browser. And they don’t have in their terms of service that they can publicly display your content (as Google has):

      > Also, Google recently made the decision to block ad blockers which will have an impact on almost all browsers on the world (because they all use Chromium). What if they someday decide to make even worst decision which will then have an impact on the whole web?

      If this were a discussion about which desktop browser to use I would agree with you. Nobody who cares about their privacy should be using Google Chrome. However, this is a discussion about which rendering engine I should base Privacy Browser on. The changes that Google has been making to Chrome have no effect on WebView. And even if they did decide to modify WebView in negative ways, when I create the Privacy WebView rolling fork it would be fairly easy to disable any of those changes.

      > They will probably continue developing GeckoView. Their new Firefox for Android (Fenix) will be based on it, so they will probably continue maintaining and developing it.

      It’s the “probably” part of that which has me concerned.

Leave a comment

Your email address will not be published. Required fields are marked *