Some clarification regarding security vs privacy in /e/OS

Hi everyone,

I’d like to share some thoughts on the topic of “privacy vs. security” within /e/OS and clarify a few points.

As you know, the promise of /e/OS has been to build a product that lets its users escape as much as possible the permanent data collection from the big techs, starting with Google, but not only.

We are cleaning Android of all features that send data to Google, replacing them with equivalent open source apps or custom developments. We have microG instead of the Google Play Services to ensure apps can benefit from all basic features such as push notifications, location… with a minimal exposure to Google. We have developed an app store that offers any existing Android app again with minimal exposure to Google and informs users about some basic information related to application trackers. Since last year, we have gone one step further with the introduction of Advanced Privacy that lets users log and block application trackers, and even offer them the opportunity to fake their location and fake their IP Address, in case of need.

/e/OS has been the first to release such an operating system with very advanced protection against personal data collection. This is without any specific configuration and is usable by anyone, even without previous knowledge.

In the meantime, we have seen other AOSP-based ROM projects starting to communicate on Privacy, some even copying our features. That’s OK!

But we also have been regularly attacked by some of those projects, including by some of their founders, including personal and direct threats. Most of the time, not answering or blocking those people is enough.

But others remain publicly active, and one of their preferred arguments is that /e/OS would be a security nightmare. Their message is actually even more ambiguous because they often implicitly or explicitly claim that privacy and security are the same things, and that /e/OS, as a privacy-focused project, should be the king of security.

However, this is a fallacy:

  • /e/OS is not and was never about hardened-security: we design a product that helps any user easily escape personal data collection and digital surveillance. We are not designing /e/OS for people who can be targeted because of their activities. And believe me: those people should just avoid using a smartphone at all, because even the best-hardened Android or iPhone can be penetrated by hackers if the benefit is worth the cost.
  • Security and privacy are not the same thing! Of course, we need security… We cannot let everything totally unsecure, open to everyone, and claim privacy. However, what is needed is state-of-the-art security, not just hardened security. Google is maintaining confusion between security and privacy in exactly the same way: “let me catch all your personal data… very securely!”
  • /e/OS is secure: we apply AOSP security patches each month (which is not the case of all commercial Android vendors), we update software as much as we can…

Now, we are not perfect: sometimes we make mistakes, sometimes we are late on some things for some reasons. That happens, and we try to fix. One of the preferred arguments of our detractors is about the /e/OS web browser and web view…

Historically, we have used the Bromite browser with some specific settings to build the /e/OS browser. But the Bromite browser project has been unmaintained for months, and we have not been able to ship new builds of /e/OS browsers based on recent Chromium releases (today we are stuck at 108). As a result, we are missing out on some new features and, obviously, some security updates that were introduced after version 108. Our support and dev team have been working to find a sustainable solution and process to address this concern, and we hope to reach a viable solution as soon as possible, but it’s not here yet.

While this isn’t a major security concern and doesn’t impact privacy, it still needs to be addressed. Meanwhile, those not confortable with this situation can download an alternative web browser from App Lounge.


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


super logical, thanks for the detailed explanation


Perfect clarification! Everybody, who don’t understand this, should better not use /e/OS.


Thanks for that.

/e/ is already a solid pillar in the fight against the massive theft of our privacy.

Its opponents show us that the project is expanding. They are afraid.

The work done by the /e/ & murena team and the community, the inclusive approach, has won my confidence since 2018.


I look at it like, what has better security, your home or a prison? What has better privacy, your home or a prison?


Propably a naive question from a layman so bare with me: why not switch to Firefox as default browser for the OS, which continues being maintained and may be more in line philosophically with your goals than a google chromium fork?

Excellent comparison! And you are right: the digital world that big techs offer us, and supported by many govs in the world, really looks like a giant digital jail.


We have considered it but Firefox is not easier to compile and as we have to apply our own privacy settings… There have been performance issues as well, for PWAs, not sure how it improved.


Gael, thank you very much for the update on this and the amazing work you and your team are doing.

I understand the challenges and I appreciate all the effort that goes into the project. Moreover, I believe in what you are working on and I’m trying to help promote and recommend the system to as many pepople as I can.

That being said, I still have some reservations why I can’t recommend /e/ unconditionally, and I hope these can be addressed soon.

It’s not just WebView, the PDF viewer has the same issue, and probably a few other components. And then there is the fact that several supported phone models have not had Android security patches since May due to build problems with these devices.

I don’t think anyone is expecting you to do a perfect job of this given the scope of what you are trying to achieve. I think what’s needed at this point is just clear communication of known security issues that are being worked on (maybe in update descriptions, or even just the development update posts in the forum) so people know they are being taken seriously.

Also, a commitment that there is a plan to reach a point in the future where all known security vulnerabilities are fixed no later than the next monthly update could help build confidence in the project.

My impression is that the main criticism here doesn’t stem as much from the security issues themselves, it’s more that some people are apparently doubting that the problems are taken seriously and get high enough priority. There are of course also those who deliberately try to use this to discredit the project, but that shouldn’t lead us to ignore the valid parts of their criticism.

That’s what people like you and me can do. But users who don’t read the forum, IT news or bug tracker wouldn’t even know about the problem in the first place. And then there are users like everyone’s grandma, or the janitor, or the pizza guy around the corner who wouldn’t even understand these issues if we tried to explain. Yet they have a right to privacy just as much as we do.

And while /e/ could be the perfect OS for someone like that, it is especially those people that need a system where they can rely on it being secure out of the box, because they will never fail to open every single web link and every shady PDF or Word document that gets sent to them.

So the more successful your are in making privacy usable by non-technical users, the more it also needs to be matched by corresponding efforts in the security department.

What you have done so far in that regard is truly amazing and, as I have said before, /e/ is no doubt the most privacy friendly system out of the box already.

Yet there is currently a danger that casual users get a false sense of privacy. People rightfully assume they are fully protected and that additional measures like an additional tracking blocker (Blokada, Tracker Control, PiHole etc.) or firewall on top of Advanced Privacy are not needed.

But with issues like #6124, which I filed but which was closed without a fix, it is clear that this is not the case just yet.

It is reasonable to expect that a feature like Advanced Privacy will at least effectively block Facebook and Google from tracking the users’ activities. If that isn’t the case, I expect a warning that the feature is still under development and that for the time being, additional measures are recommended.

So, from my perspective, it’s all mostly a matter of improving transparency in areas where there is still unfinished work. Then all of us can help spread the word until we get to a point where there is enough funding to be able to give the team the resources to address things like security problems in a more timely manner.

Then the narrative can become more “They take security issues very seriously and are working hard on fixing them, they just need a bit more resources, let’s spread the word and donate!” rather than “Oh they only care about privacy and ignore security” or “When asked about security, Gael said they’re already doing a good enough job despite there being multiple known security vulnerabilities for months”.

Sorry for the lengthy post, but I really want for Murena and /e/ to succeed and not those who are trying to discredit the project.


Everything is a process and perfection can never be achieved as everyone has their own definition of perfection.

As well as there is nothing in this universe that is completely perfect, and anyone who expects perfection needs to take a hard look at their own unattainable expectations.

This post and the details and explanations are very much appreciated. We also appreciate all the work done by the team and yourself.

Thank you all for making an alternative for all the other options out there and dealing with the naysayers who obviously don’t appreciate the amount of effort and hard work needed for these things.


It’s not just WebView, the PDF viewer has the same issue, and probably a few other components.

What is the problem with the PDF viewer?
Which are these few other components?

Also, a commitment that there is a plan to reach a point in the future where all known security vulnerabilities are fixed no later than the next monthly update could help build confidence in the project.

This, I agree, is not clear enough. But yes, we are taking all those questions seriously and we’re trying to address them as best as we can.

My impression is that the main criticism here doesn’t stem as much from the security issues themselves, it’s more that some people are apparently doubting that the problems are taken seriously and get high enough priority.

All those things are taken seriously and we are fixing them one by one, slower that we wish. Regarding priority, again, as a pro-privacy project, not a hardened-security project. The choice, at least today for us is: innovating on privacy & apps compatiblity (advanced privacy, rootbeer/safetynet/…) & device support, OR be 100% clean in term of security patches etc. (which obvisouly WOULD NOT mean perfect security: all the up to date software released today in the world has thousands security holes that will be fixed in some days/weeks/months/years…). If we take option 2, we do not exist.

Regarding your issue with trackers not detected, I’ll have a look.


Would Firefox not be the best choice as Browser? What are the concern with using Firefox?

Thank you very much for taking the time to respond to all of this in detail, especially on a Sunday!

Last time I checked it was based on a project that is no longer developed and there were known critical security flaws. I remember that f-droid under Lineage even went as far as to actively warn users and urging them to uninstall it.

PDF viewer was just an example and may have been addressed in the meantime – I can’t verify right now since my device is one of the 14 models stuck on 1.11 due to the build issues, and I can’t even check on 1.11 since Bliss Launcher got into a crash loop this week making the device unusable for now (bug report filed).

Sorry if my wording was not clear, this was pure speculation on my part. My point is that with the given scope of the project, security problems like these are bound to exist. And in my opinion that’s fine as long as there is transparency and a clearly stated goal to improve the situation as soon as resources allow for it.

I think this statement is absolutely the key part and could be communicated a bit more clearly in PR to take the steam out of the “but they don’t care about Webview!” criticism strategy.

Thank you very much! As far as I can tell it’s just a matter of adding more comprehensive block lists than the ones currently used.

I don’t think there are any big concerns in particular and firefox would be a pretty decent browser. good enough for a preinstalled system one anyways

But they as mentioned in a post above they seemed to have been having issues tying to devlop their own version of firefox and not only that some people might have issues with the decreased speed that firefox can bring so it might upset some people. and also i can sadly confirm while PWA’s on firefox have seemed to improve they still do have some performance and stability issues

1 Like

Thanks Gaël for your clarification. All /e/OS users will follow you and your team in this project because WE need project like this.


I hope there is a good solution for the bromite issue. I can accept a goodsaolution over a quick solution. In the meantime I use the Mull browser.

But Firefox on android is sadly not there yet. Especially when you use it to create a lot of PWAs.

But there is Chromite, a bromite fork, and Mulch from DivestOS. Cant say anything about them just that they exist.

1 Like

Is that problem solved in Mull?

And is Mulch from DivestOS different from Mull from F-Droid?

Mull is firefox based, mulch chromium based afaik

1 Like

This post was flagged by the community and is temporarily hidden.

1 Like

This post was flagged by the community and is temporarily hidden.