Using google.com/XXX for all its services protect the user from being spied by external actors such as ISP because everything is hidden behind HTTPS.
Whereas, with XXX.google.com, external actors knows that you are using service XXX.
Regarding the privacy:
If you are using a VPN to protect your privacy, then you are effectively transferring your trust from your ISP to your VPN provider. The VPN provider is your new ISP. So you have to make sure you trust the VPN provider more than your ISP.
In my town there are 2 ISP I can choose to trust, whereas with VPN I can choose to trust from a much greater selection.
As other mentioned, OSM is an alternative (not equivalent) of Google Maps.
https://framapad.org/abc/ (this organisation has a lot of FLOSS cloud alternatives to Google products)
Unfortunately it seems there is only text editing, not spreadsheets or forms (those I use a lot)
But I'll look into it, and probably transfer my docs there
It is important to use user respecting software when we can :)
has everybody forgotten it was replacing Microsoft?
google.com/maps would result in a DNS request for google.com so anyone monitoring DNS would know they are connecting to a google service but wouldn't know which one.
maps.google.com would result in a DNS request that show they are connecting to maps.google.com and could presume they want some maps.
DoH (and ESNI on the server side) would fix it, but iirc Chrome (the most used browser) doesn't use DoH by default.
Should a browser override system settings? That’s another question, because doing so can impact other things for the avg Joe. For example my mobile providers self serve website plays up when I use custom DNS, free hotspots with captive portals also can be an issue when you override the DNS provided by the access point.
If you want to solve unsafe defaults, this is not the way. Pushing for configuring safe defaults is.
Spock was right, logic clearly dictates that the needs of the many outweigh the needs of the few.
However I believe (not read the docs in a while) FireFox works around this by falling back to DNS if an issue with DoH is detected.
EDIT: However I'm still on the fence if it should be a browser decision. Yes browsers move more quickly then OS & ISP changes and can make things better for the masses quickly, but i'm also wary of those changes screwing up the avg person, the people like my mother who can just about order things online via her ipad but thats about it, if she accidentally lowers the screen brightness of her ipad I soon get a call about it. Its for those kind of people I don't like the idea of a browser messing around with a connection in unknown network conditions.
This statement makes a huge assumption, that the DoH provider is more trustworthy than your existing DNS provider. Personally, I trust my ISP (Small, locally owned) with my query history than I trust Google (Massive, exploitative advertising company). The fact that Google is automatically turning this on to scoop up DNS information without users consent should be illegal.
It would fix it for some specific circumstances. Since maps.google.com resolves differently than www.google.com, you can ignore DNS and just look at TCP connections to tell what service is being talked to.
If make a http get request to 142.250.179.238/ (the maps IP) but with the host header set to "www.google.com" I get the search page returned to me. If I make a http get request to 142.250.200.14/maps I get google maps.
OK. /maps might be a bad example because well google.com/maps is already a thing :-p
So if I make a request to 142.250.179.238 with the host youtube.com I get youtube. This is because most of googles public facing servers can act as the front door for many other google services not just the service that its dns is set to.
Not really sure it it comes under "domain fronting" because isn't that tactic many used to bypass censorship, pretend your connecting to one CloudFront customer when really wish to connect to another. Where google explictly configured their services to do this so they can easily load balance as demand and network conditions allow. Anyways I'm rambling now.
My point is, with google you can't rely on the ip address alone to determine the service (however it still wouldn't stop you peeking into connection and pulling out the host header unless ESNI was used) but as I said at the start, Google is more the exception here.
Last I checked, Linux was behind other platforms because there’s a lot of complex custom dns configuration that chrome (understandably) didn’t want to be accused of overriding/ignoring, but which isn’t all easily visible to the browser
Even if the computer is using 53/udp to the configured local resolver in the local network, it doesn't mean that the resolver itself is using 53/udp. Many of them can forward queries using DoT/DoH/IPoAC and the app on the users computer will be none the wiser.
My prosumer grade harder does DPI without any issue.