Events are disputed. Trayvon certainly fought back - gave Zimmerman some nasty head wounds - but it isn't clear who actually started the fight. No witnesses, no good forensics, so it's just Zimmerman's rather biased word.

And none of that matters since Trayvon had a chance to stop the fight once he obtained a dominant position over Zimmerman. He'd won the conflict but decided he would go further and beat Zimmerman while Zimmerman was screaming.

At that point Trayvon becomes the aggressor.

What's more, this analysis is very fresh. Remember that right now huge chunks of Tor traffic appear to be botnet control circuits. The botnet runs on 0.2.3.x - so that's going to bias the sample somewhat.

BTW - not surprised to learn that Linux distributors are screwing their users with stale repos yet again. Anyone who is using distributor repositories to get security sensitive software is just asking to be compromised.

Absolutely. The hardware they made for the Windows Phone was top notch. If they offered it with a current release ANDROID and strived to be the only phone company releasing a clean android with updates that happen rapidly they could have easily decimated samsung and HTC in the market.

Instead they went a completely dumb direction, and the knife in the back was Windows Phone OS.

That awesome Booo-Tay? All the sisters got back!

A swap is like a Gamer convention. Buttloads of stench and disease. Swapfunk in war will take out your entire army in short order.

That report is as accurate as an old tymey Alminac that says that the last 4 years it did not rain today, so it wont rain today.

I want to see the raw data and all the peer reviews of the same study. Too many of you people JUMP on the OMG sky is falling / OMG Sky is not falling bandwagons too fast.

US scientists want to see the real meat and what a LOT of others scientists think.

Yeah, because a Microsoft guy was not sent in to destroy it from the inside so they could buy it later at a drastically reduced value.

Everyone knew what they guy was up to, and the Board at Nokia had a lot to profit from it's demise.

Not all Google searches are encrypted. Only if you're logged in, or specifically visit encrypted.google.com. The reasons are complicated and stupid - to do with US schools with political clout that outsourced their internet filtering and couldn't filter searches (for the children!) if SSL was enabled for everyone. A bunch of companies/orgs in similar positions also complained.

If you use Chrome at least then Chrome-Google communication is forward secure (compromise of the private key let's you MITM but not passively decrypt).

Did you RTFA? The articles say specifically that Dual_EC_DRBG was a backdoor operation and even quotes from the documents themselves (look for the word finesse).

It's here: http://www.nytimes.com/interactive/2013/09/05/us/unlocking-private-communications.html?ref=us

There's nothing in the articles that implies this. Backdooring a CA only helps if several things hold:

1) They can not only intercept but also rewrite traffic on the fly. Possible, but if so, not yet mentioned in any leaks.

2) They're willing to take the chance that someone might notice.

So an operation against a single site, definitely possible. But they are clearly desperate to grab everything, all the time! Their whole MO is not targeted investigations but to spy on everyone simultaneously. You can't use a rogue CA to do that. They'd be detected immediately, if only by geeks setting up SSL for their new personal VPS and suddenly noticing the CA their browser gets isn't the one they installed.

The problems with SSL are not that CAs exist. The model holds against the global adversary who wants to decrypt everything. The problems with SSL are almost certainly more prosaic - many websites can be automatically hacked and their keys stolen without the owners ever knowing. In the default config that allows you to then decrypt all past traffic as well. Some implementations will use old, weak keys that were strong once upon a time but have since become obsolete. Some implementations will have bad random number generators. Some implementations will run on VPS providers and are subject to side channel attacks by colocated VMs. Some keys can be subpoenad and others can be obtained by covert agents. And of course you still leak traffic metadata even when SSL works perfectly.

There are lots of ways to attack SSL that will work some of the time, and that's exactly what the leaks imply - they can beat encryption sometimes but they don't have a magic skeleton key to everything.

The New York Times has an infographic that claims they have some capabilities against SSH.

Certificate authorities never see private keys so you are dead wrong about that. What's more, even if a rogue CA was minting bad certs on the fly to attest that the NSA was really foobar.com, that would have been noticed. Remember that secrecy is something they value insanely highly. They wouldn't ever do something so easily noticed and the articles do not imply any kind of CA compromise.

In fact if you read all the stories (they overlap largely but not entirely) you can get a vague picture of what's going on. Firstly, they record all encrypted traffic in case they can decrypt it later. Secondly, they have a database of public to private keys, populated via any means they can. Thirdly, they obtain keys in lots of ways (hacking, subversion, bogus court orders, brute forcing old/weak keys etc) but they don't seem to have a magical solution to all strong crypto. The closest that the leaks come to this is discussion of some amazing cryptoanalytic breakthrough, which could possibly mean they're able to break some kinds of RSA? Perhaps they're ahead of Joux et al by some years?

Regardless, what it is, it can't be a solution to all crypto, because these governments apparently asked the newspapers not to publish on the grounds that people might switch to stronger systems that worked.

No offence, but there absolutely is reason to believe you're incorrect. The reasons are in the Tor mailing lists which I've been keeping up with for the past few weeks.

Firstly, exit traffic has hardly moved, despite massive increase in Tor usage overall. This is consistent with the bots getting instructions from a hidden service. So exit node operators can't do much here.

Secondly, the whole point of the hidden service protocol is that relays don't know the IP of the hidden service. That's why there are rendezvous nodes that join user and service together via two 3-hop circuits. De-anonymizing such a service is very hard and requires you to control large numbers of nodes over a period of many months, according to the latest research. It's not something the Tor community can just do.

If you think you know of a slick way to resolve this problem, I suggest taking it to the Tor developers, because all the evidence I see from their lists is that right now they don't have any great ideas.

Because if you RTFA you will see that they reverse engineered the botnet and found that it's trying to contact a C&C server, what's more, this bot has a history of using Tor for receiving commands. It's obviously not a deliberate attempt to wreck Tor.