Did it make you feel safe knowing that it went straight to https? I know PayPal has a login screen on their homepage so maybe that is the reason they make you go straight to https?
No. I think the HTTPS in the browser prompts a user to think there is confidential information being passed when your just browsing, so now your break user experience. The app portion could be, and should be for any semi-secret information, but keep the front-end clear of it. Plus any and all external resources in-page must be https, it might hang you or a designer up down the road and break your cert.
I disagree. I might not spring for an EV cert in most cases, but using basic encryption to protect against casual eavesdropping should be the rule, not the exception.
I am 100% with that mentality, I guess I just see the overhead and understanding of HTTPS causing more problems in practice than solutions for developers who are not security-centric. Think we'll ever see google.com go to SSL?
It's very interesting to me that when SSL opens up, you immediately feel like confidential information information is going to be passed (which is usually the case).. I didn't think about that before!
The app portion is def. protected by SSL and switches to that context when you hit the login path.
Your last point is interesting too, as we do pull in external resources such as google fonts, jquery (google's CDN), analytics, etc. but have managed to find an SSL version of those URL's too (luckily). I do see this becoming painful for designers moving forward though when they're trying to pull in external resources that lack support for https url's.
All very good points.
Do you think the average user notices the SSL activation bar?
Yea, luckily nearly every major API and service (Amazon, Facebook, Google..) has an encrypted version to pull from. So as long as the entire team understands that, then I only have the usability issue as an argument. If we could get GoDaddy and other hosts to have like a $10 "Add SSL" feature, I think we would see a really good adoption of it being the standard!
This is a good question! I have no idea. I know that there are sites that do run behind SSL (like paypal) and their pages seem to appear on google just fine. As far as how this impacts your PR, I have no idea.
Encrypting site content increases server load, so response time may lack a little.. and we all know Google does take that into account. Also, it might be important that robot files and sitemaps are under the https protocol. I am guessing Google is pretty darn smart about it, I can only imagine though that a broken certificate throws a red flag.
Ha! Interesting.. I wonder if Google does count that against you since part of their latest algorithm factors in page load times.. though I would think that having your site behind https might give you some extra kudos somewhere.. considering you verified the integrity of your site at least.. (ALTHOUGH, there was that recent security breach where we someone can spoof being a CA...)
We had some issues integrating 3rd party systems, such as the Twitter button, which has had an invalid certificate for months now. If your site can live without these bells & whistles, then you should investigate and see if your site can take the performance hit.
22 comments
[ 3.8 ms ] story [ 60.9 ms ] threadIt's very interesting to me that when SSL opens up, you immediately feel like confidential information information is going to be passed (which is usually the case).. I didn't think about that before!
The app portion is def. protected by SSL and switches to that context when you hit the login path.
Your last point is interesting too, as we do pull in external resources such as google fonts, jquery (google's CDN), analytics, etc. but have managed to find an SSL version of those URL's too (luckily). I do see this becoming painful for designers moving forward though when they're trying to pull in external resources that lack support for https url's.
All very good points.
Do you think the average user notices the SSL activation bar?
http://platform.twitter.com/widgets.js vs https://platform.twitter.com/widgets.js
Luckily, we don't use that js, we use:
http://twitter.com/javascripts/blogger.js
and I just checked the certificate behind this and it's valid (I should hope twitter's main cert is valid!):
https://twitter.com/javascripts/blogger.js
and we use the json API:
http://api.twitter.com/statuses/user_timeline/healpay.json?c...
which also happens to have a valid cert:
https://api.twitter.com/statuses/user_timeline/healpay.json?...
So it looks like we're in the clear for this at least :)