8 ms·

This is a great idea, but I wonder how far you can go with it. Could you also change the lock icon when larger more secure keys are used? Could you perhaps ha

by jlgreco 13y ago

This is a great idea, but I wonder how far you can go with it. Could you also change the lock icon when larger more secure keys are used? Could you perhaps have the lock icon change color between a continuum of red to green (or better, black to white, or something accessible to colorblind people) depending on how the site is set up?

dllthomas 13y ago
Probably it should be a rolling standard, based on current best-practices.
- jlgreco 13y ago
  I was thinking it would be up to the browser vendor to decide how to rate things, but if there were a more formal system that would be great I think.
  - dllthomas 13y ago
    Oh, I'd just meant "standard" in the "something against which you measure things" sense, and had been thinking per-browser, but I agree that some industry-wide coordination would be fantastic, if done right. Probably an industry-wide lower bound, with individual browsers allowed to require more security for a given marking, would be best.
Skalman 13y ago
Assuming you're sarcastic, but don't you think it's right to punish sites that don't use the best encryption strategies? I'd support three stages: 1) no encryption, 2) some/partial encryption, 3) "perfect" encryption. For the partial encryption, the browser would provide an explanation of exactly how it could be compromised. For the case where the encrypted version does not have perfect forward secrecy, it could explain that if the server is compromised, this session can also be decrypted. I don't think browsers should cover the banks' asses here. Edit (since I can't reply deeper): I thought you were being sarcastic since I consider a gradient to be a really horrible idea. I'd want something where the browser tells me something. I don't want to wonder whether the new browser version changed the gradients slightly or a site improved its encryption strategy. Clear symbols and language is a must.
- jlgreco 13y ago
  I'm not being sarcastic, I think this is a good idea. I probably came off wrong because half-way through writing my comment I actually changed my mind, I guess my tone leaked through though.
roc 13y ago
People are not going to pay attention to a color-coded internet-weather-report sort of icon. But maybe if you switched the iconography/expectation: use a 'person' icon, instead of the lock, for vanilla SSL. It would indicate you have verified the server's identity -- which is not nothing -- but you can reserve the lock icon for forward-secure servers.
- jlgreco 13y ago
  The problem of getting users who don't care to care is probably unsolvable without destroying usability. I think providing information nicely to people who care about it is the next best thing to shoot for.
  - roc 13y ago
    I don't think it's about users not caring at all. It's more about the limit to which they can add yet-another nuanced technology/security concern to their life and work and then keep up with it as times change. [1] We've got a question of granularity [2] and rather than make a professional value judgment in the average user's best interests [3], the proposal is trying to represent the entire scale and then expect the user to educate themselves about what the scale means, compare that to their environment needs, etc. [1] How long ago was it, we were simply railing against insufficient key sizes or improper certificate validation? Anyone who 'learned' up to that day's wisdom would have to continually update their knowledge along with the rest of us to be able to make informed decisions on which colors were 'safe' for which uses. [2] 'how secure' on a scale from 'unsecure' to 'SSL' to 'perfect forward secrecy' [3] drawing a line on the scale, to the left of which is not secure and to the right of which is secure. And, when 'less-secure' options prevent valuable information that isn't necessarily 'security' (e.g. identity validation) using a clear method of distinguishing that.

by jlgreco 13y ago

dllthomas 13y ago

Probably it should be a rolling standard, based on current best-practices.

jlgreco 13y ago
I was thinking it would be up to the browser vendor to decide how to rate things, but if there were a more formal system that would be great I think.
- dllthomas 13y ago
  Oh, I'd just meant "standard" in the "something against which you measure things" sense, and had been thinking per-browser, but I agree that some industry-wide coordination would be fantastic, if done right. Probably an industry-wide lower bound, with individual browsers allowed to require more security for a given marking, would be best.

Skalman 13y ago

Assuming you're sarcastic, but don't you think it's right to punish sites that don't use the best encryption strategies? I'd support three stages: 1) no encryption, 2) some/partial encryption, 3) "perfect" encryption. For the partial encryption, the browser would provide an explanation of exactly how it could be compromised. For the case where the encrypted version does not have perfect forward secrecy, it could explain that if the server is compromised, this session can also be decrypted. I don't think browsers should cover the banks' asses here. Edit (since I can't reply deeper): I thought you were being sarcastic since I consider a gradient to be a really horrible idea. I'd want something where the browser tells me something. I don't want to wonder whether the new browser version changed the gradients slightly or a site improved its encryption strategy. Clear symbols and language is a must.

jlgreco 13y ago
I'm not being sarcastic, I think this is a good idea. I probably came off wrong because half-way through writing my comment I actually changed my mind, I guess my tone leaked through though.

roc 13y ago

People are not going to pay attention to a color-coded internet-weather-report sort of icon. But maybe if you switched the iconography/expectation: use a 'person' icon, instead of the lock, for vanilla SSL. It would indicate you have verified the server's identity -- which is not nothing -- but you can reserve the lock icon for forward-secure servers.

jlgreco 13y ago
The problem of getting users who don't care to care is probably unsolvable without destroying usability. I think providing information nicely to people who care about it is the next best thing to shoot for.
- roc 13y ago
  I don't think it's about users not caring at all. It's more about the limit to which they can add yet-another nuanced technology/security concern to their life and work and then keep up with it as times change. [1] We've got a question of granularity [2] and rather than make a professional value judgment in the average user's best interests [3], the proposal is trying to represent the entire scale and then expect the user to educate themselves about what the scale means, compare that to their environment needs, etc. [1] How long ago was it, we were simply railing against insufficient key sizes or improper certificate validation? Anyone who 'learned' up to that day's wisdom would have to continually update their knowledge along with the rest of us to be able to make informed decisions on which colors were 'safe' for which uses. [2] 'how secure' on a scale from 'unsecure' to 'SSL' to 'perfect forward secrecy' [3] drawing a line on the scale, to the left of which is not secure and to the right of which is secure. And, when 'less-secure' options prevent valuable information that isn't necessarily 'security' (e.g. identity validation) using a clear method of distinguishing that.