The info "is https available" is not secured either. The ISP can just block any packet on port 443 and force http that way. It would break links but wouldn't break people entering the address via the URL bar.
A real improvement in security would be Google caching the data, and either offering it via a custom API or just signing it and appending it to their 8.8.8.8 DNS responses. Per default, Chrome already sends the URL to Google as you type, you have to turn auto complete off if you don't want it to happen.
Right, as long as it falls back to HTTP, you don't really increase security. And if you have a side-channel like preloaded HSTS lists the change does not apply. So you're right, it just makes HTTPS sites load faster.
Hmm so I thought about it a little and I think the old way allows passive monitoring of the URL within the website while the new way requires active attacks to enable this.
We're not talking about preloaded HSTS. In such cases this change makes zero difference; Chrome already would have made the initial connection over HTTPS.
And it doesn't matter whether the legitimate server is refusing to serve plaintext HTTP if you're not talking to the legitimate server in the first place. The attacker can serve whatever they want.
Unfortunately, you can't be on the HSTS preload lists and have all newer browsers enforce HTTPS while still having a HTTP fallback for legacy systems. In genereal, the backwards compatibility story with HTTPS has been abysmal - it should have never been a new port or URL scheme in the first place.
Theoretically ISP can provide a transparent proxy to translate HTTPS to HTTP (but with some feature degradation). It could happen in restricted countries.
A real improvement in security would be Google caching the data, and either offering it via a custom API or just signing it and appending it to their 8.8.8.8 DNS responses. Per default, Chrome already sends the URL to Google as you type, you have to turn auto complete off if you don't want it to happen.