Hi!
I am trying to select a new OS for my Android phone after the old one (Divest OS) got discontinued, and I am still undecided. I mostly based my choice the last time on Mr. Kuketz’s articles (linked in the top of IodéOS website, awesome!) and my main criteria is complete de-googlification, 0 connections to Google.
In the 2023 article, it was mentioned that IodéOS makes connections to Google services, specifically: googleapis, firebaseinstallations. According to the article, there are several other connection the OS is making to corporate websites (Broadcom, Mozilla, Github, Accuweather), this is less important for me.
Does IodéOS still make the afformentioned connections to Google services or did things change? Perhaps, they can be disabled? Can other connections be disabled? I plan to not use MicroG or Aurora, just F-Droid instead, so I don’t expect issues with store connections, I hope there won’t be any.
Best,
Michelle
Can you name the specific connections you are interested in so I can check on my phone and firewall?
Yes, when microG is being used it is communicating with Google services, including firebase for messaging apps (but from open re-implementations of communicating with their APIs that also anonymize the data). But you can disable (and then fully remove after reboot) microG from “System Settings > Apps > Preinstalled Apps”.
An additional one to disable would be the SUPL server under Location settings which also would communicate with Google, as we don’t have an open alternative to use in its place.
I haven’t set up a test device with all of those disabled / removed, maybe someone else has and can then inspect if there are possible other items that need to be disabled.
So that any websites, etc. from the browser don’t go to Google, you may prefer to set some custom rules in the iodé app to block *.google.com (and other namespace variations you would want to block, maybe *.youtube.com etc.). To add custom rules you would need to subscribe to “iodé Premium”.
Hi! Thanks for reply!
I can’t link more than 4 links in a post as I am a new user, so some links are unlinked.
Google firebase connection: firebaseinstallations.googleapis.com
^ this one is reported to connect only ones, so it is better to use a captive portal to try to catch them which is pretty advanced.
googleapis: remoteprovisioning#googleapis#com
^also done once
Github: (Microsoft): github#com
^used for updates
Cloudflare: gitlab#com
^used for updates
AccuWeather: api#accuweather#com
^used for weather
Broadcom: gllto#glpals#com
^used for positioning (this one can probably be switched off by switching off location)
Since the article is 2 years old, maybe this is outdated, but some open source projects do not change some important things for decades (Like Firefox, in my personal experience). DivestOS managed to work perfectly well without these connections.
Dear @rik , the connections mentioned above are unrelated to microG. I like iode firewall idea, but iirc you can’t use it together with a VPN, right?
All Android devices need to connect to remoteprovisioning#googleapis#com.
It is part of Google’s Remote Key Provisioning (RKP) infrastructure. GrapheneOS uses a proxy to anonymize the connections. I set up a DNS redirections to the GrapheneOS proxy, so my phones don’t connect directly anymore.
gllto#glpals#com is used get satellite data for GPS. Here I did the same, I set up a DNS redirection to GrapheneOS proxy IP.
But both are not really a privacy concern. Google doesnt’t get any usable data from us.
I wouldn’t be too scared of just connections. Connections can be relatively harmless for security and privacy, or even beneficial. Think blocklists or certificate revocation lists. What’s really important is what these connections are being used for, and what code in your device is messing with them. A proprietary app contacting Google is more worrying than a FOSS app that’s privacy focused.
I don’t think there should be a problem using a VPN on top of the iodé app.
Dear @Kubiac, sorry for a delayed reply. Googleapis connection is totally not needed for proper phone functioning. DivestOS for example hasn’t done it as can bee seen in Kuketz’s articles. I’d rather not use apps which would require Google’s API key.
@lucasmz well, some basic info is transmitted by giving out the IP alone - for example if the phone would connect to Google using my home router without VPN, Google could hypothetically link this piece of data with other data about activity from the same IP address the phone connected from, profiling association between a phone and the IP, or just confirming that a phone is being used - potentially then trying to profile phone activity even if connecting from other IPs afterwards. With the mass surveillance Google and other companies are implementing, an IP can be linked to a household, etc - there are many methods to do this. Big Data is specifically being developed to link data point connections which are almost unlinkable, unrecognizable by a human, milking data out of it useful for surveillance and advertising. AI can profile each of us individually as if everyone has a personal Gestapo agent assigned specifically to them. For these reasons I am for giving Google exactly 0 data points to work with.
On that note, what does update.googleapis.com do? Is this necessary for app updates via Aurora Store?
In iodé app this shows with the (blue) ‘Chromium’ icon curiously (even though Chromium isn’t installed on my device AFAIK) and is listed under the Android System WebView app, which itself sometimes isn’t obvious in the iodé app (see comment below on UI). e.g. I could only find it occasionally via the desktop applet, it’s one of numerous apps it occasionally displays as not having ‘Reinforced’ blocking even though it is reinforced when you look in the normal app.
Anyway I have all 3 of Wi-Fi, Mobile Data and VPN locked down for this app, yet still it’s reaching out to that url above regularly (every few hours)?
P.S. On a different note on the UI side one issue with the iodé app is the layout and design for displaying app names, these are often heavily truncated on some screens so sometimes its not easy to identify an app or see it’s full name initially. You can usually see it once you dig into it (as it will be displayed ion a second location on screen in smaller text), but can be confusing if multiple apps or processes start with the same 1-2 words and have long names.
@Michelle just FWIW I have been using this successfully (iodé app + VPN) for about 2 months on my BraX3 phone with iodéOS.
Connections to firebaseinstallations and remoteprovisioning are a priori, if microG is disabled, related to the google euicc management app which was installed by default (from LineageOS). This app has been replaced by OpenEUICC in all devices except Shift devices where it does not work. So: on a iodéOS phone with microG disabled and OpenEUICC, there should be no connection at all to google.
About Android System Webview. It is an essential part of the system, as many apps use it to display web content. By itself, it just does nothing, but many apps use it as a backend for displaying some content. Some browsers are also based on it, like Jelly, the official LineageOS browser. And, it is effectively based on Chromium. It can be replaced by more privacy-friendly Webview apps, it has been discussed in the forum.
I don’t understand your remark " it’s one of numerous apps it occasionally displays as not having ‘Reinforced’ blocking even though it is reinforced when you look in the normal app" : it is listed in the blocker and its blockings can be controlled, afaik. What do you mean ?
Thanks @vince31fr - appreciate the clarification and explanation.
So what I was referring to is that I have it reinforced in the iodé app and it shows as reinforced. However occasionally, if you access iodé app via the desktop applet (instead of the usual app shortcut) it will list the same Android System Webview entry as orange and flagged not reinforced. I can then go into the iodé app via the normal home screen shortcut immediately and it will instead be blue and say it is reinforced.
Hopefully that makes sense? I would do screen shots to illustrate but I no longer have the desktop applet (I inadvertently removed it), and I am unable to reinstall it on my device as the options to do so are all currently missing (have been discussing with rik separately). So if that gets resolved and I can reinstall it if needed I can monitor for it happening again and screen shot it to illustrate if you need that.