WebKit, AOSP/Google Webview, Gecko


Hi there,

I’m looking for a clear explanation between all these web browser engines.

• WebKit is developped by Apple - open source
• AOSP webview aka Blink - open source - based on WebKit
• Google webview: fork of AOSP with proprietary stuff
• Gecko: supports open Internet standards, W3C recommendations, open source… developped by Mozilla.

For example, Firefox Focus is based on WebKit so is it really linked to AppleWebkit or is just based on Blink/Google Webview?
EDIT: based on Blink I think

Thanks for any confirmation, correction and new information!

Comrade stoutner about webview

As far as I know every webbrowser that is released for iOS is not allowed to run its own browser engine. For example (by my knowledge) Chrome for iOS uses Apple’s browser engine.

The difference between browser engines are support for standards, being or not OS, implementation of the web rendering… Between WebKit and Guecko are a lot of differences, yet both of them shows the web as it should be. There’s not more than that kind of stuff.

I don’t know anything else than that, sorry if it’s not much.

  1. In the open source world, there are two large code bases for rendering HTML content: WebKit (and its forks) and Gecko. Gecko is the engine developed by Mozilla used in Firefox. When Apple decided to make their own browser (Safari) they looked around at the existing code bases. They didn’t want to use Gecko because it wasn’t very modular and had poor performance. Instead, they took KHTML and KJS as a base (developed for KDE on Linux and used in Konqueror) and developed WebKit. When Google decided to get into the browser world they made the same decision for the same reason with Chrome, which was originally built on WebKit and is now built of a WebKit fork called Blink. Opera had their own engine, but they eventually dropped it to use Blink as well (through a customized version of Chrome). Android’s WebView, which is used by apps to render HTML, is based on Blink.

When people fork WebKit, usually the part they change the most is the JavaScript engine component. This is where most of the speed benefits of various browser updates come from.

  1. @captainepoch is correct; on iOS all browsers must use the iOS WebKit rendering engine. This doesn’t make Google and Mozilla very happy, but they don’t have very many options, so they have gone along with it so far.

  2. Because there aren’t enough WebKit implementations (https://xkcd.com/927/), I intend to create a fork of Android’s WebView called Privacy WebView (https://www.stoutner.com/category/roadmap/) to go along with Privacy Browser (https://f-droid.org/repository/browse/?fdfilter=privacy+browser&fdid=com.stoutner.privacybrowser.standard). When I do, it will be a fork of Blink, which is a fork of WebKit, which is a fork of KHTML. :grin:


I suppose that the decision of Apple and Google of chose webkit instead of Gecko can also be motivated by the type of licence, because BSD licence seams a bit less copyleft than MPL.


Thanks @sorenstoutner for this detailed history.
However I’m also wondering what are the differences in terms of privacy / security:

  • between AOSP and Google webview: AOSP webview has to be updated through an update of the firmware while Google webview can be updated as a regular app.
    What are the other differences ? Like Chromium and Chrome I guess there are additional proprietary code into Google’s one. Is Google adding more security patches into his own version?
  • Is Google able to monitor the web trafic while using a browser based on AOSP/Google Webview?

Looking forward to your privacy webview :slight_smile:


Yes, I am sure that licensing figured into the decision as well.

KHTML and KJS are licensed under the LGPL. https://en.wikipedia.org/wiki/KHTML

That allowed Apple to build WebKit around those components with any license they wanted. The original parts based on KHTML and KJS, called WebCore and JavaScriptCore in WebKit, are still licensed under the LGPL. The new sections developed by Apple were originally closed source, but were open sourced by Apple in 2005 under a BSD license. https://en.wikipedia.org/wiki/WebKit#Open-sourcing

Blink is also licensed under a mixture of the 3-clause BSD license and the LGPL. https://en.wikipedia.org/wiki/Blink_(web_engine)

At the time Apple (and later Google) made the decision to create their own browsers, I remember reading articles where they said one of the major reasons for going the KHTML/WebKit route was the modularity of the code as compared with Gecko (which allowed for better performance on wimpy devices like the cell phones of the day). However, I am not able to put my finger on any of the links to those articles right now. Some things really do get buried on the internet if enough time passes. (Note that Mozilla has made a lot of effort to improve the Gecko codebase, especially in light of the speed wars that Chrome launched, so it isn’t as bad as it was when Apple and Google made their original decisions).

  1. There is no difference between AOSP and Google’s WebView. Originally Google only updated WebView with new Android releases. Because of the sorry state of Android updates on most devices, that meant that almost everyone was running outdated, vulnerable versions of WebView. https://arstechnica.com/security/2015/01/google-wont-fix-bug-hitting-60-percent-of-android-phones/ From the beginning of Android, WebView was built on WebKit, but prior to Android 4.4, the WebView code was built on a different code base than that used by Chromium (it didn’t get updated as much). Beginning in Android 4.4, Android’s WebView started being built from the same code base as Chromium (which had already transitioned to Blink). Beginning with Android 5.0, Google redesigned the underlying code structure so that WebView could be updated either by an OS upgrade or through an app update on the Play Store. This allowed them to push WebView security updates to devices that weren’t receiving OS updates. Basically, the AOSP WebView code is updated every month or so, that portion is built into an APK, and it is pushed out to all devices running Android 5.0 through the Play Store. https://arstechnica.com/gadgets/2014/11/android-5-0-lollipop-thoroughly-reviewed/#h1 The code can be found at https://android.googlesource.com/ and the instructions for building WebView are at https://www.chromium.org/developers/how-tos/build-instructions-android-webview

  2. Google, being the semi-punks they are, does monitor by default all traffic from any app that uses WebView. This general monitoring can be disabled by adding <meta-data android:name="android.webkit.WebView.MetricsOptOut" android:value="true" /> to the AndroidManifest.xml file. https://developer.android.com/reference/android/webkit/WebView.html They also do other things to make it easy for the internet to track WebView usage, even if the above opt-out is included. For example, WebView abuses the X-Requested-With header to send the application ID (eg. com.stoutner.privacybrowser.standard) to every website visited by an app running WebView and makes it difficult to completely remove this functionality. https://redmine.stoutner.com/issues/37 It is reasons like this that I am eventually planning to fork WebView to get something that respects the user’s privacy better.


@sorenstoutner btw do you have why blocking Android WebView with a firewall (AFWall+ for instance) doesn’t prevent apps from loading web content?
I tested the About screen of K-9 mail and the pages are loaded.


That’s because the app runs WebView in its own context → all permissions
from the app.


Is it related to the ‘Full network access’ permission?
So I guess we can’t do anything against these connections, can we?


That traffic outcomes from the calling app. If you want to block it, you
need to block K-9, which I’m sure not what you want.


@Primokorn, depending on the complexity of your firewall, you could block all outbound traffic from K-9 mail with a destination port of 80 or 443. This would also block HTML emails from loading external images (K-9 Mail uses WebView to render HTML emails). If only ports 80 and 443 are blocked, K-9 Mail will still be able to get and send emails, which happens on different ports.

I’m curious: are you trying to block WebView as an exercise in understanding how it works or do you have concerns about K-9 Mail loading the About pages?


My firewall (AFWall+) uses iptables and I can create scripts for this situation. However preventing the app using these ports block displaying web content from reliable emails.

Actually I always try to learn how things are working on my device and I also want to reduce as much as possible the quantity of data sent to Google.
Thanks to your inputs I have a better comprehension. It’s pretty hard to find relevant information on the subject.