Re: Proposal: Marking HTTP As Non-Secure

First of all, some change along these lines is absolutely necessary is it 
closes a huge hole that has been successfully exploited since the Netscape 
days. That is, while browsers indicate positive security for TLS, they make 
no indication at all in the case no security, leaving ample room for 
website content to fill that void. Call this the "Green padlock favicon" 
problem if you like. 

Some notable points:

Given these roughly 3 distinct scenarios with respect to connection status:

A: The connection is successfully secured. (HTTPS)
B: No security was attempted. (HTTP)
C: Securing the connection has failed. (Certificate validation failure)

A few people have said that B and C are roughly identical from a security 
perspective and could be represented as the same state -- in both cases no 
security is provided. I would disagree here. In the case of the failed 
certificate verification, the client has attempted to secure the connection 
and that attempt has failed. In the case of HTTP, the client made no 
indication of a preference for security. While scenario B represents the 
*absence* of security, scenario C represents the *failure* of security, and 
is therefore more troublesome. While we want to raise the awareness of 
scenario B, we shouldn't promote it to the severity of scenario C. Doing so 
conflates two very different cases and failure modes; while both represent 
the absence of verifiable transport security, the latter indicates that the 
user's expressed expectation of security has not been met, while the former 
simply reflects the absence of any expectation of security.

With respect to EV vs DV/DANE certificates, that discussion should be 
completely separate from this. No further comment necessary.

Finally, it's worth noting that reports from the field in response to the 
Chrome SHA-1 sunsetting initiative have shown that even the most minor of 
warnings has a measurable impact on site operators. I've received many 
reports from operators large and small indicating visible losses of revenue 
due to the nearly-hidden warning Chrome currently displays for a SHA-1 cert 
with a long expiration. This suggests that the UX changes surrounding 
security needn't initially be intrusive to have a strong impact on site 
operations. An unobtrusive but centrally-located notice to the effect of 
"your connection has not been secured" is indisputably accurate, conveys no 
bias or agenda, and yet can be expected to produce a sea-change of behavior 
for site operators. 

It's like bike locks: they're functional and highly visible, but also 
optional. Still, if one day someone started putting up signs saying "this 
bike has no lock", even though it's telling you nothing you couldn't 
already see, behavior would immediately change.