Find your Device with an SMS or online with the help of FMDServer. This applications goal is to track your device when it’s lost and should be a…
Find your Device with an SMS or online with the help of FMDServer. This applications goal is to track your device when it’s lost and should be a…
I wouldn’t use it, but always appreciate Open Source solutions that can be self hosted if you want.
If you really care about your privacy, think about to not use stock Android. Instead consider an alternative that is based on Android, but stipping out all the Google and tracking from the operating system, such as “/e/” operating system (bad name): https://en.wikipedia.org/wiki//e/_(operating_system) and https://e.foundation/e-os/
Could you explain why you wouldn’t use it?
I’ve been using it for a couple of years and am happy with it, it grants an extra layer of security I think, if you can wipe the device when lost/stolen. Also very handy if you misplaced the phone and its set to not ring, as with this it will ring at full volume. You don’t need to use their server for the app to function, if that is your concern. I use a secondary device from my household. You can send a text message to your phone to let it ring even when its set to silent mode/get its location/or even wipe it remotely.
Nothing against the project or the concept, I personally don’t have a need for. I’m just the kind of person who is organized when it comes to stuff like that (no offense to anyone, I really try to be careful with the wording here!). And if I don’t see a need for a software or service, then there is no need to add complexity to the system. I’m still curious enough about these tools to look into. That’s all.
/e/ is not very degoogled. DivestOS or GrapheneOS would be better choices, then maybe CalyxOS.
/e/ does quite a good job removing Google’s presence from Android. It’s been awhile since I watched it, but this techlore video does a good breakdown of it.
https://eylenburg.github.io/android_comparison.htm
I’m not sure what your point is with this reply?
I’ve seen that page before, it’s helpful for getting your bearings with the different android ROMs, but take a look down towards the bottom at the “Supported Devices” section, and also compare the /e/ section to the “Stock Android” section.
It still has much of the google proprietary blobs still included and relies on google services, also without significant effort to harden Android. I have also heard that sometimes they fall behind on updates to their apps by weeks at a time (correct me if I’m wrong I am still looking for the source I found this info from). It may be moderately degoogled, but their security just ain’t there. In some cases (like OEM EOSL for older devices) having a 3rd party ROM may improve security with more up to date patches. Unless the bootloader is relockable and secure boot is possible, you will be compromising your device’s security (and privacy along with it) and destroying the Android security model in general.
Like you say, it is moderately de-googled, which is a fantastic improvement over stock android any way you spin it. I believe that was the point of the original commenter, as it is mine. However there are those blobs that do get left in (in every ROM, including even DivestOS which is the most aggresive in this regard). Install a firewall or network monitor on a device that’s only been somewhat deblobbed and you’ll find that they are not little black boxes sending all your data to Google, but instead are there to do things locally like software interaction with hardware in the phone that is from another company like Broadcom.
Any ROM on a Samsung phone probably lags on security updates due to Samsung itself being slow to release them, though they do seem to be doing better lately. If the ROM itself is slow to push updates, the most you’ll wait is 2-3 months. That’s pretty much not a problem unless you’re being threatened by state level actors, and is the state that the majority of stock android users are in. In fact, stock android can often be years out of date because their manufacturer just doesn’t put them out.
Regarding dependence on Google services (play store of otherwise), let’s be honest, GrapheneOS users almost always install sandboxed play services, work profile or not. I don’t blame them, it’s how I have Graphene installed on my phone. However, this not a privacy oriented thing to do, it releases a flood of information to Google, much more that a simple connectivity check or SUPL ping. It’s not as much as fully integrated play services though, which is good. MicroG may be theoretically less secure, but it is certainly more private. It simply asks for less information from you than play services do.
The relockable bootloader subject is bit of a pet peeve of mine. Personally, I do choose to use a pixel so that I can have that added security, as it does have value. However, to say that without a lockable bootloader you are compromising your security and by extension privacy is what i would consider an overstatement that creates fear and uncertainty. Your security and privacy only become compromised if a thief steals your physical device then also has the know how to execute a sophisticated software based attack on the phone using adb. This just isn’t something that happens. In the many years I’ve been around the android ROM community, privacy/security focused or otherwise, I’ve not heard of this happening even once. To tie it back in to the OP, this scenario is actually a perfect use case for the app mentioned in this post, it offers you the ability to remotely wipe the device if it’s been stolen.
It can be an issue from a software angle though too, but then you would have to download and install a piece of malicious software that is specifically targeting phones without verified boot. At that point there is a greater issue though, because you can download and install malicious software that is targeting phones that DO have verified boot active just as easily. All that’s necessary is to be well informed and have good security habits and behaviors, it’s how desktop competant windows and Linux users have gotten along just fine all these decades.
It’s easy to get swept up in the security dogma of the android ROM community. In my opinion, some of it is helpful, but some is not practical or useful for every day users.
Related to relockable bootloaders and the security they provide, I was under the impression that if a malicious bit of software were to make use of some privilege escalating vulnerability and modify the kernel, the phone would fail to run in some way (ignore the rest of this if that isn’t the case). I dont think security should be dependent on the user behavior in basically any case.
For example, a FOSS developer in our communities could suddenly lose it and modify an existing app of theirs to inject malicious code making use of a vulnerability in android and we’d have know what of knowing until the damage is reported. Good user behavior is very important for security, but we can’t all be auditing our apps for each new release, even though its quite unlikely to happen.
Yes that’s the benefit of verified boot, and it is a helpful security feature. However, if you’ve used or are using Windows or Linux as an operating system, then you are comfortable with using a device that does not have verified boot (not sure about iOS and Mac, I’m not familiar with them). The risk you’re talking about with malicious code being injected in to an app you’ve chosen to trust is a threat to any device, verified boot or not. Modification of the kernel is an attack vector, but it certainly isn’t the only way for an app to cause mischief on your phone and devices are all relatively as vulnerable to developer or supply chain attacks.
Using software someone else developed always comes down to trust, unless you are auditing the code for every app you use, which I don’t think either you or I are. Having features that increase security in some technical way feels good but may lull us a sense of security. For instance, here’s a quote from a security researcher that I ran across in the past. It’s regarding the reputation for security that iOS has:
The same is true for us users. Security features are important, but user education and awareness is the most important element of keeping ourselves from ‘making bad decisions and opening up security vulnerabilities’ in our device usage.
Thankfully like you said, there are thousands of highly qualified individuals vetting the code of mainstream open source projects, which saves us regular users in the case we face an xz situation. A few principles that outway security features like verified boot in my book are:
Unless you are being targeted by a stalker, a malicious state actor or are downloading disreputable software, the average user (with a little bit of knowledge) would be just fine on /e/ or lineageOS. Tens of thousands of people are right now without any problems.
Why is /e/ not very degoogled? It is through and through.
There is no android ROM that is fully degoogled without losing out on much of base Android’s functionality. See the table I link under the other person’s comment. I have also heard that /e/ OS falls behind on package updates from its forks of other projects, many of its default apps.
Here is a thorough analysis of /os’s security and privacy.
https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6/
Tldnr: it’s alright but but grapheme, divestos or calyxos should be preferred if those are available on your device.
Problematic seems the unique device id /e os generates and sends on every update and also security updates for the integrated webview browser have been severely out of date in the past.
Looks like a good and careful analysis. While I speak German, its a lot to take here, so cannot say much about the articles content (besides some of the concepts are way above my head and understanding).
But the article/analysis doesn’t seem to support your claim “not very degoogled”? (Edit: I changed this phrase, it was wrongly phrased.)
The /e/os ID you mentioned, has nothing to do with Google, as the update information is sent to /e/os servers I guess (which in itself is concerning, I’m not saying otherwise). I personally don’t see a need to switch to any of the other services (they pretty much also support microG and I can’t install them anyway I guess).
Ok, yeah, you’ve got a point I think. But one could argue if microg is enabled by default, at least some info might leak to google as their push servers are contacted and a device id is created (even if the data is anonymized to some extend.). (Depending on if these settings are enabled by default in microg which I am not sure of).
Here’s some info from the divestOS faq (cmp.: https://divestos.org/pages/faq):
"Anything important I should know about microG?¶
It goes on to provide some guidelines if you want to use microg:
How should I configure microG?¶
"Depending on the apps you want to use there are a few different ways you can use microG.
So depending on your thread model, you still would want to disable some of the options in microg to have absolutely no leakage of data to google. For example I am not comfortable any more with using push notifications since it was revealed that state actors use this info to tail users communications.