3 ms·

Giving users a false sense of security is absolutely worse than making sure they know there is no security.

by count 12y ago

personZ 12y ago
EDIT: I remain convinced that it is impossible to have any credible security discussion on HN. Everyone just clucks and spouts rhetoric, the Ptacek fan club in full effect. No security solution is absolute, but instead every security approach is a "false sense of security" from some perspective, and every solution is steps on a gradient. Anyone who thinks otherwise is simply naive. Do we eschew SSL rather than give users a "false sense of security"? There are many potential vulnerabilities to SSL, from stealing private keys, to co-opting or compromising root authorities, to more esoteric mathematical vulnerabilities. Yet we still use SSL. We find a pragmatic medium where we achieve the greatest security possible within realistic confines and restrictions, understanding that there are (and always will be) potential weaknesses, and improve as we go. Simply tut-tuting and rote repeating the "false sense of security" nonsense does literally nothing for anyone. It is pseudo-enlightened babble.
- hluska 12y ago
  Though I don't agree with all of it, I like this comment. Your SSL example is excellent. In the context of online shopping, SSL may protect your credit card number in transit, but it can't protect you from keystroke loggers that intercept the information before it is ever encrypted. Yet, the industry still uses it and people are consistently compromised by malicious software. On the other hand, I'm still learning about crypto, so I find these conversations illuminating. Thinking about ways to attack security, or trying to understand how other people approach attacks has given me a far deeper understanding than merely reading about it. However, that's a personal bias because being critical of what I learn is how I learn. Needless to say, I used to routinely drive teachers crazy...
- danielweber 12y ago
  People tsk-tsk'ing security systems as "that won't be perfect, so it will just give users a false sense of security" has been going on for over 20 years. Sometimes it's right, sometimes it's not. I remember being yelled at that anti-spam products were stupid because "I can't stand losing even 1 mail out of 10,000!!" (In reality, email is a lossy system that doesn't have four 9's of reliability anyway.) I heard the same thing about all sorts of products from people in both industry and academia only to watch them become significant parts of the IT world.[1] Nerds like black/white answers, especially about areas where they aren't experts. It makes the world much easier to understand. (And I think it was a stroke of marketing genius for Zimmerman to call his product "Pretty Good Privacy" instead of anything implying perfection.) So I have sympathy for your position here. Still -- the JavaScript runtime is a hell of a place to try to encrypt anything. If your only hope is to add an obfuscation layer, call it that explicitly, and expect support to fall off. Adding more pieces to a system can make it less secure. [1] and I still regret not following up with Dave Mann about his attempts to create a numbering system for attacks because someone else at the table said the AV vendors would never go along
- tptacek 12y ago
  This is a terribly flawed argument because we do not in fact accept "many potential vulnerabilities to SSL". On the contrary, we declare vulnerabilities in SSL that require gigabytes worth of observations for a single target to be "hair on fire" emergencies. On the flip side, we accept staggeringly obvious flaws in the security model of "server-proof" Javascript crypto --- flaws like, "despite what the server operators claim, they can at any time steal secrets from their users --- flaws that have in the past been exploited by law enforcement. Not only we do accept them, but people like you get pissy when people like the "Ptacek fan club" on this thread point them out.
  - count 12y ago
    So, now that there's a fan club, do you have a mailing list or get togethers?!
- count 12y ago
  When SSL gets broken, there are built in mechanisms that generally demonstrate 'something' is being screwed with. With JS crypto, that goes away - if the JS is shipped over the wire, it can just be silently replaced. If you're relying on SSL to protect the JS crypto, why bother with the JS crypto in the first place? When vendors ship some kind of client-side pre-built verification capability (i.e. code that DOES NOT come over the wire), much like the existing SSL stack, things will change dramatically.

Giving users a false sense of security is absolutely worse than making sure they know there is no security.

by count 12y ago

Giving users a false sense of security is absolutely worse than making sure they know there is no security.

EDIT: I remain convinced that it is impossible to have any credible security discussion on HN. Everyone just clucks and spouts rhetoric, the Ptacek fan club in full effect. No security solution is absolute, but instead every security approach is a "false sense of security" from some perspective, and every solution is steps on a gradient. Anyone who thinks otherwise is simply naive. Do we eschew SSL rather than give users a "false sense of security"? There are many potential vulnerabilities to SSL, from stealing private keys, to co-opting or compromising root authorities, to more esoteric mathematical vulnerabilities. Yet we still use SSL. We find a pragmatic medium where we achieve the greatest security possible within realistic confines and restrictions, understanding that there are (and always will be) potential weaknesses, and improve as we go. Simply tut-tuting and rote repeating the "false sense of security" nonsense does literally nothing for anyone. It is pseudo-enlightened babble.

hluska 12y ago
Though I don't agree with all of it, I like this comment. Your SSL example is excellent. In the context of online shopping, SSL may protect your credit card number in transit, but it can't protect you from keystroke loggers that intercept the information before it is ever encrypted. Yet, the industry still uses it and people are consistently compromised by malicious software. On the other hand, I'm still learning about crypto, so I find these conversations illuminating. Thinking about ways to attack security, or trying to understand how other people approach attacks has given me a far deeper understanding than merely reading about it. However, that's a personal bias because being critical of what I learn is how I learn. Needless to say, I used to routinely drive teachers crazy...
danielweber 12y ago
People tsk-tsk'ing security systems as "that won't be perfect, so it will just give users a false sense of security" has been going on for over 20 years. Sometimes it's right, sometimes it's not. I remember being yelled at that anti-spam products were stupid because "I can't stand losing even 1 mail out of 10,000!!" (In reality, email is a lossy system that doesn't have four 9's of reliability anyway.) I heard the same thing about all sorts of products from people in both industry and academia only to watch them become significant parts of the IT world.[1] Nerds like black/white answers, especially about areas where they aren't experts. It makes the world much easier to understand. (And I think it was a stroke of marketing genius for Zimmerman to call his product "Pretty Good Privacy" instead of anything implying perfection.) So I have sympathy for your position here. Still -- the JavaScript runtime is a hell of a place to try to encrypt anything. If your only hope is to add an obfuscation layer, call it that explicitly, and expect support to fall off. Adding more pieces to a system can make it less secure. [1] and I still regret not following up with Dave Mann about his attempts to create a numbering system for attacks because someone else at the table said the AV vendors would never go along
tptacek 12y ago
This is a terribly flawed argument because we do not in fact accept "many potential vulnerabilities to SSL". On the contrary, we declare vulnerabilities in SSL that require gigabytes worth of observations for a single target to be "hair on fire" emergencies. On the flip side, we accept staggeringly obvious flaws in the security model of "server-proof" Javascript crypto --- flaws like, "despite what the server operators claim, they can at any time steal secrets from their users --- flaws that have in the past been exploited by law enforcement. Not only we do accept them, but people like you get pissy when people like the "Ptacek fan club" on this thread point them out.
- count 12y ago
  So, now that there's a fan club, do you have a mailing list or get togethers?!
count 12y ago
When SSL gets broken, there are built in mechanisms that generally demonstrate 'something' is being screwed with. With JS crypto, that goes away - if the JS is shipped over the wire, it can just be silently replaced. If you're relying on SSL to protect the JS crypto, why bother with the JS crypto in the first place? When vendors ship some kind of client-side pre-built verification capability (i.e. code that DOES NOT come over the wire), much like the existing SSL stack, things will change dramatically.