Also, what does this mean for EV certs if Chrome is training users to look for 'Secure'? Given that EV certs don't display that, does it reduce trust in them?
Also, what does this mean for EV certs if Chrome is training users to look for 'Secure'? Given that EV certs don't display that, does it reduce trust in them?
It does not ensure privacy. It ensures encryption. Technically, the data is obscured, but it is not private. Private would mean nobody knows what is going on. But anyone with a passive traffic sniffer and some machine learning algorithms can determine your client, your OS, your network, and what websites you are browsing over HTTPS.
A valid descriptor would be "Encrypted".
Someone should conduct a poll with a mockup of a URL bar that says "Encrypted" instead, asking a wide variety of users to describe what it means.
When users look at that part of the URL bar, there's an implicit question being asked of the UI.
Describing a URL as "Secure", "Private", or even "Encrypted" is a partial answer, users will infer the rest and they'll get it wrong a lot of the time.
CAs who issue certificates for clearly fraudulent domains like paypal.com.removed-limits.com are the problem. Anyone signing a CSR like that should be blacklisted in all the browsers.
*.com.removed-limits.com
Blocking the string "paypal" would prevent issuance for phishing sites for maybe a day. After that, they'd have all migrated to "payypal" or "paypel", which would still be more than sufficient. And if that stops working too, well, good luck with wildcards!Not to mention that in an HTTPS-only world, CAs would have full control over which domains are permitted on the web. Is introducing a semi-centralized content police really a good trade-off just to prevent phishing, or shouldn't we look into how we can prevent phishing using other means (U2F, webauthn) and focus on moving to negative-only security indicators (where HTTPS becomes the default, with no security indicator)?
They have nothing to do with figuring out if you're being phished.