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!
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.
- 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.
@anon36515525 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.
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.
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
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
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).
@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.