RC4 is a terribly broken cipher. It was known to be broken in the late '90s and was included in SSL more as an accident of history than anything else. Unfortunately, SSL was standardized before researchers fully understood the interactions between encryption and message authentication, and SSL botched block encryption (and thus AES). So, for the past ~4-5 years, big companies have been using RC4 as a stopgap for dealing with vulnerabilities stemming from SSL's botched AES construction.
That doesn't work anymore, because the flaws in RC4 are now known to be far more grave than they were previously though.
Add support for AES-GCM, the only rigorously secure ciphersuite available to TLS, to the laundry list of other things Google has done to improve Internet security --- forward secrecy, certificate pinning, detection of forged certificates, patching the Lucky 13 vulnerability.
...Or not; it appears my edit to this overlapped a response, so I'm putting my rambling comment back, below]
----
Checking now, it looks as if, as of today at least, Facebook is also using/preferring AES_128_GCM. Again, I don't have a specific note-to-self to refer to, and my memory's a bit fuzzy, but I seem to recall that until recently they were using AES_128_CBC, or something else other than GCM.
If you've time to answer, are you familiar with this use and change (am I right, specifically?) and if so might I impose for a sentence or two on what improvement the change to GCM brings?
Regardless, thanks for the description and qualification in your parent comment.
P.S. Upon reflection, I think I recall Facebook using AES_128_GCM for some time now, although I seem to recall -- perhaps incorrectly -- their using something else at some point after they switched to ECDHE_RSA.
I mostly look at the certificate chains as a check against obvious man in the middle situations. Again, I'm not claiming any kind of expertise, but I do have a certain degree of curiosity.
P.P.S. So maybe I shouldn't have asked/imposed my follow-up. Or maybe a better question would be, how is Facebook doing / regarded with respect to this aspect of security, these days?
What's especially nice about AES-GCM is that the "mode" itself takes care of guaranteeing both message confidentiality and integrity. The TLS working group does not need to do much joinery and decisionmaking to make GCM work; the mode itself is standardized to provide those capabilities. The less you ask of the TLS working group, the more you put on the fundamental crypto, the better off you are.
(As it happens, the very little decisionmaking latitude the TLS WG actually had for AES-GCM resulted in a weakness! Though not an especially meaningful one.)
Facebook also has a good security team. Google has the advantage/beneficence of running an important browser project that is itself committed to moving the ball forward on TLS, which is an advantage Facebook lacks.
Because the Fluhrer-McGrew digraph biases recur through the keystream, successive samples don't require a TLS session setup and key exchange; you can reuse a single session to collect many samples. So, while the digraph biases provide a weaker signal, the attack on them actually runs faster.
Net-net, from what we know now, RC4-drop-1024 would have had no effect at all on the security of TLS. That could change, but when I look at the digraph biases, I think it's the digraph biases that are going to get more effective.