From the very beginning, the folks sponsoring the Rust effort from within Mozilla made sure that Mozilla couldn't directly control things. And Mozilla also just isn't that kind of organization to begin with, honestly.
These conversations have been going on a long time. This particular iteration of this conversation started before I left Mozilla. It has nothing to do with me personally, regardless of that relationship.
I have long (before, during, and after my employment at Mozilla) have thought that an independent foundation would be excellent for Rust, but am worried about the details. Foundations require active administration, which is even more work. And it's unclear who does that work. I think that we've grown to the point where it very well make sense now, though.
The problem was that SSL supported compression directly, so you could compress the encapsulated stream. What happens in HTTP is that, say the cookie header contained the user's session cookie, and the body was somewhat controllable by an attacker. (E.g., by making CORS requests in the background.) The attacker could repeat "Cookie: auth=a" many times; if your auth cookie started with "a", it would compress slightly better as both could get compressed together, things would be slightly faster, and an attacker could use timing information to discern that he'd gotten the first character correct, and move on to the second.
HTTP compression being mentioned in the article only compresses the body. It's still possible to execute the same sort of attack situationally if there's some part of, say, a response body that an attacker can control and a part that response body that the attacker doesn't control and is sensitive and wants to know and somehow only has access to the timing information.
But generally, JSON responses don't mix secret data + attacker controllable data, I feel, so compression should usually be okay. (And IME, it's typically done.) SSL/TLS compression should usually be left off, as that seems much easier to exploit.
