The current state of the LineageOS-based /e/ ROM

The current state of the LineageOS-based /e/ ROM

Published:
Author: · 7 min read
#android   #rom   #lineageos   #e-foundation

In March 2019, we checked the LineageOS-based ROM provided by the French /e/ foundation. In this article, we look at the /e/ Android ROM again to check whether issues identified by us are still present.

Contents

  1. Preparation
  2. Features
  3. Security, and privacy
  4. Summary
  5. Links

Always stay in the loop!
Subscribe to our RSS/Atom feeds.

Preparation

Like last time, we wiped our Moto G4. Then, we installed a fresh copy of /e/ using adb sideload. Initially, we skipped most configuration. We only set the local time. The setup asks you to optionally register for an /e/ account. We didn’t do this.

After initial configuration, we connected the Moto G4 with a dedicated VLAN to monitor its complete network traffic.

Features

Before we analyze the network traffic, we look at features of /e/ like last time. The current ROM for the Moto G4 (build date August 3, 2019) is based on Android 7.1.2 like last time (Android 7.1.2 is still officially supported by Google). The Android security patch level is July 5, 2019, according to the settings. So it is the latest patch level for Android.

Preinstalled apps are among others:

  • Apps (/e/ app store)
  • Bliss Launcher
  • Chromium-based /e/ web browser
  • LibreOffice Viewer
  • Magic Earth (maps client)
  • K-9 Mail-based mail client
  • microG Services Core
  • MuPDF mini (PDF viewer)
  • Notes
  • Open Camera
  • OpenKeychain (OpenPGP client)
  • OpenTasks
  • QKSMS (SMS messenger, branded as foundation.e.message)
  • Weather client
  • several apps included in LOS/Android (Clock, Contacts etc.)

Obviously, they removed Signal and Telegram, and added their own Apps store.

Security, and privacy

Since this article also isn’t focused on features of /e/, we again look at security and privacy aspects. The /e/ Foundation promotes their same-named mobile OS as “ungoogled”, coming with “carefully selected apps”.

Communication with the internet

In this section, we discuss several findings regarding /e/’s network traffic when connected to the internet.

Hello Google, you are still there

Last time, we saw that /e/ connected to Google servers for its connectivity check. This time, we see exactly the same behavior:

1
2
3
4
5

GET /generate_204 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
Host: connectivitycheck.gstatic.com
Connection: Keep-Alive
Accept-Encoding: gzip

Our G4 connects to 172.217.18.99, a Google server. There is a new issue (#268) on /e/’s GitLab instance. Seemingly, they try to set up their own server for connectivity checks to get rid off Google here.

Last time, other users reported that /e/ used Google’s DNS servers (e.g., 8.8.8.8) by default. We weren’t able to reproduce this, and mentioned this in our last report. /e/ closed the related ticket #269, and stated “This is not true […] The conclusion was that 8.8.8.8 and 2000:: are only used in Bionic to figure out if some IPv4 or IPv6 is available.”

Besides, there is still network traffic from/to www.gstatic.com, clientservices.googleapis.com and www.google.com via IPv4. This is tracked by issue #271. Issue #271 is still open and there are no relevant comments.

NTP synchronization around the world

This finding didn’t change at all. See our last report.

The related issue #272 on /e/’s GitLab instance states: “This is something probably not extremely challenging in term of user’s data privacy protection and at least it doesn’t go to Google. Actually maybe we should sort out the list of NTP servers and keep only ‘trusted ones’, if this exists. And/or add some /e/ NTP servers.”

Weather app still leaks personal data in cleartext

Last time, the preinstalled weather app (foundation.e.weather, version 4.4) leaked our location in real-time. Each time, we searched for a location to get the current weather, the app sent a GET request to api.openweathermap.org in cleartext. One example was GET /data/2.5/find?q=lin&type=like&cnt=15&APPID=50[…]8 HTTP/1.1. If we used the device’s GPS to get weather information, it leaked our current position.

The weather app still leaks data like your location in cleartext. Obviously, /e/ didn’t add HTTPS to encrypt data in transit. However, they seemingly changed the user agent to okhttp/3.2.0. Last time, it was Dalvik/2.1.0 (Linux; U; Android 7.1.2; Moto G4 Build/NJH47F), leaking device information. This is interesting since the version number didn’t change.

The related issue #273 on /e/’s GitLab instance states: “The weather app will be improved, to use HTTPS and remove user-agent. […]“. The issue is still open. The problem of leaking data is still present.

Magic Earth–again cleartext traffic

We checked Magic Earth (com.generalmagic.magicearth, version 7.1.19.20…) again. Last time, we identified that the app talked to 12 different IP addresses owned by General Magic. Ten times the communication was in cleartext only.

This time, we experienced the same behavior. It is still unclear why only some traffic is encrypted.

The related issue #274 on /e/’s GitLab instance states: “MagicEarth provided us a quite comprehensive document regarding privacy, and we are working with them to improve this aspect. We will discuss with them the issue with unencrypted traffic.” So there is no update here.

The App store of /e/

In March, there was no app store installed by default. This time, /e/ ships their own app store “Apps” (foundation.e.apps, version 1.1.5).

The app allows you to request new apps, search for apps and also games, and you can download/install apps, of course. /e/ seemingly offers a broad mix of apps, contrary to F-Droid. So you also find apps like “SWAT and Zombies - Defense & Battle” that contain ads and trackers. Some people probably don’t like this, however, there is a chance to get rid off third-party stores to access Google’s infrastructure (like Aurora Store).

We checked for version information of 10 random apps for comparison:

Name/e/ versionGoogle Play version
Conversations2.5.3+fcr2.5.5+pcr
Firefox Klar8.0.15device dependent
Keybase4.0.14.2.0
Orfox¹52.9.0esr52.9.0esr
Protonmail1.11.41.11.4
Signal4.43.84.44.7
Steam Chat0.90.9
Telegram5.7.1device dependent
VLC3.1.7device dependent
WhatsApp2.19.188device dependent

So some apps are slightly older than on Google Play. ¹Note that Orfox is totally outdated and insecure. Don’t use it. We don’t know why they added this app to their app store.

Using the Apps store results in traffic to/from “cleanapk.org”. We don’t know who operates this domain. The device downloaded two certificates (api.cleanapk.org and apk.cleanapk.org). Most communication was TLS 1.2 encrypted. It would be nice to get some information about “cleanapk.com”. Maybe, this domain is operated by /e/ for their app store.

/e/ Foundation website

Last time, we also identified some issues with the website of /e/. For instance, their versions of WordPress and WooCommerce were outdated and contained publicly-known security vulnerabilities.

We checked their main website e.foundation again. This time, it runs WordPress 5.2.2 (the current version) and WooCommerce 3.6.5 (the current version). The server itself runs Apache 2.4.29 on Ubuntu 18.04 LTS (last time, it ran Apache 2.4.10 on Debian 8). Looking only at version numbers, this was clearly improved by /e/.

However, nearly all modern security-related HTTP response headers like Content Security Policy are still not set. The website still supports outdated TLS 1.0 and 1.1 protocols, but dropped support for old DES-based cipher suites. So there was only minor improvement here. We think that securing their website should take top priority, especially due to 165 JavaScript files embedded on their main page. There is also some third-party content embedded, hosted on “cdn.jsdelivr.net” and “stackpath.bootstrapcdn.com”.

Interestingly, the Google font is gone now. Last time, /e/ stated that removing the font hosted by Google isn’t important for them since their promise regarding being Google-free doesn’t include their website. The related issue #275 talks about issues with the CMS, and it is still open.

Summary

Compared with our last report, the overall situation is slightly improved. Their website is based on up-to-date software now, and they removed the Google font. Additionally, they seemingly masked the user agent of the Weather app. Most other findings are still unaddressed, though.

The new app store is a chance to completely get rid off of Google Play, however, we don’t know about the relationship with “cleanapk.com”, and how they ship their apps (e.g., who builds and signs the apps?).

As before, /e/ looks promising, it isn’t Google-free by now.

See also