I was going through the firewall whitelisting required for the service because I noticed Apple TVs haven't checked in in years; when I noticed the list for the domains required for the services is broader than before, and it's not in the dedicated port but on the general HTTPS port, and most of the domains in the case of Android devices (which I also manage) are Google's general public tracking and data collection domains.

I'm not comfortable whitelisting vague multi-purpose domains such as googleapis.com, gstatic.om, domains that leave little doubt they're not good for users e.g. google-analytics.com, or domains that are used by other unrelated Google e.g. gvt1.com, googleusercontent.com, generally associated with nothing useful.

That's not the only issue with this list, since the beginning it's had wildcards in it. {IF ANYBODY AT MANAGEENGINE IS READING} You need to be more specific and much more transparent. Use your power to pressure Google into disclosing more information if you don't have it either. There is no firewall that can't block or allow those addresses because firewalls do not operate in that layer. When a block is added on a domain, I'm sure you must know that the domain is preemptively resolved, so it can be blocked later at layer 3, on its IP addresses, there's no way it can preempt wildcard matching addresses.

It would need to be inspecting DNS requests as well, and block it at that layer, or if it's more thorough — which it should given encrypted DNS can potentially bypass it nevertheless — inspect the DNS request, match it with its local filter where the wildcard could only be matched, resolve the actual request now that it has a matching domain, dynamically create the rule for it, and finally optimize the rule set, which is a processor-demanding process. It's too much burden. In many network, because of security, or due to things like Active Directory, or due to the fact that each of these filters need to be powerful, and thus too big to be integrated on a single system.

Documenting a wildcard and calling it a day is irresponsible, specially when the target audience is the subscribers of a cloud service, which very likely mean they don't have their own infrastructure. No data center, server rooms, probably not even a server/broom closet to speak of.

On my on device which is on MDM and rooted, I block Firebase along with a few more of those domains and it connects fine to MDM Plus, policies can be pushed to it, nothing has failed so far despite the list of in-device blocks is quite extensive. So, I'm confident things in that article (https://www.manageengine.com/mobile-device-management/faq.html > "Configure MDM" > points 1 and 2) aren't stricly needed. MDM is already [extremely] invasive enough, please clarify.