> What evidence does Chrome have that my site is insecure
The fact that it is using HTTP, and therefore can be trivially MITMed by anyone controlling any point traversed between you and the client. Communication between the browser and your server is insecure.
Whether that is an important fact to users is a decision users will need to make, but it is a fact.
> 'What could happen' logic would mean disabling all browsers since you could get pwned by using any of them.
Clearly, to the extent that is accurate, that's not the logic at issue since nothing is being disabled here. So, please, stop with the irrelevant strawmen.
>The fact that it is using HTTP, and therefore can be trivially MITMed by anyone controlling any point traversed between you and the client.
Can you please link to any evidence showing the millions of HTTP sites that were MITMed? I mean after all its so trivial as you claim. OTOH, why would anyone care to do that when they've found it much easier to trivially inject scripts and other potentially harmful stuff via compromised ads, third party hosted JS scripts, compromised CDNs, etc, etc. The current proposal fails to address any of those real, actual, tangible 'bad' things that are actually occuring with alarming frequency.
>Communication between the browser and your server is insecure.
That applies to every single piece of data transfered that is not under the control of the domain being visited.
>Clearly, to the extent that is accurate, that's not the logic at issue since nothing is being disabled here. So, please, stop with the irrelevant strawmen.
Simply asserting it doesn't make it so. I reject your interpretation. The most dominant browser vendor showing scrary yellow triangles with exclamation marks, instead of showing your webpage is exactly like disabling it.
> The most dominant browser vendor showing scrary yellow triangles with exclamation marks, instead of showing your webpage is exactly like disabling it.
No, it'd not, and we know it's not because the much more forceful click-through warnings they used for HTTPS certificate errors (because scary red icons in the address bar failed) still had a high enough click-through rate when the “proceed” link wasn't hidden behind a multi-click process hidden behind an “advanced” button that, well, they invented the multistep, hidden process they use now for certificate errors.
And, anyway, the UI they've shown is simple light grey “Not Secure” text, not a “scary yellow triangle”. It's not anything like blocking, and it's not a blocking attempt that failed because—frommthr experience with certificate errors—they know how much it takes to really stop casual web users from proceeding in the face of a security warning.
The fact that it is using HTTP, and therefore can be trivially MITMed by anyone controlling any point traversed between you and the client. Communication between the browser and your server is insecure.
Whether that is an important fact to users is a decision users will need to make, but it is a fact.
> 'What could happen' logic would mean disabling all browsers since you could get pwned by using any of them.
Clearly, to the extent that is accurate, that's not the logic at issue since nothing is being disabled here. So, please, stop with the irrelevant strawmen.