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.”
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.
“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:
“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: [email protected]) 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:
“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. 184.108.40.206) 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.
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.
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 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.
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:
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/.
Gaël Duval, /e/ Founder.
PS readers might be interested in learning more about /e/:
The three founding articles:
Create your free account to unlock your custom reading experience.