5 ms·

'Secure' may be flawed, but is 'Private' any better? To me, 'Private' carries the implication that the data is only known by a specific set of people, which doe

'Secure' may be flawed, but is 'Private' any better? To me, 'Private' carries the implication that the data is only known by a specific set of people, which doesn't seem particularly helpful to a user if that set of people isn't verified -- flagging it as 'Private' may mistakenly lead to them thinking it has been. 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?

peterwwillis 9y ago
Private isn't even a valid descriptor. The indicator only shows up on valid encrypted connections signed by a trusted CA. 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".
- mrsteveman1 9y ago
  > 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.
- ams6110 9y ago
  If you think the typical paypal user will understand the difference between "Secure", "Private", and "Encrypted" I would beg to differ. 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.
  - stordoff 9y ago
    But wouldn't doing that be a _huge_ hurdle to Let's Encrypt/certification automation more generally? I'd not sure that would be a net positive.
  - pfg 9y ago
    What are your thoughts on a CA issuing a wildcard certificate for: *.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)?
  - peterwwillis 9y ago
    A CA is just someone who verifies a cert was signed by a key that they know about. Their only purpose is to show your connection wasn't MITM'd. They have nothing to do with figuring out if you're being phished.

peterwwillis 9y ago

Private isn't even a valid descriptor. The indicator only shows up on valid encrypted connections signed by a trusted CA. 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".

mrsteveman1 9y ago
> 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.
ams6110 9y ago
If you think the typical paypal user will understand the difference between "Secure", "Private", and "Encrypted" I would beg to differ. 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.
- stordoff 9y ago
  But wouldn't doing that be a _huge_ hurdle to Let's Encrypt/certification automation more generally? I'd not sure that would be a net positive.
- pfg 9y ago
  What are your thoughts on a CA issuing a wildcard certificate for: *.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)?
- peterwwillis 9y ago
  A CA is just someone who verifies a cert was signed by a key that they know about. Their only purpose is to show your connection wasn't MITM'd. They have nothing to do with figuring out if you're being phished.