/e/ Page says /e/ is ungoogled/degoogled, why is /e/ then connecting to google?

Ok… I turned it off.

As far as I am concerned, a problem with leaking an IMEI to Google in a default configuration should be treated with utmost priority. And any feature that requires enabling certain options, but still causes this to happen should come without a big fat bright red double confirmation warning dialog popping up before anything of that sort is switched on. You cannot “unshare” data with Google once sent.

After all, the purpose of the /e/ project is to provide a privacy-friendly and de-googled operating system. I realize the project is still work in progress and I have the utmost amount of respect for the team behind it, but depending on people’s threat model, leaking an IMEI can amount to being a deal breaker, or worse, a trust breaker – not to mention a PR issue.

1 Like

Good idea! I would also like it that way.

1 Like

Yes, it does. iodé says:

1 Like

Can you all please start verifying claims of the projects you depend on instead of parroting their lies?

How is iodeOS degoogled if they include proprietary Google libraries in their browser?


­I just said that iodé says it was degoogled.­


Your wording was clear.
The comment was not directed at you, I apologize if it came off that way.
It was just meant in general.

No problem, it was probably my fault that I interpreted it that way.

I have a few comment/questions about all of this.

It is not really news that google has it’s tentacles everywhere. I am far from an expert at these things but I imagine at this point it has got to be nigh impossible to connect to the internet hardly without some kind of connection to google. It is a sad state.

Micro G is kind of a black box to me. I know it is a replacement for google services so that you can run apps meant for googled android without having google on your phone, but I imagine microG has to interface with google servers at some capacity to make this happen. Does merely this interfacing with google servers automatically give google your info? If I was super privacy focused like some here (not that there is anything wrong with that) I would think I would not want any google apps at all and thus would have no need for microG in the first place. Unfortunately you have to sacrifice much, I feel, to do that. For me, at least not being forced to have certain apps on my phone (like facebook) and not being fussed at and barred from basic functionality for not giving certain permissions, this is a step in the right direction and /e/ os gives me that. I do not have to connect my phone to a gmail account at all with /e/ os.

I feel like /e/ has their heart in the right place even if everything is not perfect. I sincerely doubt this is any kind of sinister plot to sell all your info to google or anything of the sort. My feeling is that a phone completely isolated from google could be provided but then you might as well be using a blackberry or palm pilot. At least /e/ gives you information on what trackers exist in certain apps etc. I think some connection to mainstream services and apps is necessary to attract a wider audience than just the early adopter types and the very privacy focused. If the community is never expanded in this way, there will never be enough momentum behind the project to be a viable third option to regular android or iphone.

Just some thoughts. Not meaning to be critical of any of the discussion. Just the fact that this discussion can take place openly and honestly is much appreciated (thank you e!).


It isnt. In my Network for example, i blocked everything from Google/Alphabet for example (Microsoft, Amazon, Facebook/Meta, and many others too) on Network level (DNS, Pi-hole).

And “my Internet” isnt more useless as “the internet from others”.

Prior my S10, i had a very old phone (12 years old), with lineageos on it, wich didnt got any updates since years. that i degoogled (and i mean really degoogled) by my self. but that was possible, because that phone was already not supported anymore since years, and didnt got any update wich would overwrite/remove all edits and patches i did.

As i got my S10, i searched for a lazy way so that i dont need to do it again. i found /e/OS. But after installation, i found out, that /e/OS is everything else, but sure not ungoogled/degoogled.

Thats why i created this topic (and still waiting for answer).

If only one Service/APP/what_ever depends on at least one Services from Google, they shouldnt claim that /e/OS is ungoogled/degoogled.

Nobody says /e/OS want to sell your data to others or something like that. only a question, and discussion, if it is right, to call that ungoogled/degoogled, if it is clear, that this isnt the case.


It is of course clear that /e/OS is not completely degoogled, as it is still based on AOSP and microg or App-Lounge send data to Google, but to my knowledge no personal data. I think /e/OS means by “degoogled” that no personal data is sent to Google, which is Google’s real privacy issue.


Hi, thank you for raising this interesting topic, since deGoogling is one of the key driver behind our project.

So here I’m trying to answer two things:

  • what do we mean by “deGoogling”?
  • what is the current deGoogling state
  • what can we expect in term of connections to some Google servers?

What do we mean by “deGoogling”?

Our vision of “deGoogling” is not something like “get rid of any piece of any Google-related software or feature in /e/OS”. It would be a dogmatic approach that probably some will love, but we’re not in that game that probably leads to nowhere. Instead, we focus on personal data protection, and which data is sent to Google. In other words, the purpose of /e/OS is to make its users untraceable by Google. In short: with /e/OS Google is not able to profile the user and use its data for its own purpose (micro-targetting), or to sell those data to third-parties.

What is the current state of deGoogling in /e/OS?

We have documented what’s been done so far at this page, and in this document at https://e.foundation/wp-content/uploads/2020/09/e-state-of-degooglisation.pdf
There is also this document at some-facts-about-the-Google-Android-operating-system-and-personal-data-collection/facts.md at main · leag1234/some-facts-about-the-Google-Android-operating-system-and-personal-data-collection · GitHub

Most of it should be still accurate, though possibly not totally up to date

What can we expect in term of connections to some Google servers?

In some cases, there are some connections to Google servers.

So far, the main source of connections to Google servers was microG, and especially access to push notifications. If users want to have push notifications from applications, there is no other way than connecting to Google server to receive push notifications, because most application that send notifications are using Google push notification (so this is implemented and embedded in Android apps). However, since we have totally removed the proprietary Google Play Services piece of software from /e/OS and replaced by microG, connections to Google servers for the purpose of push notifications feature are done anonymously. This means that the only thing Google knows is that they got a connection from a specific IP that is related to push notifications, but no more. So even if that is not totally perfect (an IP address can be used to track users) it’s considered to be good enough in term of personal data privacy.

Another case of connection to Google servers is related to Safetynet check. Safetynet is a so called security feature that Google suggests to app developers to ensure that their app is not running on a non-GoogleAndroid device (e.g. commercial Android you find on smartphones in stores, with the Google stamp on it). This check needs a connection to some Google servers. Once again here, it’s an anonymous call, so it doesn’t allow Google to track the user.

A third case of connection to Google servers is the new version of App Lounge that is now fetching data from Google Play Store directly to get access to the whole catalog of Android applications. We offer two options for this: anonymous access and real Google account. It’s user’s choice, but in all case there is an option to avoid being tracked by Google. The only issue here remains the IP address, but it’s a smaller issue.

Regarding tracking by IP you will also have a good surprise in 6 days from now (https://launch.murena.com/)

There are also a couple other “grey zones”, one is under investigation, it’s linked to A-GPS and SUPL servers, that can possibly use some Google servers, but it remains unclear at this stage.

That was a quick summary of where we are today, and I think it’s pretty good, and /e/OS is probably the most advanced mobile OS regarding personal data protection from Google (and we’re also adding more pro-privacy features that go beyond the big privacy issue with Google).

So in short: it’s not because there is a network socket opened that connects to a Google server that this means that it’s sending some personal data to Google. Things are a little bit more complex.

Note that what is written above is based of my current knowledge. As you may guess, we’re also playing with Pi-hole and other nice tools, to check what unexpected data could go over the network. So next step is that we’re checking this with the team, and we will soon give additional and more technical information about connections to Google servers.

Stay tuned!



Another case of connection to Google servers is related to Safetynet check. […] Once again here, it’s an anonymous call, so it doesn’t allow Google to track the user.

Please correct me if I’m wrong, but last I checked microG downloads and executes the highly obfuscated DroidGuard program and runs them.
And this is default enabled out of box:

Sending device serial is the opposite of anonymous?

1 Like

@SkewedZeppelin Are you able to submit a patch via Gitlab?

1 Like

microG sends randomly generated device serial by default (play-services-base-core/src/main/kotlin/org/microg/gms/profile/ProfileManager.kt · master · e / os / GmsCore · GitLab) unless the user explicitly ask microG to send the real device profile in the Google Device Registration in microG setting.

1 Like

OK, so as it is for microG:

  • NATIVE uses the real serial BUT randomizes each character as it was, as in number becomes another number, lower char another lower char, etc.
  • REAL will send the real serial number
  • The two profiles for Nexus and Motorola will use the random template on them

I indeed was wrong there with what microG itself sends.

But even ignoring what microG does/doesn’t, no one knows what DroidGuard does/collects/sends, and it still runs in a privileged context.

And again as I mentioned earlier in this thread, Widevine is also running in the TEE and in userspace on these devices too, also proprietary black boxes from Google.

1 Like

Hello, I believe the term Ungoogled/Degoogled is a specification meant to remove the Google commercial implementation from phones and people lives.
In other terms: cutting incomes.

Hi @Aizu welcome to the /e/ forum. that is a rather non-specific assertion. My memory of industrial history is that it is the formation of monopolies at very large scale that has driven down wages for the many and increased dividends for the few.

1 Like

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

To answer the question about pings from the /e/OS to google servers during setup, we have created a document. It can be viewed here