> Users/user agents need to know whether to expect a connection to be secure.
Why not expect it to be secure? Connect to https before http.
Why not expect it to be secure? Connect to https before http.
It would be trivial for any man-in-the-middle to block https and server http.
The main problem is preventing downgrade attacks. With mail it is easy to just remember the setting for every server. Not so with websites.
[1] https://www.agwa.name/blog/post/starttls_considered_harmful
IMHO, the feature would need to be implemented as some have suggested, by enabling any website to transmit securely or insecurely, but for the web browser to request a secure TLS connection first (trying HTTP and HTTPS to reduce incompatibilities) and if a website appeared to have issues, then try insecure connections. If an insecure page were to be served, the browser should indicate this with a broken padlock.
Furthermore, I believe that browsers should warn when any data is input, e.g. clicking items that cause JS calls or text is typed - this strict implementation is important. Single page JS applications have made it possible to send any input data via JSON, we cannot only warn the user on a form submission, since it would be very possible to capture details via AJAX. E.g. If I were impersonating an e-commerce solution, I could hope the user would not notice the padlock and use AJAX to send the data preventing any form submission warnings. This would be annoying for users when they were using such websites regularly, but this would be a good thing - pressuring websites that handle user inputs to act responsibly and use encryption via TLS.
Then it would be good to remember this setting and always pull the HTTPS.