Replicant

FWIW, I've been happily using llvmpipe for about 2 weeks based on Wolfgang's instructions for Replicant 6.0. It's definitely less snappy, but I'm okay with the extra lag in return for the improved security of using Orfox. Would it be feasible to release an alternate Replicant 6.0 build with a current WebView, for the users like me who are okay with llvmpipe's current state?

It is my understanding that newer versions of webview currently can't be used because they don't work with the software rendering.

FWIW, I've been happily using llvmpipe for about 2 weeks based on Wolfgang's instructions for Replicant 6.0. It's definitely less snappy, but I'm okay with the extra lag in return for the improved security of using Orfox.

This is great to hear that llvmpipe in its current state is already usable for you!

Newer versions of the webview do indeed work with llvmpipe, at least they should. Latest versions may still introduce issues but these seem to get fixed by the Mesa or Android-x86 developers over time.

Please note that the apk is not built as part of a regular Replicant build. The apk needs to be built separately in a chromium build environment and only the final apk is committed to the source code. The apk can be installed with adb install -r webview.apk, just like a normal app. So there is no need for a completely separate Replicant build, just because of one apk file.

I didn't look into the loader code for the webview, so I don't know if it's possible to switch between the two in a similar way like with llvmpipe and the Android software renderer. At least it should be possible to additionally ship an updated webview apk as part of a Replicant 6.0 zip. Then it can be manually switched between the two with something like adb shell mv old-webview.apk old-webview.apk.bak && adb shell mv new-webview.apk old-webview.apk

It would be great if we could utilize the script that selects libagl/llvmpipe on a per app basis https://redmine.replicant.us/issues/1844 and somehow configured llvmpipe by default on every app using webview. I don't know how this could be automated.

Here's a suggestions related to how one can visually inspect an app to see if it uses WebView: https://stackoverflow.com/a/19160572

Is this the source code for the most current stable version of Webview? https://chromium.googlesource.com/chromium/src/+/master/android_webview/ If so, like Wolfgang said, the Webview apk needs to be built separately in a chromium build environment, so it'd be good if we could build it ourselves.

These instructions reference Android 5.0.0 so it might be old https://www.chromium.org/developers/how-tos/build-instructions-android-webview

The old version of WebView that we use doesn't have TLS 1.2 GCM ciphersuites: https://redmine.replicant.us/issues/1949

This is yet another reason why we need to update WebView.

Debian, Guix, Bromite, Iridium, Inox, ungoogled-chromium, Iridium, and Vanadium all seem to have their own versions of WebView.

I took a look at all the Chromium forks mentioned above, except for Vanadium, which I couldn't find.

After looking at the manifestos and design principles for all of them, ungoogle-chromium seemed to be more aligned with software freedom.

Then I found out that Guix (a FSDG compliant distro) distributes ungoogled-chromium after running it through a build recipe that removes a few extra files.

On Guix mailing list there is the following bold statement:

To the best of our knowledge, ungoogled-chromium as packaged in guix is completely free

I would say this is our best bet and we should try to build WebView after Guix build recipe for ungoogled-chromium.

• Bromite - Quite interesting for the fact that the codebase is used to build WebView. Focused on privacy and ad blocking, not on software freedom.
• Debian - Limited patch set that strives to use system libs instead of binaries but does not go as deep as ungoogled-chromium when it comes to removing Google services.
• Iridium - Tries a step on every direction. Isn't as thorough as ungoogled-chromium about ungoogling and doesn't seem to replace built-in binaries for system libs.

Edit: the proprietary codecs that Bromite brings are stuff like h264, mp3 or mp4. Which may be under some patent in some crazy legislation, but there is a free software implementation for it (which is actually distributed on FSDG distros like Parabola). Thus no issue there.

There is an ungoogled-chromium fork focused on bringing it to Android: ungoogled-chromium-android

The main dev reports success on building the WebView apk with it.

1. grab ungoogled-chromium-android
2. pass it through the Guix "filters" for ungoogled-chromium
3. make it output a WebView apk.

1. ungoogled-chromium-android targets API 24. Replicant 6 is API 23.
2. How should we re-create what Guix did on top of ungoogled-chromium?

Unobtainium 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. We are looking to know whether some Unobtainium patches could still be applied on top of ungoogled-chromium-android.

1. Start off with ungoogled-chromium-android.
2. Try to make it work with API 23.
3. Remove the remaining prebuilts while taking inspiration from Unobtainium.
4. Check if any remaining Unobtainium patches still apply on top of ungoogled-chromium-android.
5. Check if the third-party files filtered out by Guix are still in ungoogled-chromium-android at this stage.
6. Try to build everything from fdroid-server like Unobtainium does. It's a great way to pick leftover prebuilts.
7. Gather all the devs involved, write a paper, make a few slides, submit to a relevant free-software conference. From there shout out loud to the entire world how fucked up Chromium is.

Both ungoogled-chromium-android and Unobtainium devs are willing to help. Coordinate with them.

The Parabola team does not deem Guix approach to be acceptable because it hasn't been presented to the FSDG work-group for evaluation. The current recommendation for Chromium is still to: Remove program/package

Note that the above is a recommendation. Replicant may decide otherwise, but in that event we would have to prove why our approach works and we should share it with all other FSDG distros.

Addition: Guix developers did present something, their guile code for the package. I'm trying to understand why it is not enough.

Guix developers stand by their approach, and reply that all freedom related issues pointed onto their version of ungoogled-chromium have been solved.

After a long review of most email threads on GNU-linux-libre that address the Chromium subject, with special focus on the latest thread that spun up when Guix added their build of ungoogled-chromium. I, Andrés D and Kurtis Hanna concluded that Guix's approach is reasonable. Guix devs actually posted a plain English description for it with all subsequent rebuttals being suspicions and not actual findings of non-free content.

1. Start off with Guix's source code for ungoogled-chromium, i.e. after being cleaned by their build script.
2. Run Ubuntu license check script on top of it.
3. Check if any "BlockedOn" issue from the original Chromium bug 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. Make it work with API 23.
7. Try to build everything from fdroid-server like Unobtainium does. It's a great way to pick leftover prebuilts.
8. Send recipe to be peer-reviewed at GNU-linux-libre, written in plain English, and explaining how it addresses Luke's concerns.

My understanding of the discussion related to this on IRC was that, for our 6.0 0004 release, we will build and provide an up to date version of webview using ungoogled-chromium's tree after running it through a Guix build recipe that removes a few extra files.

I think that once webview is built and the apk is integrated into our build system we will be ready to release 6.0 0004.

While not directly related to this ticket, I think it was decided in Replicant 9 webview will be removed until we can find a way to use gecko instead of chromium as the underlying engine, but still keep feature parity with the webview API.

Please correct me if this is wrong.

Hi Kurtis,

I think you are wrong.

1. Release Replicant 6 0004 with the old WebView, alongside with a warning stating it's security holes. This warning should advise people to use a Gecko based browser such as Fennec F-Droid, which although slow, will now work on 0004 due to the usage of llvmpipe software renderer. The old WebView should only be used on apps that render trusted content.
2. Replicant 9 will be released without WebView only if there is neither: a) a liberated WebView or b) a shim that envelops GeckoView and makes it API-compatible with WebView (the Upstream page has more details on this).

IMHO the GeckoView shim, although much better, is not accomplishable in due time even for Replicant 9 (unless some new contributor appears, or someone from Mozilla steps in). We must thus strive to complete the WebView/Chromium liberation approach suggested above in time for the Replicant 9 release. It seems to be our best hope.

Another possible approach for Replicant 9, would be releasing it without WebView, and 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.

The quick and dirty approach to update webview in Replicant 6 is to:

1) grab ungoogled-chromium-android
2) make it compatible with API 23
3) compile

The reason why ungoogled-chromium-android is not compatible with API 23 was described by the author here: https://github.com/wchen342/ungoogled-chromium-android/issues/7#issuecomment-545561123

I just removed the default webview in Replicant 6 and replaced it with the system webview build I found here: https://git.droidware.info/wchen342/ungoogled-chromium-android

It seems to be working perfectly. Are there any freedom issues with this build, or can we include it in Replicant 6 and the upcoming Replicant based on mainline?

edit: I'm currently running version 90.0.4430.212. Here's their non-git based website about system webview: https://uc.droidware.info/system_web_view.html

I just asked the developer if there are still nonfree binaries that they know are required to build their version of webview: https://github.com/ungoogled-software/ungoogled-chromium-android/issues/90

Guix still does lots of cleaning on top of ungoogled-chromium: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/chromium.scm#n357
As such, I bet that it still has plenty of blobs ending up in the WebView build.

I am the maintainer of ungoogled-chromium-android. I just discovered this discussion following the issue opened by Kurtis Hanna. So I think I can explain and make things a little clearer:

1. The remaining binary blobs for building android version are mainly two types: pre-built jar files and other data files/tools. For the jar files, most of them can be built from source since I cleared out all the Google Play/Firebase related ones. However, there are ~50 jars and and the reason I do not build them from source is that it is hard for me to track them all between updates, since UC needs to be updated with current stable version. For the binary files, most of them are for ICU. There is one special piece that is a customized version of aapt2. I do not know whether it is possible to substitute that one because I tried to use normal aapt2 in SDK but that didn't work.
2. I read the GUIX script linked above. The mentioned section is just running UC scripts for removing binary files/domain substitution. The other scripts are also commonly used in other distributions, for example see this Fedora spec: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/chromium.spec#_1148

If you guys are interested in creating a complete free version of webview over uc-android, I will suggest open a separate branch in the repo or start a fork somewhere, so that we can cooperate on removing the rest of the blobs. Unfortunately I cannot lead this effort because I do have other works to finish, but I will be happy to help and give suggestions.