Leaving Apple & Google: How is /e/ actually Google-free?

Yesterday, the privacy-focused /e/ mobile ecosystem that we have been developing for one year, has been covered at InfoSec Handbook, with a focus on privacy concerns and on the actual “de-googlisation” of the system.

The author raised some concerns, and concluded that “While /e/ looks promising, it isn’t Google-free by now.”

Great!

I’m very pleased that some security and privacy experts are starting to have a close look at /e/, and are challenging what we are doing: it’s extremely useful for us to learn about how the project is considered by experts. It’s also super-helpful because, it’s raising the bar of expectations and therefore encouraging us to do better and to improve the product.

However, I felt that, even if /e/ is still beta software and therefore not perfect yet, it was important to answer some of the concerns raised in this article, and to elaborate about our status, goals & roadmap.

Claims & concerns answered

Let’s go:

“Its members must pay an annual fee.””

While I’m not certain about what the author means here, it’s important for me to remind that:

• /e/ is an open-source project, in the public internet, which is backed by a non-profit organization
• as an open-source project, all the source code used in the /e/ operating system (which is forked from AOSP/LineageOS) and used in /e/’s core online services is available publicly
• anyone can download /e/ builds (currently available for about 60 different smartphones) and /e/’s source code, and is free to install or compile the ROM

“In summary, installing /e/ is as easy as installing LineageOS. You do not need an /e/ account as stated in their requirements.”

There is no such requirement of using an /e/ account to install the ROM on our website:

“Optionnal: It is recommended that you have an /e/ account (like: john.doe@e.email) if you want to benefit from /e/ account integration for all online services such as: email, drive, calendar, notes, tasks. In order to get a test /e/ account, please read instructions here.”

“However, some people may not like Signal and Telegram preinstalled on their phone regardless of whether they use it.”

Absolutely. And that’s the reason why:

1. we will soon add a new feature that will let users uninstall most default (preinstalled) application from /e/
2. next summer we will introduce different user profiles during the installation, that will impact the choice of default applications

“We monitored all data connections of /e/ after restarting the phone. First of all, /e/ knocks on Google’s door by using its connectivity check:”

As it’s stated next in the article, this issue was reported on our Gitlab (#146), along with DNS issues.

Of course, this is something that we want to fix before we release /e/ v1.0.

“Other users report that /e/ uses Google’s DNS servers (e.g. 8.8.8.8) by default.”

This is not true: we have done a comprehensive review of the source code, and in particular of Bionic, the Android’s custom libc.

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.

Otherwise, DNS servers are set by the network’s provider using DHCP and could only be enforced using WiFi access.

So we have developed and recently introduced a feature to let users enforce their DNS settings if they wish so:

“The settings allow you to set a default DNS resolver (Settings → Wireless & networks → More → DNS → disable “Use network DNS” → Set DNS to use). We tried this but the router enforces the DNS resolver of the network.”

It’s working though, unless we have a bug somewhere, or unless the router is rewriting DNS requests. We will check again to ensure that this new feature is working as expected.

“Moreover, there is TLS 1.2-encrypted traffic from/to www.google.com, gstaticadssl.l.google.com, googleadapis.l.google.com, and www3.l.google.com via IPv4/IPv6.”

Thanks for reporting this, we will have a look, it needs to be fixed.

“NTP synchronization results in many different domain names that learn about your IP address”

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.

“In summary, the weather app leaks your IP address, the identity of your device, and maybe your location (city name, GPS coordinates). All is sent in cleartext.”

The weather app will be improved, to use HTTPS and remove user-agent. However, it’s clear that it will keep on sending GPS coordinates to OpenWeatherMaps (this is not Google byt the way). Otherwise, there can’t be a weather service based on current location.

Note that sending geolocation can be disabled in settings:

“So, it remains unclear what kind of information is sent/received to/from General Magic in cleartext.”

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.

Regarding e Foundation websites

We are aware of several issues with some of the CMS we’re using on our websites, in particular with Wordpress.

What’s important to understand here is that the promise of the /e/ project is to provide an mobile ecosystem, ROM + basic online services, that are much more respectful of user’s data privacy. And the first step for this is to “un-google” as much as possible.

Therefore, we are focusing on the product:

• the /e/ ROM
• /e/ online services: drive, calendar, notes, tasks, email, meta search engine (and soon: Android application repository)

The main issues we have is with the CMS that we are using (Wordpress) for e.foundation, because it’s unsure that they really care about data privacy. So even if this aspect is out of the project scope in term of promise, if this is not improving, we will probably move to another CMS.

“We already reached out to /e/ Foundation regarding their usage of Google fonts in January, however, we didn’t get an answer so far.”

This is linked with the previous point, and it was discussed publicly.

Please also note that we have a Privacy Policy available online, though probably not perfect, it’s intended to inform users about what we are using on our website.

Conclusion

We think that if /e/ is not perfect yet in term of user’s data privacy protection, we are on the good way. Of course we will continue to work hard to make it still better and better. And probably that /e/ is already the most advanced general-purpose mobile ecosystem in term of “ungooglisation” and in term of protection user’s data privacy protection:

• no Google search is used
• no Google Apps are used
• /e/ is close to send 0 data to Google
• /e/ provides replacements to all basic online services (drive, mail…)

We will list all the remaining concerns on our website, so that users know about the current status.

However, I’d like to thank you again InfoSec Handbook and the author of the article for the comprehensive review and the very valuable feedback about /e/.

Sincerely yours,

Gaël Duval, /e/ Founder.

Follow me on Twitter / on Mastodon

PS readers might be interested in learning more about /e/:

The three founding articles:

• Leaving Apple and Google : my “eelo odyssey” — Introduction
• Leaving Apple and Google: my “eelo odyssey” — Part1: the mobile OS
• Leaving Apple and Google: my “eelo odyssey.” Part 2: Web Services

And also:

• /e/ is more than tech, it’s a societal project for freedom and democracy
• /e/ first beta announcement and description

Leaving Apple & Google: How is /e/ actually Google-free? was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.