> > Wrong- this is a matter of protecting the user. I may have a site that > doesn't deal with anything important. Let's say it allows users to see > their friends' baby pictures. They need to login so that we know what > babies to show. Session gets hijacked? Big deal, you can see someone else's > babies. But half the users are gonna use the same password they use for > their paypal account. Should they have? no. But you don't want to be the > vector by which that stuff happens. > > That's the kind of "netiquette" I was talking about. Web developers should "apply the netiquette", so it would be less probable that the password gets leaked (and users are happy) .
> 2) It's a cpu issue > > I can't follow your conclusion here. You say it's not important in 2012, > and yet Facebook still defaults to it and WordPress continues to offer it. > It may not be a good trade off in most cases, but it's certainly common > practice. I think we're still missing something here... > > Facebook runs how many server ? Given that content on facebook is not so precious, and that privacy was never a big issue for them, they save some buck on plain navigation vs ssl. Wordpress is not recommending that, it's giving you a choice. Wordpress runs for the 80% of the time a relatively small site on a supercrowded shared hosting scenario. SSL navigation shouldn't be slower, but crowded server are the majority of the cases where Wordpress runs, so its common to see a certain "limitation" using those providers together with a SSL certificate. I think the point you're missing from my post before is related to the "lack" of coverage for python shared-hosting that could pose the same problem in terms of "slower" response times. Given that normally web2py apps runs on VPS in the worst case scenario, the CPU time "wasted" in SSL protection is negligible. 4) Mixed content issue > > Mixed content is not always a choice. If you pull images hosted on other > HTTP sites, boom, you're stuck with mixed content, and some browsers don't > handle it elegantly. IE throws a pop up in your face. Chrome shows a > warning indicator on all your HTTPS pages in a session if just one page has > mixed content. > Yep. This is kind of frustrating. But has a logic: an URL "with padlock" doesn't necessary mean that all the data the user sees (and exchange, e.g. posting a form) is secured. We (web developers) know that ajax, iframe, images and recently websockets can exchange data "out of band" in regards of SSL protection, "normal" users don't. Some browsers alert the user of this fact, some browsers not. Some sites "proxy" the content served to "avoid" the itchy browsers "popups", some sites don't. It's just a matter of "visions". 5) Still don't understand your PS. Can't tell if you're talking about user > perception or actual DNS poisoning, but the first point is out of scope I > think- my concern is that WE know what is secure- I'm not counting on the > user to know or care. As for the latter, I still don't see how the scenario > is any different if both case-1 and case-2 require a user to be redirected > to https://example.com/login if they type in http://example.com/login. > lost me on this one. > Well, both. Your point is "don't let the users give away their passwords on my site": ok, I get that point. But, e.g. with DNS poisoning: your pages shows up in the google search results. User clicks on "https://example.com/yarin/baby_pictures (login to see Yarin's baby pictures)" and are instead connected to an evil Niphlod's hosted https://example.com/yarin/baby_pictures. When browsing to Niphlod's hosted, they get a warning about a certificate mismatch, while on Yarin's one all goes fine. Without SSL, your users are giving passwords away to Niphlod. User perception: "hey, it had a padlock all the time, why this time there is no padlock?" . This has more impact in users mind than checking if https is enabled only in the login page. Explicit redirection make your site "protected" without caring on the web2py side, if you are on a "production" webserver. Beware that you can force redirect to https only for "sections" of your site (e.g., the login page, assuming you're still fine with that). If you run web2py behind a webserver with that "restriction", your code doesn't have to deal with checking if SSL is enabled or not. Another fine addition is that in modern browsers (and cellphones, and tablets) if you type "example.com" you are "pointed" to http://example.com. Having to type https:// is a loss of time for desktop users (see all the madness regarding short urls) and a little cumbersome on "touch keyboards" on small devices. @Yarin and all: at the end of the "speech", still Yarin's suggestion to make case-1 more achievable by web2py is good. --
