Can't the argument be made that if you are a startup and have launched a product to test the market, it would take up too much developer time to think about https? Depending on the nature of the service, shouldn't you defer the extra effort until only after you've validated the product/market fit?
Well, the contradictory argument can be made as well: If you're a start-up, and your early adopters get annoyed because someone made sure Firesheep works with your web site, and they're all getting pranked, they're going to decide they won't bother.
OTOH, I am writing this comment on an open wireless router.
On the gripping hand, nothing I put here is private, and if someone "pranks" me, I can just login again and delete offensive content. Karma isn't actually money...
Your local network admin, your ISP, any ad networks your ISP has or will have arrangements with and your government can log all the websites you visit and build profiles of you because https isn't used everywhere.
This might not bother you individually, today. But maybe it will cause problems for you in the future if laws change? Maybe it is causing problems for a lot of people who aren't you today? Maybe it is causing problems for citizens in countries other than yours?
The World would be better off if https was used everywhere.
Surely you're understating the time? 15 minutes sounds like the "happy path" estimate. Don't you have to think about mixed content and other edge cases? Or do these just not come up that often?
It's obviously going to be easiest if you do it from the beginning, but even retrofitting won't be a huge issue. It's probably also easier if you secure your entire site rather than piecemeal (like just for logins).
I actually did it last night, from yum install httpd to (self-signed) SSL in less than 15 minutes. There are some webapp considerations, but they are negligible when compared to other security efforts like XSS diligence.
Comments
"everyone should be using HTTPS"
Can't the argument be made that if you are a startup and have launched a product to test the market, it would take up too much developer time to think about https? Depending on the nature of the service, shouldn't you defer the extra effort until only after you've validated the product/market fit?
Well, the contradictory argument can be made as well: If you're a start-up, and your early adopters get annoyed because someone made sure Firesheep works with your web site, and they're all getting pranked, they're going to decide they won't bother.
OTOH, I am writing this comment on an open wireless router.
On the gripping hand, nothing I put here is private, and if someone "pranks" me, I can just login again and delete offensive content. Karma isn't actually money...
Your local network admin, your ISP, any ad networks your ISP has or will have arrangements with and your government can log all the websites you visit and build profiles of you because https isn't used everywhere.
This might not bother you individually, today. But maybe it will cause problems for you in the future if laws change? Maybe it is causing problems for a lot of people who aren't you today? Maybe it is causing problems for citizens in countries other than yours?
The World would be better off if https was used everywhere.
It's $12 and 15 minutes, not a big investment.
Surely you're understating the time? 15 minutes sounds like the "happy path" estimate. Don't you have to think about mixed content and other edge cases? Or do these just not come up that often?
It's obviously going to be easiest if you do it from the beginning, but even retrofitting won't be a huge issue. It's probably also easier if you secure your entire site rather than piecemeal (like just for logins).
I actually did it last night, from yum install httpd to (self-signed) SSL in less than 15 minutes. There are some webapp considerations, but they are negligible when compared to other security efforts like XSS diligence.