My /e/ exit interview

I’ve used /e/ for at least a couple years now. I begin shopping for new phones tomorrow, which I will not be flashing /e/ to. /e/ does fit my threat model and phone usage perfectly, and the /e/ team, both official and “amateur” has been wonderful, quick and responsive.

My reason for leaving is because living in Hong Kong, I am on occasion required to use badly-made apps. I was unable to get the quarantine app working on any of my family’s 3 /e/ phones after 3 days of spending all of my energy working on the problem, in spite of lots of help here on the forum. This problem cannot be allowed to happen again, as we were able to function only because we chanced into a non-/e/ phone a month ago. The next app I’m required by my son’s school, or the govt here, or whoever, to use may run into a similar problem. So I need to set up as much reversible security and privacy as I can on stock android, rather than on a non-reversible (unable to return to factory settings easily) OS like /e/. So I will no longer be using /e/ as my primary driver.

How /e/ failed me:
The failure is my own, rather than with the OS itself. Specifically in two areas: PC and know-how. For the last few years I have allowed my computer PC skills to lapse. After a move several years ago, I no longer used a PC in daily life. Actually the only times I would bring it out of storage were for backups, media transfer, and flashing /e/. If I had kept a PC up to date, used a PC in daily life and kept my own skills sharp, basic tasks like abd would be both easier and could be done in the background while working on other tasks.

Phone-only OTA /e/ installation, and being able to restore factory settings from the phone, would make the difference for me. I think that both of these are not possible, but there it is.

I wish I could continue using /e/. I will do basic OTA on my family’s old /e/ phones, and try to keep up with the project - I really like how it took care of much of the security and privacy concerns for me, and the community here is amazing. Definitely a bittersweet parting on my part.

AMA? If there’s anything you’d like to know, I’m happy to answer.

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone



/e/ does fit my threat model and phone usage perfectly
I really like how it took care of much of the security and privacy concerns for me

We’re you aware the WebView/Browser hadn’t been updated in 8 months and has 273 known security issues, including 6 of which were marked as zero-days by Google?
I track this here:

Furthermore the PDF viewer uses a library not updated since January 2016 and too has 55+ known security issues:

Am genuinely curious how someone knowing that can accept it into any threat model.

Feel free to ignore me, I won’t mind. :slight_smile:


I was aware of issues like that, in a general sense. My threat model is less concerned about an individual hacker’s attacks, and more concerned with avoiding broadcasting information to google and governments. If governments really want to track my activities, they will find a way to do so, but I see no good reason to provide them with a huge database on me that they can casually access. /e/ attempts, and refines its attempts, to keep a phone from constantly sending out info, while retaining access to almost all free Android apps. Now I have to do the hard work myself, to try to shut down the many information leaks on a new stock Android phone - and I don’t think I’ll be able to plug as many leaks on my own as /e/ did for me.


Why don’t you contribute to /e/ then and fix those obvious security flaws, if you don’t mind my asking?


I already maintain dozens of other FOSS projects completely on my free time at a complete monetary loss and at the end of the day /e/ is a company actively selling devices/cloud services, it is their responsibility to keep their systems updated for their customers.

They’re welcome to reuse my code under the denoted licenses or reach out to me, but why would I contribute my limited time to a company who has repeatedly shown to not care about blatant security issues like this?

Do you have actual proof for your allegations then? I haven’t seen much yet. The text files you linked aren’t really conclusive concerning the causes and/or nature of the security flaws.

Every single Chromium update says

Android releases contain the same security fixes as their corresponding desktop release, unless otherwise noted.

The changelogs for each update and count of security patches is documented on that table.
The current shipping and historically shipping versions are documented on that table.

That information provided there is enough to dive deeper if necessary.

Not to mention that these Chromium issues are one of many, see the others I note (and source) here:

Take for example the Teracube 2e that /e/OS is currently selling: Murena Teracube 2e - Murena - deGoogled phones and services

Here are the prorprietary vendor blobs that are being shipped with it: proprietary-files.txt · v1-r · e / devices / android_device_teracube_emerald · GitLab

Note the line at the top denoting the version those blobs are from:

Extracted from full_yk673v6_lwg62_64-user 11 RP1A.200720.011 p1k61v164bspP16 release-keys unless pinned

More specifically this part: RP1A.200720
That is this version of Android: 9d2242d67e673ed357812999705a7b91be3a1f58 - platform/build - Git at Google

Note the date:

Wed Jul 29 22:47:56 2020 +0000

Here is the kernel too, note the version it uses: Makefile · v1-r · e / devices / android_kernel_teracube_emerald · GitLab


Here is Linux 4.19.127: Linux 4.19.127 []

Note the date:

Sun, 7 Jun 2020 14:58:56 +0200

Is it really acceptable for /e/OS to be selling devices that are 2+ years behind on kernel and vendor security patches?

Edit: these other devices they’re selling are also end-of-life (only the oem/vendor can provide firmware&vendor security updates)

@SkewedZeppelin your Divestos project gives you lots of merit, it’s great, you have that patchlevel in order where you can control it - but CVE counts drive you mad to the point you can’t put it aside.

The context of @hkmike is rather no matter how well patched his /e/devices would be, he had difficulties running mandatory software in Hong Kong for their Covid schemes and school program. That’s a different problem not addressable by patching to latest levels and the issue is of general concern to all users as in software that is needed to participate (banking/public-admin).


I’m less concerned with their/your/anyone else’s reasons to use or not use any particular OS or software.

I just want users to be informed of the (security) issues that they’re likely unaware of.

(Seriously please don’t take my posts here as shilling my project, my offering is genuinely unsuitable for many here (no gapps/no microg/no drm/etc.). My only goal is truly to push forward security of the community.)


I appreciate that you keep us informed. I also know and have noticed that not all like that. But as the saying goes “Don’t shoot the messenger”…

Also as a sidenote, bromite just released update 108.0.5359.75 via their f-droid repo, possibly bit earlier at github.


Despite their update today they’re still missing today’s security fix: 106.0.5249.163 is missing the recent zero-day fix · Discussion #2421 · bromite/bromite · GitHub

1 Like

Why don’t you postulate here, it will be a real chance to have you in the /e/ team



We’re aware of this. The issue with the the WebView is due to the fact that we had some dev team reorg, and that there is someone else in charge of the Browser build, and it takes some time.
It will be fixed in the coming weeks though.

Same for PDFviewer, it will be updated soon and we’re improving our processes to avoid being trapped in such situations again in the future.

That’s the reason why we need to grow the team, and for this we need more financial support too.

Last but not least @SkewedZeppelin this forum is NOT a place to advertise DivestOS or other projects. This is an /e/OS-related forum, thanks.


Security risks are a dime a dozen. Especially with stock Android. The security risks are by a multiple lower with /e/OS, regardless of the /e/OS version.

Numerous custom ROMs that you provide are an increased security risk. For example, the Google Pixel 3, 3a, 3 XL, 3a XL, 4, 4 XL devices supported by you have not been functional for months, although these devices have received updates every month for months.

Similarly, many other devices from your repertoire are untested, where means that you do not own the devices and leave the sole testing to your community. Nevertheless, they are also updated every month - including their serious bugs.

@SkewedZeppelin, please first sweep in front of your own door before you constantly decry /e/OS here.

1 Like

The security risks are by a multiple lower with /e/OS, regardless of the /e/OS version.

Citation needed, because what I show above directly proves otherwise.

Almost like it is a FOSS project provided without any guarantee or warranty.
Unlike Murena who is actively selling end-of-life devices and cloud services, which Gael didn’t even bother to comment on.

Then what’s the alternative for making a range of degoogled devices accessible for the average user who might not have the expertise to flash their device themselves?

If you don’t mind me asking what projects do you maintain?

1 Like

Another critical question here is, are you more afraid of individual hacker attacks or of gogol asserting world domination?

I myself can live with some security tradeoffs in turn of making a widely accessible gogol alternative :person_shrugging:


OP here. I love all the discussion that is happening in this thread. It helps a dabbler like me learn more about these issues.

I thought you all might be interested with the solutions I’m working on to make my family’s phones as /e/ as possible without /e/, so to speak.

Initial setup with a new phone: avoid installing as much as possible. change privacy settings, following most of the suggeations here: The New Oil
Lawnchair to remove non-removable access to google assistant and search on home screen.
Shelter. Do not allow apps outside shelter to communicate with apps inside shelter, and vice versa. Proton VPN secure core blocking malware, tracking, and ads running in two instances - once in the main phone and one in shelter. Google Play only signed into in shelter, using aurora outside of shelter. Apps that have a connection with google, or one or two trackers, all under Shelter. Android Auto, google Assistant, Calendar, Chrome, Files by google, Gmail, and Google all disabled. And a few more settings to try to keep clipboard, suggested next word, saved passwords etc private.

This is all taking multiple hours to investigate each app individually and carefully set up on three phones. It’s also tough to not make stupid mistakes that allow snooping because I missed something or signed in when I shouldn’t have. I’ve had to factory reset and start over once.

Anyway, not perfect (obviously), but I feel a little better about my personal threat model, considering that I (unfortunately) need to stay within the google ecosystem.