Facebook Fails at https(musiform.tumblr.com) |
Facebook Fails at https(musiform.tumblr.com) |
Not until they saw a demonstration video did they believe that it was as bad as I was telling them it was. It is hilarious as a security guy watching "new" exploits come out and watching them go into serious mode since this is a new exploit and it is a bad one and it is going to cause doom and whatnot.
If you can't trust the connection you are on, then time to not use said connection or VPN somewhere. Plenty of places to find hosted VPN services.
Care to recommend one? I've had a few unsatisfactory experiences (terrible bandwidth, unreliable servers, etc.) and would love a good recommendation.
So have you solved your problems if you use third party VPN to do the encryption between you and the third party and the mentioned third party also conveniently has your whole data stream unencrypted, no matter from where you connect?
In addition, I'd like to ask the entire world to stop using 'fail' as a noun. It's lazy and incorrect.
The costs must be weighed against the benefits. Calling FB out as a "fail" is failing to understand all of the issues.
that is exactly my point. "Web security" being treated as a separate area where only specific people specialize instead of being treated as a basic fundamental prerequisite for a web developer.
Currently on my production application it adds a minimum of 200ms per request.
This is yet another reason to use a tool like 1password.
I'd also love if they enabled encryption for FB chat, even if you used an external client like iChat or Pidgin.
This particular entry, however, uses the worn and now ridiculous "fail" meme five different times. Fail.
It's (for me) pretty simple. they force the users to use http because the amount of cpu time which is spent for http user is lower than the time for https...
just my two cents
"all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."