DNS Blocklist for Sandboxed Play Services?

gristle-cause

Been using a firewall to monitor outbound traffic from my GOS device. I've been able to identify & block a handful of trackers & data aggregators from my applications, without breaking functionality

I find myself wondering whether the same process can be applied to the sandboxed Play Services. Is every endpoint absolutely necessary to maintain functionality? Has anyone experimented with this?

For example, I do see aperiodic calls to firebase. I've blocked it, and app functionality remains unaffected. What other connections can safely be blocked?

Core reasoning: every additional piece of data I allow this tech giant to aggregate is a negative. Completely removing Google is the ideal goal, but many GOS users do depend on Play-only softwares. If some small number of unnecessary calls to Google servers can be safely blocked, we're surely moving in the right direction

de0u

gristle-cause Blocking Firebase will stop apps (such as messaging apps) from receiving push notifications.

hemingway

gristle-cause

What do you do when an update to your app or play services changes the domains used for analytics? Doing this via firewall rules sounds like a losing battle but still a hill I'd consider worth dying on if no other option was available. Can you share what firewall you used?

The only other thing I can think of is implementing this via router or pihole with an auto updated domain list that blocks google analytics but not functionally important google servers. This has the disadvantage of not working outside that setup but does such a wonderful list even exist? I couldn't find anything on a search apart from seemingly wip and unreliable lists. The Adaway style filter lists I looked at only appear to contain google tracking domains related to web tracking (and not app analytics) and google ads.

GrouchyGrape

gristle-cause Is every endpoint absolutely necessary to maintain functionality?

No, as you've noticed with certain firebase domains. That being said, just remember that this is ultimately a losing battle. Google could (and may currently, haven't looked for evidence) use "google.com" for all of it's most privacy invasive data "calls to home". Furthermore, they don't have to use DNS at all. They could go straight to their IP.

All of this is still able to be blocked (albeit with likely side effects), but isn't a "cure" for using Google products while avoiding their data collection completely.

I typically just monitor DNS queries as well as traffic flow, then block stuff and see what breaks.

Always remember, if you really want to avoid data collection from a company, the best way is to not use their services.

gristle-cause

de0u imprecise language from my end, apologies. I blocked 'firebaseinstallations.googleapis.com' and 'firebaselogging-pa.googleapis.com', two domains seemingly associated with crash analytics. Neither seems to have broken push notifications, which seem connected with a call to 'mtalk.google.com'

AloofChocolate

de0u If you wish push notifications, stay away from Google, it is all data for them, use an opensource version in Accrescent - Sunup.
Sunup is a small Android application that acts as a distributor for the UnifiedPush ecosystem. Its job is to receive push messages from Mozilla’s Autopush server (the same backend that powers Firefox Push) and then forward those messages to any Android app on the device that implements the UnifiedPush protocol.

gristle-cause

hemingway Can you share what firewall you used?

RethinkDNS, on device. I spend most of my day outside my LAN, so I can't reliably manage this at the network firewall

hemingway What do you do when an update to your app or play services changes the domains used for analytics?
GrouchyGrape Google could (and may currently, haven't looked for evidence) use "google.com" for all of it's most privacy invasive data "calls to home"

This is a concern, one I don't know how much to weight. Currently, Play Services seems to be using over 50 domain endpoints for communication. I don't know how frequently we should expect these to change, if ever

mmobder

This overall process is very time-consuming and severely affects user experience.
Just apply Hagezi's Ultimate and no google, and then whitelist those really required PER-APP and not globaly.

Re firebaseinstallations, firebaseremoteconfig, firebaseinappmessaging - it highly depends on set of your aps.
For example, apps that are built on top of google maps (navigations, etc), will most likely fail if you block it globally, as at least from my impression, a connection to firebaseinstallations and/or firebaseremoteconfig is done to obtain something that finally enables further connections to clients4.google.com (clients3.google.com, etc) where it seems map tiles are fetched from.

gristle-cause

mmobder it highly depends on set of your aps.
For example, apps that are built on top of google maps (navigations, etc), will most likely fail if you block it globally

Absolutely dependent on your particular apps. The small number I run seem to leverage per-app calls to their personal servers for maps. I see very little cross-communication with Play

gristle-cause

mmobder Just apply Hagezi's Ultimate and no google, and then whitelist those really required PER-APP and not globaly.

This is ultimately the exact same process, just inverted. The NoGoogle Blocklist will absolutely break Play. You'll still need to work through Play's outbound calls, tweak with the firewall, and build a list of necessary endpoints

Makalratlor

mmobder Just apply Hagezi's Ultimate and no google, and then whitelist those really required PER-APP and not globaly.

For some reason despite being a Google hater who wants distance as much as possible I never quite considered just blocking everything then just maintaining allowing ones I need and blocking new ones I don't need. That would be considerably easier. I immediately enabled the no Google list lol.

hemingway I can't think of a way to effectively do this without some sort of hosts file which isn't supported by GOS.

The safest way that is also considered one of the most effective is generally to use android's Private DNS feature with a filtering DNS server of your choice.

Provided you don't self host your own there are relatively private services out there like NextDNS that allow you to achieve the same thing. This is the safest way to achieve this as a DNS provider is something you already have to use and trust anyways. That and a there's a good amount of ISPs out there that don't have good DNS offerings so you are in most cases probably better off picking a third party DNS provider anyways (some notable exceptions would include if you have a very high threat model or use a VPN or Tor especially Tor.)

I use NextDNS primarily due to it being a solution that is compatible with basically every modern day device (due to it being a DNS server with plenty of compatible options and protocols) and given that I can update it from one area and have my changes reflected on all devices that helps a lot with friction.

hemingway

gristle-cause This is a concern, one I don't know how much to weight

Well it certainly is something to consider. No matter how you manage to implement this, can a single instance of internet access to an analytics server undo 100% of your hard work? It's conceiavable (imo a certainty) that at some point, the firewall or DNS rules will be out of date and let something through.

Imho it's probably better to prioritize degoogling your phone, and an important step in that is to replace apps that communicate with google with alternatives that don't. Then for the handful of apps that remain, you can try to curtail unwanted communications. I can't think of a way to effectively do this without some sort of hosts file which isn't supported by GOS.

Another route would have been to use something like app manager that allows you to disable analytics related activities on the app but iirc that function requires root, also not (easily) achievable on GOS.

mmobder

gristle-cause servers for maps

Ah, ok, so that's not google maps then, easy).

Ok, coming back to my experience - I put apps into Isolate (by default they're blocked by rdns upon installation), then whitelist required domains. In combination with on-device Hagezi Ultimate and upstream nextdns (on-device rdns blocklists help not to exceed the quota and reduce network/battery use).
Seems OK so far, though efforts-hungry at initial stage.

Play services are blocked in rdns, but have mapsmobilesdks-pa.googleapis.com preconfigured in whitelist for cases I install new app that asks for gmaps. Play store is just blocked.

mmobder

gristle-cause The NoGoogle Blocklist will absolutely break Play.

Not in my experience, however, at this stage of de-googling, I'm not heavily dependent on gapps and I don't rely on push services.
A lot of Play store apps will handle broken calls to all those logging and other facilities just fine, though complaining sometimes.
The only hassle for me are apps that embed google maps, where mapsmobilesdks-pa.googleapis.com has to be whitelisted.
Luckily, Waze navigation works in a different way, so I can live with other apps now showing maps.

mmobder

hemingway the firewall or DNS rules will be out of date and let something through.

That's where per-app whitelist comes of help, though at the cost of maintaining it (that is not high for relatively stable apps). No guarantee though that apps aren't smart enough at least in case of big corps to embed at least some of native analitycs into "core" domains like those *.googlevideo.com domains that serves yt's video streams.

mmobder

hemingway can't think of a way to effectively do this without some sort of hosts file which isn't supported by GOS

rethinkdns helps with that, though, as a majority of small community/foss apps is not prone of errors and may theoretically leak something because of misconfiguration and scarce resources to ensure quality of releases.

GrouchyGrape

AloofChocolate not all apps support alternative push services

de0u

AloofChocolate Sunup is a small Android application that acts as a distributor for the UnifiedPush ecosystem. Its job is to receive push messages from Mozilla’s Autopush server (the same backend that powers Firefox Push) and then forward those messages to any Android app on the device that implements the UnifiedPush protocol.

My sense is that some on-device client apps do support UnifiedPush and some don't... how many app servers are set up to use Mozilla Autopush?

gristle-cause

Update: I have successfully limited outbound connections from GOS sandboxed Google to the bare minimum for my needs

My use case: PStore to download apps & updates, retain FCM push notifications for my Play apps & RCS on GMessages. Here are my tested, required connections for:

PStore:

play-fe.googleapis.com (store frontend server)
play.googleapis.com
connectivitycheck.gstatic.com
*.gvt1.com (CDN for app & update downloads)

PServices:

mtalk.google.com (FCM Push Notifications)
play.googleapis.com
android.googleapis.com
android.apis.google.com
time.google.com

I won't detail the GMessages domains, as they are all using a CDN with region-specific subdomain prefixes that will need to be tailored per user. I will say that I cut it down to four servers - three for RCS, one for general messaging

Likewise, traveling around may connect you to different servers on a CDN, these domains may only apply to my locality.

All other endpoints have been blocked, and my apps continue to work fully-featured. Be aware, your mileage may vary. As was mentioned earlier in the thread, if your apps demand different services from Google than mine (for example, mine are not calling GMaps at all), you will undoubtably need additional connections

I do not know whether this self-imposed whitelist accomplishes anything meaningful, as I ultimately dont have any eyes on the contents of remaining communication. But I feel accomplished, so I now rest easy

Fuck you Google. Don't be evil

AloofChocolate

gristle-cause "Fuck you Google. Don't be evil" There motto years ago Don't be evil, how times have changed.

gristle-cause

gristle-cause update2: If Play Protect scanning is on, PStore will also need to reach 'android.apis.google.com'

hemingway

gristle-cause I have successfully limited outbound connections from GOS sandboxed Google to the bare minimum for my needs

Glad you got results!. Ima steal your setup and try to improve upon it when I have time.

Sindbad

gristle-cause
Thanks for that list! I also started whitelisting single Google domains based on your findings.
Could you make an example "GMessages domains" for RCS and general messaging? I'm not finding them in my DNS logs.

Also do you think following domains are required for Play Store?

playstoregatewayadapter-pa.googleapis.com
prod-lt-playstoregatewayadapter-pa.googleapis.com

AloofChocolate

de0u https://unifiedpush.org/