There's a very interesting idea at the end of this proposal: that the more-aggressive warnings arrive based on telemetry of the preponderance of secure interactions. By changing over time, and in a manner sensitive to the real mix of user interactions, there's less risk of habituation to "oh, all sites show that warning".
You could even make the switch based not on the entire browsers' usership, but an individual user's recent past. (Not sure this is a good idea, but it's an interesting one.)
> A fair argument, but what's the gradual approach?
Site blacklists (a list of sites that should be secure.) Start with all of the banking and payment sites. Then add in sensitive topics to the person's country (eg atheism, homosexuality, piracy, etc.) The list would work a lot like the phishing/malware blacklist.
If anyone has the algorithms and data for that, it'd be Google. Of course, they'd then risk it being easier for governments to demand browsers block content for them. So it's a double-edged sword.
One possibility for a gradual approach: sites which have both HTTP and HTTPS servers, are marked insecure when user browses to the HTTP version. The knowledge about the presence of both HTTP and HTTPS can be hard-coded for popular websites* and/or inferred from history in the client.
* I mean popular websites that don't send HSTS header, such as reddit.com. Those that send the HSTS header would anyway be subjected to automatic redirection.
PS. We are considering this option in the gngr browser (https://gngr.info). We are also considering going further and not loading the HTTP page automatically. The user would need to press "OK" to proceed.
The idea behind this is to use it as an impetus for sites and services to move to SSL/TLS.