My /e/ exit interview

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.




I may be wrong but I think that even under shleter, apps with tracker still tracks you in your work profile.
Shelter is usefull against apps like whatsapp which collect contacts info but not against trackers.
You’d better use Advanced Privacy/Tracker Control/DDG app tracking protection and so on.

Hi @hkmike do you log in to a Google A/C at first start wizard?

@Nicolas_Sas The idea is to hopefully limit all tracking to only the work profile in Shelter. There are some apps that are specifically granted permission by default to access personal data from the work file and vice versa! I denied them that permission. I doubt that it works completely, but turning off most of the water faucets should cause the house to flood much more slowly, as it were.

I had to choose between Tracker Control and a VPN that blocks trackers. I chose the latter.

@aibd No. And it seems to have worked. Shelter apps know about the google Play store, but apps in the main profile do not, and the main profile claims that there is no account associated with the device.

I am hoping that each device is functionally two completely separate devices. At least access is limited as much as possible.