You make a phone that can't be bent by being left in someone's pocket, so that if it is bent, it clearly was damage beyond the scope of the warranty?

They have a video. That's exactly what they do: they place the phone on two blocks of wood, and then have a machine apply a set amount of pounds of force to a bar placed across the middle of the phone.

About all their test tells you is that you shouldn't take Consumer Reports tests seriously if this is the kind of testing they're going to do. Especially because the people bending the phones weren't bending them straight in the middle, they were bending them right below the volume buttons. Which is also where their test phone's case actually breaks, even though the bend is down where they placed the bar.

Also make sure to remove /bin/sh, because (at least on my Mac, and I'm fairly certain I haven't screwed around with /bin) rather than have /bin/sh be a symlink or a hard link, /bin/sh is a copy of /bin/bash. Not sure why.

Right now, I think they're just blindly hitting web servers with headers set to exploit the vulnerability and hoping they get lucky. So less of a "scan" and more of a "spray and pray" type deal.

I think some versions of Apache shipped with a cgi-bin that contained a shell script as an example, so that would be another thing to try hitting first.

Well, Apache and literally every other CGI container since that's how CGI works: the HTTP environment (headers and various other stuff) is passed to the script being executed via specifically named environment variables.

You and everyone else.

The attack surface is "anywhere you can influence the values of environment variables prior to bash being run." Where exactly is that? Well...

The easiest example of that are CGI scripts, where the web server will set environment variables to values that are taken directly from HTTP headers. If the CGI script is a bash script (why would you do that?) or ever happens to fork out to a bash script in any way (that's more understandable), it's vulnerable.

But that's just one example. Any place a remote value gets stuck straight into an environment variable and a bash script gets run is vulnerable. And people are almost certainly going to slowly find more and more places where that's the case.

If you just want to know if you're vulnerable, there are one-liners that will determine if you're still vulnerable, but since the first fix didn't, chances are, you very well could be.

True, but generally security patches get backported to whatever the current Cygwin version is.

So the vulnerability is as of now fixed with today's 4.1.12-5, which isn't the latest version of Bash.

No, they have two million players, not two million subscribers. There's a very important difference there.

Remember that the game has a free trial now. Inflating that player count is very easy.

Weren't they suppose to be announcing active player numbers recently? Notice how that never happened? Gee, wonder why.

The idea that a failed MMO from 2010 could someone be a competitor in 2014 while requiring a subscription is just so laughable I don't even no where to start. And, yes, I've played 2.0. They removed everything interesting from their horrible launch and ripped off as much of World of Warcraft as they possibly could. It's still not worth playing and the lack of active subscriber numbers bears that out.

Wildstar is still in flux because they managed to scare a ton of their original player base away but they're now working hard on earning them back. Destiny has already entered that wonderful "wait until the next patch" period where it's flat-out not worth playing until updated. (And how I wish Destiny players would stop whining about that, but that's a different issue.)

I notice you didn't bother mentioning ArcheAge, which is the current "big MMO" that's drawing a ton of players away from other MMOs. It sounds like it's the MMO that people wanted TESO to be. Could be interesting or could flame out in a couple of months. We'll just have to wait and see.

You know what, based on previous Apple stories, probably not.

Apparently Apple is so stupidly secretive about their new phones that when they beta test the new hardware, they require them to be in special "camouflage cases" to prevent outsiders from getting a sneak peak at the new phone.

So it's entirely possible that they literally never tested having the phone in a pants pocket the entire day without it also being in a rigid case that prevented the problem from happening.

Apparently this only affects iPhone 6/6 Plus phones.

I wonder what the chances are that they just accidentally forgot to include the drivers for the new TouchID sensor and the new cellular radios in those phones? Because that would be a truly hilarious QA mistake.

"What, we were supposed to try this on our flagship phone? Oops."

Wait, so iOS 8.0.1 prevents hipsters from unlocking their phones and from making calls?

And Apple is calling that a bug and pulling the update over that?

This sounds like the best version of iOS Apple has ever created! Why would they want to stop people from upgrading? Get iOS 8.0.1 out to everyone as fast as possible!

I just updated Cygwin to the latest, and yes, it's still vulnerable. (At least its bash-4.1.10-4 is, I suppose it's possible that the mirror I'm using is out of date.)

It would be nice if the article mentioned what browsers/plugins were vulnerable, wouldn't it? (And does this cover api.jquery.com or just the home page?) Although it wouldn't surprise me that they just don't know yet since jQuery is still investigating.

I'm pretty sure I'm up to date with everything, but...

Wow you're dense.

I'm saying that what the US is doing in Syria is exactly equivalent to what Russia is doing in Ukraine.

Because, according to international law, it is.

The sanctions being imposed against Russia are for Russia taking literally the exact same actions the US is currently taking in Syria.

You can argue the relative morality all you want, but we're still, ultimately, invading a sovereign nation.

According to the article, the library itself wasn't affected.

Plus most people don't use jQuery.com as a CDN. Instead jQuery recommends you use Google's CDN if you want to use a CDN for jQuery.

Of course, this is still bad - I visit jQuery.com fairly frequently to check the documentation. The article doesn't say what was required for the malware to run so I have no idea if I was vulnerable to it or not, but if it was dropped on all pages and not just the home page, I definitely could have been hit by it.