The Best Advanced Privacy ROM/w MicroG
I tested e/OS ROM on my OnePlus 5T for over a year, e/OS supports more than 269 devices
Fully "deGoogled" Open Source Mobile Ecosystem
- e/foundation Website
- OnePlus 5T Latest Dev Build Downloads
- e/OS "dumpling" & 5T Device Details
- List of More Than 269 Supported Devices
- Advanced Privacy
The operating system
/e/ is a “deGoogled” version of Android OS. It has an open-source Android OS core, with no Google apps or Google services accessing your personal data. It is compatible with all your favorite Android apps.With /e/ you’ll find a set of carefully selected apps to cover your most common needs, personal and professional: get you email, plan your week ahead, chat with your friends and coworkers, browse the web, check the weather, check your itinerary for your next meeting…
All the apps are based on open source bricks. We improve their design and experience to make them look stellar and easy to use daily.
Advanced Privacy
⦁ Table of Contents Link
Advanced Privacy lets you manage in app trackers, IP address and location. It’s available as a widget and within the operating system settings.Advanced Privacy is a specific tool developed to limit your data exposure once you have installed third party apps.
When an application snoops in the background, it will use trackers to log your activity even if you are not using the app. It will also collect the IP address, so it can potentially link internet activity to a specific device and to a persona, and finally it will try to pinpoint your exact location.
ONEPLUS 5T - ROM - ROOT - TWRP - "INSTALLATION GUIDE" LINK BELOW
- ⦁ "Installation Link" Method #1 Easy Installation (TOOL ALL IN ONE)
- ⦁ "Installation Link" Method #2 Install via command line (for advanced users)
IS PLAY STORE NEEDED?
As it turns out, giving up Google is possible, and the experience isn't nearly as bad as you might think, plus my battery life is amazing now. If you care about privacy, better battery life, or want a smoother running phone, take the plunge and find a Rom that doesn't have Gapps installed.
Below are a few applications that I have tested without Gapps installed. I have also listed a few alternative store applications with there links. I exclusively use FLOSS, Free/Libre and Open Source Software, and because of this, I chose to install F-Droid.
What is "FLOSS and FOSS"
The two political camps in the free software community are the free software movement and open source. The free software movement is a campaign for computer users' freedom; we say that a nonfree program is an injustice to its users. The open source camp declines to see the issue as a matter of justice to the users, and bases its arguments on practical benefits only.
To emphasize that “free software” refers to freedom and not to price, we sometimes write or say “free (libre) software,” adding the French or Spanish word that means free in the sense of freedom. In some contexts, it works to use just “libre software.”
A researcher studying practices and methods used by developers in the free software community decided that these questions were independent of the developers' political views, so he used the term “FLOSS,” meaning “Free/Libre and Open Source Software,” to explicitly avoid a preference between the two political camps. If you wish to be neutral, this is a good way to do it, since this makes the names of the two camps equally prominent.
Others use the term “FOSS,” which stands for “Free and Open Source Software.” This is meant to mean the same thing as “FLOSS,” but it is less clear, since it fails to explain that “free” refers to freedom. It also makes “free software” less visible than “open source,” since it presents “open source” prominently but splits “free software” apart.
“Free and Open Source Software” is misleading in another way: it suggests that “free and open source” names a single point of view, rather than mentioning two different ones. This conceptualization of the field is an obstacle to understanding the fact that free software and open source are different political positions that disagree fundamentally.
Thus, if you want to be neutral between free software and open source, and clear about them, the way to achieve that is to say “FLOSS,” not “FOSS.”
We in the free software movement don't use either of these terms, because we don't want to be neutral on the political question. We stand for freedom, and we show it every time—by saying “free” and “libre”— or “free (libre)”. by Richard Stallman
To emphasize that “free software” refers to freedom and not to price, we sometimes write or say “free (libre) software,” adding the French or Spanish word that means free in the sense of freedom. In some contexts, it works to use just “libre software.”
A researcher studying practices and methods used by developers in the free software community decided that these questions were independent of the developers' political views, so he used the term “FLOSS,” meaning “Free/Libre and Open Source Software,” to explicitly avoid a preference between the two political camps. If you wish to be neutral, this is a good way to do it, since this makes the names of the two camps equally prominent.
Others use the term “FOSS,” which stands for “Free and Open Source Software.” This is meant to mean the same thing as “FLOSS,” but it is less clear, since it fails to explain that “free” refers to freedom. It also makes “free software” less visible than “open source,” since it presents “open source” prominently but splits “free software” apart.
“Free and Open Source Software” is misleading in another way: it suggests that “free and open source” names a single point of view, rather than mentioning two different ones. This conceptualization of the field is an obstacle to understanding the fact that free software and open source are different political positions that disagree fundamentally.
Thus, if you want to be neutral between free software and open source, and clear about them, the way to achieve that is to say “FLOSS,” not “FOSS.”
We in the free software movement don't use either of these terms, because we don't want to be neutral on the political question. We stand for freedom, and we show it every time—by saying “free” and “libre”— or “free (libre)”. by Richard Stallman
If your running a Rom without Gapps, some applications like "Last Pass and Vimeo" will show a pop-up when you first start them that says, won't be able to run without Google Services, they might be able to run and some wont, unless you install microG, then you wont have this issue.
What is MicroG?
Actually, the microG is a free software clone of Google's proprietary center libraries and applications. To be more specific, it's a FLOSS (Free/Libre Open Source Software) frame to permit applications designed for Google Play Services to operate on programs, in which Play Services is not available. It provides all the needed APIs provided from the Google Play services so that the programs dependent on it may operate normally.
Telegram Links for microG Group Help
Update: I installed microG on my OnePlus 5T running Phoenix Rom. This Rom has signature spoofing already baked into it, so the installation is simpler, runs very smooth, better battery life and security. For detailed installation instruction, see post #5 below.
What is microG Signature Spoofing
To use all the neat features from the microG project, which allows you to use all features of your Android smartphone without proprietary battery-consuming Google blobs, your system is required to support signature spoofing. Currently only very few custom ROMs have built-in support for this feature, luckily you can use Xposed or a patching tool to add the feature to the systems that don’t have it.
But: What is all this about? Is signature spoofing a problem when not using microG? Will it influence my security?
About signature spoofing
On Android, all applications are signed (usually using SHA1 with RSA). The certificate/key-combinations used to sign apps are self-signed. This means there is no PKI / certificate authority to verify a key to be owned by a person/company/entity. Thus everyone can come up with a key that has a equally valid Google certificate as keys used by Google to publish their apps.
However, on Android signatures are not designed to serve the purpose of verifying ownership/source of a package. Signatures are used to verify integrity and to ensure same package author when updating apps. The second one is important, to verify that only one the author has access to the private storage of an app. A different author is not able to sign an app using the same key, because he does not have access to it, and thus can not provide an update to an application that will be granted access to the app private storage. For example, the Signal app provided by OpenWhisperSystems is signed by a key not available to third-parties and thus Signal can store chat history in the private app storage and don’t need to fear that a rogue update can access this data. This means that signatures are important to ensure the secrecy of the private app storage and thus is an essential part of the Android package managements security system.
Signature spoofing allows applications to behave like being signed by a third party. This means that whenever one application asks the operating system for the certificate used to sign an installed package and that package uses signature spoofing, instead of the certificate attached to the app, a spoofed certificate is returned. This certificate has to be announced in the AndroidManifest.xml and the app is required to request the android.permission.FAKE_SIGNATURE permission. This means that it is not only easy to detect that an application uses signature spoofing, the user also has to give its consent – before Android 6, this was done during installation time, since then the consent is even more explicit in a dedicated pop-up, and the user can decide not to grant the permission.
Of course only very few developers ever ask for the certificate used to sign an application. There are numerous reasons for that:
So why does microG require signature spoofing?
Now that we know, that only very few use direct access to certificate, you might wonder why microG needs it for certain features. Well the fact is that although most developers don’t even now about it, their apps actually do direct certificate access. This is due to how Google Play Services works:
Applications that use Google Play Services use the Play Services client library. This library is directly embedded into the application, is delivered as part of it and finally runs in the security context of that app. And this library actually uses direct certificate access to ensure that the Play Services app installed on the device is singed by a specific private key. It also verifies that the Play Store is installed (and signed using the same key), although it is not required for Play Services to run. This is the reason for the development of the microG FakeStore app.
There is one other popular use case I’d like to stress: DRM. Some developers use direct certificate access to verify that the application itself is signed by them. The reason for this is simple: If you modify an application you need to sign it (the previous signature is broken, if your system is not vulnerable to the “Android Master Key” vulnerability). As you don’t have the private key of the original developer you will not be able to create a valid signature that has the same certificate. This means you can’t modify the application without the original developer knowing about it. (Well, you could modify the checking code itself, …). With signature spoofing you can easily bypass these restrictions – as long as the app does not contain code to detect signature spoofing. by ~larma/blog
But: What is all this about? Is signature spoofing a problem when not using microG? Will it influence my security?
About signature spoofing
On Android, all applications are signed (usually using SHA1 with RSA). The certificate/key-combinations used to sign apps are self-signed. This means there is no PKI / certificate authority to verify a key to be owned by a person/company/entity. Thus everyone can come up with a key that has a equally valid Google certificate as keys used by Google to publish their apps.
However, on Android signatures are not designed to serve the purpose of verifying ownership/source of a package. Signatures are used to verify integrity and to ensure same package author when updating apps. The second one is important, to verify that only one the author has access to the private storage of an app. A different author is not able to sign an app using the same key, because he does not have access to it, and thus can not provide an update to an application that will be granted access to the app private storage. For example, the Signal app provided by OpenWhisperSystems is signed by a key not available to third-parties and thus Signal can store chat history in the private app storage and don’t need to fear that a rogue update can access this data. This means that signatures are important to ensure the secrecy of the private app storage and thus is an essential part of the Android package managements security system.
Signature spoofing allows applications to behave like being signed by a third party. This means that whenever one application asks the operating system for the certificate used to sign an installed package and that package uses signature spoofing, instead of the certificate attached to the app, a spoofed certificate is returned. This certificate has to be announced in the AndroidManifest.xml and the app is required to request the android.permission.FAKE_SIGNATURE permission. This means that it is not only easy to detect that an application uses signature spoofing, the user also has to give its consent – before Android 6, this was done during installation time, since then the consent is even more explicit in a dedicated pop-up, and the user can decide not to grant the permission.
Of course only very few developers ever ask for the certificate used to sign an application. There are numerous reasons for that:
- In most cases you only want to verify, that an app is signed with the same key as yours (e.g. the apps are from the same author). For this case, the package manager has a method checkSignatures which compares the certificates of two packages. Thus the app author is not required to mess with byte arrays returned when requesting the certificate – and verifying the author name of a certificate is completely useless as described above.
- If you want to use any kind of security model, you are much more likely to introduce a custom permission. On Android every app can declare a new permission and decide which apps will be granted this permission. One option here is to restrict by signature, or you can also require explicit user consent. This again is a lot easier than working with certificates, even more flexible and can be used to allow third-parties to integrate with your app (on users decision). Nice!
- Directly working with certificates is not considered a security feature and is not listed on the security tips article in the documentation, whereas the proper use of permissions is.
- When using the package managers GET_SIGNATURES feature to directly access the certificate, the android lint tool (which is usually used during the compilation process) will print a high priority warning, as improper use of this feature can be a security risk and the proper use is rather complicated. So complicated, that Google themselves did it wrong once, resulting in a major Android security vulnerability (sometimes referred to as the Fake ID vulnerability).
So why does microG require signature spoofing?
Now that we know, that only very few use direct access to certificate, you might wonder why microG needs it for certain features. Well the fact is that although most developers don’t even now about it, their apps actually do direct certificate access. This is due to how Google Play Services works:
Applications that use Google Play Services use the Play Services client library. This library is directly embedded into the application, is delivered as part of it and finally runs in the security context of that app. And this library actually uses direct certificate access to ensure that the Play Services app installed on the device is singed by a specific private key. It also verifies that the Play Store is installed (and signed using the same key), although it is not required for Play Services to run. This is the reason for the development of the microG FakeStore app.
There is one other popular use case I’d like to stress: DRM. Some developers use direct certificate access to verify that the application itself is signed by them. The reason for this is simple: If you modify an application you need to sign it (the previous signature is broken, if your system is not vulnerable to the “Android Master Key” vulnerability). As you don’t have the private key of the original developer you will not be able to create a valid signature that has the same certificate. This means you can’t modify the application without the original developer knowing about it. (Well, you could modify the checking code itself, …). With signature spoofing you can easily bypass these restrictions – as long as the app does not contain code to detect signature spoofing. by ~larma/blog
If your Rom does not support Signature Spoofing, take a look at this link.
Last edited: