Last week's discussion (here and here) over how there is only one mode, and it is secure, brought forth the delicious contrast with browsing and security: yes, you can do that but it doesn't work well. No, I'm not talking about the logos being cross-sited, but all of the 100 little flaws that you find when you try and do a website for secure purposes.
So why bother? Financial cryptography eats its own medicine, but it doesn't do it for breakfast, lunch and desert. Which reminds me to introduce another of the sub-hypes for critique:
Posted by iang at June 22, 2008 08:13 AM | TrackBack#4.2 Usability Determines the Number of Users Ease of use is the most important determinant to the number of users. Ease of implementation is important, ease of incorporation is also important, and even more important is the ease of use by end-users. This reflects a natural subdivision into several classes of users: implementors, integrators and end-users, each class of which can halt the use of the protocol if they find it ... unusable. As they are laid out serially between you and the marketplace, you have to consider usability to all of them.
The protocol should be designed to be easy to code up, so as to help implementors help integrators help users. It should be designed to be easy to interface to, so as to help integrators help users. It should be designed to be easy to configure, so as to help users get security.
If there are any complex or tricky features, ask yourself whether the benefit is really worth the cost of coder's time. It is not that developers cannot do it, it is simply that they will not do it; nobody has all the time in the world, and a protocol that is twice as long to implement is twice as likely to not get done.
Same for integrators of systems. If the complexity provided by the protocol and the implementation causes X amount of work, and another protocol costs only X/2 then there is a big temptation to switch. Regardless of absolute or theoretical security.
Same for users.
Exactly my point ... usability trumps above everything else. Putting your site on HTTPS makes it a pain to use (red bar , certificate error and all that crap ) .
And additionally, I don't think you achieve anything at all by having a HTTPS , except maybe some sort of idealism that everything should be secure. But that is also lost by having a few images that are not secure. You can't have it both ways!
Exactly my point ... usability trumps above everything else. Putting your site on HTTPS makes it a pain to use (red bar , certificate error and all that crap ) .
And additionally, I don't think you achieve anything at all by having a HTTPS , except maybe some sort of idealism that everything should be secure. But that is also lost by having a few images that are not secure. You can't have it both ways!
@anonymous
If you installed the root cert from www.cacert.org, you wouldn't have any problems using this blog.
The images' not being secure is part of a more general problem with https. I was at a site that displayed a secure iframe from the online order system. Now that may well be secure, but the user is left with no visible indication of security or lack thereof.
Some browsers will warn the user about insecure content displayed on a secure page, but not all of them. And sites like gmail like to mix and match secure and insecure modes. They have you enter your password by https, but then do your e-mail and so forth completely unsecured. What good is it to enter a password via a secure form if a plaintext cookie is used to verify identity once you have logged in?
I feel that to have any hope of security for an https session, a browser should have to obey the following restrictions when visiting a secure site:
* No external content should be displayed or loaded from a secure page, including images, dtds, scripts, frames. All content on a page must be authenticated with the same certificate.
* No form on a secure site should be allowed to post anything to any other site. The POST connection must be authenticated with the same certificate as the source page before any data is sent.
* No cookie that is set via https should ever be presented insecurely or to any other server than the one that set the cookie.
* Exceptions may be made only if the external site has a certificate with a valid chain of trust leading up to a certificate that identifies the original site.
But when people mix and match secure and insecure willy-nilly, the overall security is reduced to the lowest common denominator: insecure.
Posted by: not-so-anonymous at June 27, 2008 11:24 AM