DivestOS vs. /e/ OS - security and privacy easy

Thanks for this info!

1 Like

Thanks you coming here, you are welcome.
I like the ton, the form and the content of your post,

4 Likes

Because you can’t easilly whitelist. I used hardcoded hosts file but was not happy with it, a symlink to a external host file would introduce security issues.

1 Like

I’m sure it works great, but to me it is not clear what it does, and what exactly is scanned. I see this a lot, putting a lot of effort to create an “engine” and then the “car” has to be build quickly around it using cardboard :). But i think you taking the time here to answer some questions and statements is quite nice, thanks.

2 Likes

Dear Tad

thanks for your time and insights. I enjoyed reading your post and I’m happy that we, as in users, are in such a lucky position to be able to choose between different OS’ with different takes on similar problems.

Very nice from you sharing your knowledge with other projects. This is what makes FOSS great and I’m more than not jelly, as I’m not able to contribute due to my poor coding skills.

4 Likes

Dear all, the /e/ team brought this interesting discussion thread to my attention.
So I want to explain something about privacy vs security, because there is often a lot of confusion between the two concepts.

Though they are linked together, you can have excellent security without privacy, and you can have decent privacy without hardened security.

The perfect examples are Apple and Google. They put a lot of effort into security and they call it privacy for marketing purpose.

If you take Google, this translates into: “we are hardening the security of your devices so that you can send us all your personal data in a safe way”. For Apple it’s a little bit different, but not so much in the end, if you consider the recent news about iOS, and if you consider that all your browsing searches on iOS, which is a big part of your life, goes through Google.

Where does /e/OS stand in this story?

The purpose of /e/ is to provide users an option to break free from the permanent and industrial data collection that happens in iOS and Android, for the profit of Google and Apple and a few other big techs. We think that this situation is bad and is a threat to our freedom, to our democracies, and has other bad side effects.

So I want to be clear that /e/OS is currently NOT a security-hardened system. This means that if your device is stolen/lost (1) or if you are targeted (2) by a powerful organization like govs, secret services, mafia… which can happen because of your sensitive activities, /e/OS won’t offer you an extra protection.

Why?

The reasons are :

  • we currently have more than enough work implementing features and bringing improvements on the privacy aspects, and make it auditable by using open source
  • we think that whatever extra security features you put in a computer system, if you are targetted by a powerful organization, you will eventually be compromised. There are hundred techniques for a powerful organization to get their hands on your data, and sometimes the most powerful ones are not the most technical, and history has shown that reaching “perfect security” is an endless mouse and cat game.

However we will improve security for the cases we think we can bring an interesting and realistic answer. That is the case for the example (1), when you lose your phone for instance. In this case we will offer users the opportunity to wipe their device remotely, that’s in our development roadmap.

My overall point here is that there are different products for different purpose. /e/OS is designed for a general audience that wishes to regain some control on their personal data, but that is not particulary threatened because of sensitive activities.

Have a good day everyone!
Gaël

28 Likes

Thank you for taking the time to personally respond here Gaël, I truly appreciate it.

But for lack of better words I genuinely believe that /e/OS is actively neglecting users with regards to security. I kindly ask that you and your team take a strong look at what the others in this area are doing and take it into account.

Best regards,
Tad.

10 Likes

So /e/OS is exactly what I use and want to have.
I am a normal citizen who is not afraid of the secret services, but would like to prevent the rapidly growing collection of data, which is often unnecessary for the use of mobile phones.

Keep it up

It would be interesting to know how well the Foundation is growing.

7 Likes

Thanks to your support /e/ OS team is growing at a slow but steady pace.
As a person who has been directly or indirectly connected with the organization from the start I am a witness to this growth. We have a list of team members on our website. Some of the team members mentioned there are not active now but we have retained the names as they contributed to the growth of the organization.
We have a number of new team members who have joined the team full time but their names are missing. I can see at least 10 names missing from the list . Expect the web site team will update the list soon.
A summary of the details of how the finance is managed is also provided on our website - mostly salaries and infra maintenance.
As Gaël mentioned /e/ is not a security hardened OS. Casual browsers who are looking for an absolutely secure OS would do better to try out other options.
/e/ will not change its focus from the average users who want to keep their data safe but at the same time due to personal reasons use popular social media apps. It is a contradiction of choices but most of our users face this dilemma. We at /e/ remain committed to this user group.
Our priorities remain to make the user experience better, increase the coverage of applications for this group of dedicated users and ease up the setup and configuration process as much as possible. It is a tough ask and one that keeps the teams busy.

12 Likes

I agree on that. The interface is simple and not distracting. As a matter of fact, users should only become aware of a threat in case there is one. This is basically the behavior of Hypatia.

Thanks for this nice software.

1 Like

Thanks for this comment. Maybe there are some simple additions that may help. My uneducated guess is that the Divested Computing Group did a nice service to the community by building Hypatia (A real-time malware scanner) - https://f-droid.org/packages/us.spotco.malwarescanner

Linux users are familiar with ClamAV and might appreciate this tool. Maybe it is worth to be considered for optional inclusion in /e/.

So far I can confirm the claims (fast, low energy consumption, simple) by the Divest developer(s) (albeit I cannot say if it is really working).

1 Like

@tyxo

did a nice service to the community by building Hypatia

Hypatia is absolutely completely useless compared to my CVE checker/patcher program

It allows any developer to patch any kernel against hundreds of known vulnerabilities with only a few minutes of trivial work. It is the best thing we can do for these old devices with old and outdated kernels.

4 Likes

There should be no misunderstanding. A maleware scanner has a slightly different purpose.
A patched system is the foundation.

I think the ability for /e/ users to re-lock the bootloader would be a big security improvement wouldn’t it? Not trying to sound sarcastic - genuine question/suggestion. From what I read online it is a big security risk to leave bootloader unlocked.

2 Likes

@anon88181694 seem to have knowledge about that, can you share how to make this possible?

bootloader locking

I am not allowed to paste links anymore so bear with me:

this is pretty easy to support/enable, you just have to integrate the following into your builds

  • builds must be -user, not -userdebug
  • in DivestOS-Build repo:
    • signing keys can be generated correctly using Scripts/Generate_Signing_Keys.sh $device
    • Scripts/Common/Copy_Keys.sh is used to copy verity keys into kernels
    • processRelease() in Scripts/Common/Functions.sh is used to sign releases
    • devices can have verified boot re-enabled using enableVerity() in Scripts/Common/Functions.sh
    • you need to sed -i 's/^\treturn VERITY_STATE_DISABLE;//' drivers/md/dm-android-verity.c on all kernels, to restore verified boot that LineageOS disabled
    • you’ll need to apply Patches/*/android_build/0002-OTA_Keys.patch to android_build repo to correctly add keys to the recovery
  • update_device_info.sh in DivestOS-Website repo has device bootloader information in the format: unlock method, bootloader lock support, verified boot support

As for device support (per the devices I build for):

  • 9 devices have been tested working with locked bootloader and verified boot
  • 5 devices have been tested working with locked bootloader but do not support verfied boot
  • 25 devices should support locked bootloader with verified boot
  • 6 devices should support locked bootloader but do not support verified boot
10 Likes

Yea you are right. Sometimes unlocking bootloader is critical for finance / banking app.

Yes I m into that also

Dear All,

From this topic I have been contuining to learn something new everyday. Very interesting feedbacks.

In my case I locked the bootloader again trough ADB in Linux. Some banking apps work with help of Shelter, some not. Could be /e/OS sign verification the issue?

Thanks
BR

1 Like

Hi, I too want to lock bootloader of Redmi Note 4. How to do it?