What is /e/'s position on security?

/e/OS Smartphone Operating System
1

I’m in the process of looking around at various privacy and security focused Android OS’s and I’m reading quite a number of criticisms of /e/ around security, e.g. coming from people that like GrapheneOS, CalyxOS, et. al. The criticisms focus on two broad areas, the first being that /e/ inherits the userdebug builds from LineageOS and thus disables a very large swath of Android security protections, the second being that /e/ supports (focuses?) on old devices that have not had updates to their proprietary blobs for a long time and that run older kernels with known vulnerabilities.

I don’t want to start another argument here, my question is whether there is any “official” response to those criticisms. I understand this is both a touchy and tricky topic (not unlike privacy) and would love to hear /e/‘s reasoning for why it’s OK to use LineageOS’ security stance as a base and why it’s OK to promote the use of old phones in the face of the security issues.

Personally, up to about a year ago I did not really care about my phone’s security: I simply didn’t have much of value on it and I avoided all SMS verification stuff. At this point, however, I have to accept that I can no longer avoid apps and SMS that affect my finances and other personal safety/security aspects, which means I have to take my phone’s security seriously and sadly this raises some important doubts about /e/.

2 Likes
2

Hello.
The first vulnerability is always…
.
user!

And for my security (?) my banck launch aws (and gg-lytics, and so on, without my consent) each time I connect from my PC running Debian, with clean DNS… Furthermore, wants me to download a gg assistant :crazy_face:

Sorry, /me => [ ]

1 Like
3

@Manoj … Are you aware of anything official in this regard?

4

We would prefer to spend our time on resolving issues we have and making improvements to the code. Seriously we do not have the time to devote to answer every critic or troll who wants to bash /e/ and prove that their OS is better.
I can only tell them if your OS is better than /e/ good for you. Spend more time on it and make it better instead of wasting your time bashing /e/.
We have shared all that is to be known about /e/ in our Product Description . Gaël has regularly shared updated about the work we do through his posts which show up on Kickstarter and which then show up on our announcement channel. Searching through this site will throw up a lot of posts on the /e/ way of working.
We are not trying to beat anyone or be better than anyone else. We are only trying to improve the google AOSP code and make it safe for the average android smartphone user. Nothing more nothing less. When the time comes we will come up with detailed documents on security and privacy from our perspective. For now we would prefer to get the work at hand done.

9 Likes
5

Thanks, I was fearing this type of reply :sleepy:. The word “security” does not show up once in the product description. I looked in the announcements category, and I can’t find anything noteworthy either. You write “trying to improve the google AOSP code” but you start with LineageOS which disables a large number of Android security features, so while you’re improving on some axes you’re taking a huge step back on the security axis. I respect “For now we would prefer to get the work at hand done” I was just wondering about the direction of this work.

1 Like
6

I undestand your point. Well it depends how you look. I saw some post by Mr. Duval stating (e.g. at kickstarter) that updating /e/ is important to apply the security patches constantly following in. Certainly not a full statement but they care. I undstand the response by @Manoj in that way. Updates included but currently no additional measures because there are no resources for this ATM. This comes later it seems.
@tve : out of curiosity, what other things could be done?

7

The biggest item would be not to produce userdebug builds, which reduce security. I don’t know whether that would require ditching lineageos or not.

Another big issue is the promotion of old devices, which is really great from a responsible-consumer perspective, but horrid from a security one. The reason is that they are several years out of date on firmware (proprietary blobs) and kernel. Look up the mediatek-su vulnerability to read how bad these issues can get (e.g. https://www.xda-developers.com/mediatek-su-rootkit-exploit/), I found it rather eye-opening.

Finally, if you look at security-focused ROMs like grapheneos or calyxos you’ll see that they’re almost exclusively available for google pixel devices. The reason is that on pixels you can unlock the bootloader, flash a completely custom ROM, and then relock the bootloader for that ROM and thereby get full verification at boot time. What this means is that even if a malicious app manages to get root (or whatever) access due to a vulnerability it can’t make that persist across reboots. I don’t see that a pixel-only focus could work for /e/ but I would have expected /e/ to support pixels better and use that as a way to try and get more manufacturers to support this feature.

I’m not a security fanatic. I decided to ditch stock because of privacy, specifically, I don’t want every thing I do tracked by Google et. al. But there is a very big overlap between privacy and security and as I’ve been educating myself about the various options for a more private system for my phone I’ve found myself unwilling to trade privacy off for less security. Given that I own a pixel3a I fortunately have very good options.

(Edit: I’m also not focusing exclusively on where /e/ is today but where it’s headed, hence the phrasing of the topic of this thread.)

5 Likes
8

Thanks for this clear and interesting answer. I didn’t consider the firmware an issue. Indeed more complicated than I thought.

9

Hi everybody,

Well, I just recently found out about /e/ and other google-free alternatives, and I do like /e/'s concept and its approach making a change from Android to /e/ as easy as possible for normal users, even by offering ready to use phones. However, as tve stated above, the prospect of the mere possibly of exchanging privacy for a higher vulnerability doesn’t sound like a good deal.

While e.foundations marketing strategy and fair transparency are quite good, I wish the security topic would gain a little more attention and convince people like me that it is okay to invest in a Mureno /e/phone.

PS: Okay, just found some comforting information in the release notes (https://gitlab.e.foundation/e/os/releases/-/releases).

1 Like
10

/e/OS primary aim is to be privacy-friendly (And still user-frinedly), rather than particularly secure like .e.g. CalyxOS or GrapheneOS. However, this does not mean that it is any less secure than either stock Android, or than LineageOS on which it is mainly based. So you are not giving up any security compared to those OSs in return for the increased privay

1 Like
11

I disagree, unless something has changed that I haven’t noticed: /e/ does not use secure boot with a locked bootloader. That’s a huge security difference compared to stock, CalyxOS or Graphene.

1 Like
12

E’s founder believes you can have “decent privacy” without “hardened security.” DivestOS vs. /e/ OS - security and privacy easy - #73 by gael This is a mistak/e/, but /e/ is what /e/ is.

13

Hello.

If someone else can pick your device, there is no security.

Strong passwords and my brain as pw.manager are better than ‘secured’ system. Cause every system has its own failures…

Inboard data leaks (between apps, with hardware backdoors and so on) are an higher risk for privacy and personal security than an unlocked bootloader.

1 Like
14

What this means is that even if a malicious app manages to get root (or whatever) access due to a vulnerability it can’t make that persist across reboots

dm-verity within AVB protects the system and vendor partitions, but the malicious app on data can regain root anytime some of its code is triggered if the device is still vulnerable. The example mediatek exploit posted would elevate to root on a -user build too if you have an app calling the described ioctls. There are benefits sure, just being nuanced. A re-locked bootloader is only possible on a subset of devices. Enabling encryption on userdata should be prominently advised for though to have an evenings time to cycle credentials if the phone parts ways and assess fallout.

I dug up some links recently on userdebug (more for App compatability than security, no more “rooted device” complaining because of ro.debuggable) at App called mitID keeps saying my device is rooted - #6 by tcecyk - I’m sure the /e/ devs will gradually introduce those for devices time permitting.

2 Likes
15

Matter of opinion. /e/OS’s security is “good enough” for me (and for many other users). And its ease of user is great too, with everything you need working “out of the box”. If you want a “hardened security” OS, then don’t pick /e/OS

1 Like
16

Thanks for all your controversial arguments. I’m just a regular phone user and don’t know much about specific risks. Saying that there are risks in all soft- and hardware, however, sounds like a poor argument. Wouldn’t that be like leaving all doors and windows open or unlocked, because an experienced burgler can get into the house anyway? I think as many obstacles as possible are better than none.

I’m pretty sensitive about my privacy, not using any social media/chat platform or email client except Threema, FairEmail and Ghostery, boycotting Amazon, Spottify, Netflix – you name it - additionally trying to protect my personal data with other solutions as best as I can. Those are some of the things besides my surfing behavior, I can control. What I, personally, have very limited control over is the operating system and the hardware I use. That means I have to rely on them to a high degree and to trust security and/or privacy promising developers, that they are using all means possible.

There are as many companies, institutions, secret services, totalitarian states, or bored/greedy individuals capable of gaining unauthorized access to our systems and data as there are reasons to use them, for profit, full control, blackmail, corruption and whatever. Thus it’s high time for a Europe-made Google-free OS! But what good would a Google freed OS be, if at the same time it’s opening backdoors?

Like I said, I’m a layman here, but if critics (although I don’t know how skilled they are) are pointing out that /e/OS might have security problems and there are no reassuring explanations on the foundation’s website, from the founder, or the development team, then … this makes me wonder if the decision whether to use /e/OS or Android is a choice between pest and cholera. Okay now, I may be exaggerating - what I’m trying to point out is, that this security topic should be communicated fair and square on the /e/OS website, because common sense tells me there’s no privacy without decent security.

Whether an unlocked boot is inevitable or not such a big deal after all, should be clarified in a convincing way and in simple words that everybody understands. If common Android patches are adopted and provided, I’d like to find this information on an official page. If device affecting patches are released, will there be respective patches available for e.g. Mureno phones, or is that obsolete, as those phones aren’t supported by manufacturers any more in the first place? In this respect the /e/OS and Mureno promotion in my very own humble opinion seems to be as improvable as any other cell phone advertising. Too little information for decision making.

Just one last remark: The most interesting privacy protecting Android alternatives I read about, are US based, i.e. I wouldn’t trust them in the long run. I think, /e/OS should proudly emphasize its origin and the GDPR.

BTW, here’s an article recommending /e/OS’s privacy protection: „Schlimmer als Google: Welche Daten alternative Android-Hersteller sammeln“

1 Like
17

One example tells you all you need to know about E’s priority for privacy and security: Search this forum and e gitlab for Nervuri app store issues.

Open Gitlab Issues:

  • 4091-privacy and security: sending device ID and installed apps list to App store
  • 4143-Apps store promotes apps with trackers

May 2021 first reported, to January 2022, any progress?

1 Like
18

This topic was automatically closed after 14 days. New replies are no longer allowed.