Session:The chromium mess meets Android

From 36C3 Wiki
Description WebView is one of the core components of the Android system, used and abused by apps to render web content (HTML, CSS, JS). WebView is nowadays built out of the Chromium source tree which has been plagued by privacy and freedom issues. As a fully free-software Android distribution, Replicant is exploring different paths to create a WebView build that respects user's privacy and freedom. Our tentative approaches go all the way from further cleaning the Chromium source after projects like ungoogled-chromium, to fully replacing WebView by a shim built around GeckoView. We will present our approaches on this lightning talk, on the hopes of getting feedback from the community and engaging other projects to collaborate with us.
Type Discussion
Kids session No
Keyword(s) software, web, coding, security, safety
Tags Android, Chromium, Chrome, privacy, adblock, webview, ungoogled, gecko
Processing assembly Assembly:Replicant
Person organizing Dllud, JeremyRand
Language en - English
en - English
Related to Projects:Replicant
Other sessions... ... further results

(Click here to refresh this page.)

Subtitle Proposals on how to get a fully free WebView build or replace it with something completely new
Starts at 2019/12/29 21:00
Ends at 2019/12/29 21:30
Duration 30 minutes
Location Room:Lecture room M1

The Chromium mess meets Android

Proposals on how to get a fully free WebView build or replace it by something completely new.

What is WebView?

The WebView API[1] has been around since the first version of Android. It allows developers to render web content (HTML, CSS, JavaScript) inside their applications. It's use was at first limited to apps that needed to show bits of HTML, such as email clients and RSS readers. However it's use has become much more pervasive with the advent of cross-platform mobile frameworks such as Cordova, Xamarin and React Native, that render most of the apps' content inside WebView. A quick run through the apps listed at PRISM Break[2] showed that almost half on them depend on WebView.

WebView was at first built out of the WebKit code tree, but it switched to a Chromium based build from Android 4.4 (KitKat) onwards[3]. As the years go by, Chromium has proved to be a minefield of privacy[4] and freedom issues[5][6] and thus unfit for inclusion[7] in distributions that abide by the Free System Distribution Guidelines (FSDG)[8].

Webview and Replicant

Replicant[9], a fully free-software Android distribution that follows the FSDG, has been using an outdated build of WebView, based on Chromium 43, back from when the Chromium Android build did not depend on proprietary libraries. This outdated version is becoming a severe security hazard[10] and must be replaced soon. Unfortunately this means that Replicant is now left with the burden of creating a WebView build that respects user's privacy and freedom. We have been exploring different paths to do so, that go all the way from further cleaning the Chromium source after projects like ungoogled-chromium-android[11], to fully replacing WebView by a shim built around GeckoView[12].

Approach 1: Chromium forks

At first, we reviewed the several ongoing projects that strive to clean the Chromium mess:

  • ungoogle-chromium seemed to be aligned with both privacy and software freedom[4].
  • Bromite is quite interesting for the fact that the codebase is used to build WebView[13]. However it is only focused on privacy and ad blocking, not on software freedom.
  • Debian has a limited patch set that strives to use system libs instead of binaries[14] but does not go as deep as ungoogled-chromium when it comes to removing Google services[15].
  • Iridium tries a step on every direction[16]. It isn't as thorough as ungoogled-chromium about ungoogling and doesn't seem to replace built-in binaries for system libs.

We then found out that Guix, a FSDG compliant distro, claims a good measure of success[17][18][19] with an approach based on ungoogled-chromium. They run it through a build recipe that removes a few extra files[20].

Both the upstream ungoogled-chromium as well as the Guix recipe target desktop builds of Chromium. Unfortunately a build for Android requires many more prebuilts and proprietary dependencies such as the Google Mobile Services (GMS)[21]. On the bright side, there are projects that strive to get clean Chromium builds for Android too:

  • ungoogled-chromium-android[11] builds upon ungoogled-chromium with Android specific patches and fixes. It even provides a F-Droid repository with a WebView build[22]. Unfortunately, supporting Android meant adding prebuilts that could no yet be removed[23].
  • Unobtainium[24] is a project that, besides removing Google services and libraries from Chromium, also tried to get rid of all prebuilts. The goal was to be built from within F-Droid. Unfortunately the project has been dormant for an year now, while Chromium advanced full speed ahead.

Fully free WebView apk with existing Chromium forks

So far no project could yet produce a WebView apk that is 100% free software and void of privacy concerns. At Replicant we devised the following path that builds upon these projects and could potentially lead to an acceptable WebView apk:

  1. Start off with Guix's source code for ungoogled-chromium, i.e. after being cleaned by their build recipe.
  2. Run Ubuntu license check script on top of it.
  3. Check if any "BlockedOn" issue from the original Chromium bug[5] still applies (hint: most of them should be related to third-party code that was removed).
  4. Try to build WebView out of it (will probably fail).
  5. Cherry pick all the necessary patches from ungoogled-chromium-android and Unobtainium.
  6. Try to build everything from fdroid-server like Unobtainium does. It's a great way to pick leftover prebuilts.
  7. Send recipe to be peer-reviewed at GNU-linux-libre, written in plain English, and explaining how it addresses Luke's concerns[6].

Approach 2: WebView API compatibility shim for GeckoView

Despite sensible and achievable, this previous approach would be met with a constant maintenance burden, as the Chromium tree evolves and more proprietary dependencies or privacy issues get added. Our major issue is that Google's interests do not seem aligned with ours. As such, we turned our attention to GeckoView[25][26], as Mozilla's interests seem much more aligned with us.

GeckoView is Java wrapper for the Gecko browser engine that turns it into a reusable Android library. It can be used by Android apps as a substitute of WebView, but unfortunately it has an incompatible API that wasn't meant to be a drop-in replacement. As such, we analyzed the possibility of creating a shim to bridge GeckoView and WebView APIs:

  • Some functions have a 1:1 mapping, e.g.:
WebView.goBack() and WebView.goForward() > GeckoSession.NavigationDelegate
WebView.loadUrl() > GeckoSession.loadUri()
WebView.stopLoading() > GeckoSession.stop()
  • Others would require emulation, e.g.:
WebView.getTitle() > GeckoSession.HistoryDelegate.HistoryItem.getTitle()

(iterate the list to get the most recent one)

WebView.pageDown() > PanZoomController.scrollBy(width,height)
  • Others are nowhere to be found in GeckoView and would require modifications to it in order to expose more features from Gecko, e.g.: WebView.zoomIn()
  • Others still, which have been added to WebView on the latest APIs (26-29) are too tied to Chromium, and perhaps the best option would be simply to not support those, e.g.:
WebView.getWebViewClient(), WebView.getWebViewLooper(), WebView.getWebChromeClient()

The conclusion is that, as is, making GeckoView compatible with the WebView API would require a considerable effort. However, the end result has the potential to require much less maintenance: we wouldn't have to constantly scout the Gecko source for proprietary dependencies and privacy issues.

The burden of this effort could also be lessened by trying to involve other FSDG compliant distros as well as the KDE Free Qt Foundation. qt5-webengine, one of the components of Qt, uses Chromium underneath and is currently embargoed from FSDG compliant distros due to the same privacy and freedom concerns. Perhaps some of this work could be shared with them in order to build a qt5-webengine replacement with Gecko underneath.

Approach 3: replace WebView for GeckoView on apps themselves

Another possible approach would be to fork the most important apps that depend on WebView to use GeckoView instead. This approach would be almost madness as too many apps depend on WebView. It would be impossible for the small Replicant team to maintain this. It would only work if the app maintainers themselves perceive GeckoView as a better alternative and start using it upstream.

Feedback welcomed

Comments, ideas and specially collaborations are much welcomed.




























Archived page - Impressum/Datenschutz