Old Mac keyboards had something similar to that - instead of an upside-down-T-shaped directional pad, the had the four arrow keys in the bottom-left, in a row. I no longer remember what order they were in (besides "awful".)
It was usable, once you got used to it, but not intuitive in any way whatsoever. I'm not sure anyone used it enough to determine if it was actually better.
Seriously though, we all get weirded out by different things. If the raised bit bothers you, why not move another key to the right and go with RDFG?
The biggest problem with these key layouts is rebinding all the game's keys. Also, you'd be amazed how many games hardcode the default keymap into the tutorial. "Press R to reload!" no, R makes me go forward. That doesn't help at all! Stupid game >:(
I always figured Gordon Freeman a bit differently.
He doesn't talk, and he never does anything particularly scientific. He's mute out of confusion. He's been dropped into this world, completely out of nowhere, and while there are people claiming to know him, people claiming to have been friends with him for decades, he, like us, has absolutely no memory of any of it.
He doesn't know who he is. He doesn't know what he's doing here. All he knows is that he's trying to survive, and things try to kill him, and . . . well, he could just walk away, right? But he never had a chance to get out during the events of Half-Life 1, and in some ways this entire mess is his fault, and, well, these people are relying on him.
So he soldiers on. But he still doesn't know any of the people, events, or places that this is happening in. So if he opens his mouth one time, people might realize he's not actually the person they think he is. So he keeps his mouth shut, and somehow things seem to work out, everyone always knows where he has to go next, and nobody suspects a thing.
Except, of course, for the G-Man, who knows everything that's happened, and knows where Gordon came from, and knows what Gordon is sent to do.
Is that all really subtle enough that people are missing it? It seems pretty clear from the beginning and ending of most of the games that, whatever Gordon is, he's certainly not just some random dude with a PhD. The sheer existence of the G-Man proves that. I'm honestly rather impressed that Valve's kept it up this long without spilling the beans. I honestly think that Gordon is just as in-the-dark about the world of Half-Life as we are.
I have to say, the thing I've always wondered about is the business side of things. I've heard, although I have no hard evidence, that Gamestop/EB stores don't make any significant profit off new games, which is why they're always pushing used games. Their profit sources are "used games" and "product placement" - publishers pay big bucks to have things like Halo 3 in the front-and-center of stores.
What I'm curious about is what they would do if you went to them and said "I have a game, I would like you to sell it, we've been doing advertising and it should sell quite a bit, we can't afford to pay you for placement but we'll sell the actual copies to you for $15 less so you can actually make a profit on it". Would they give some of that front-and-center space over to it in the hopes of selling more, or would they just relegate it to the back shelves because it's not paying the bucks?
Unfortunately it seems impossible to actually get information on the big business policies. Ah well.
The problem is that "copyright" and the logical extension of "patenting" physical objects are the same thing.
You don't copyright a stove, because people can't just copy it. You patent it, and now people can't build an identical stove, even if they could build something very stovelike. But with software, you copyright the software, and now people can't copy it. Patenting would, in theory, fulfill the exact same purpose - "you can't build the identical software" - and that's software patents are kind of bizarre and shouldn't even exist.
Instead, though, patents are being treated as "one step up from copyright" - you can't build an identical stove, and you "can't build software that does the same thing". Which isn't the equivalent of patents at all. It's more the equivalent of a concept monopoly. If software patents were imported right back into the physical world, you'd have people able to put patent on "cars", or "stoves", as an entire class of thing.
I don't think software patents need to be "fixed". I don't think they need to be "abolished". I think what's necessary is realization that the entire concept of "software patent" doesn't even make sense, and that there really is no parallel with the physical world here.
Most of the real server farms I've seen were running at a significant load - 30%+. It's rarely been a matter of wanting lots of computers, and generally been a matter of needing lots of CPU powers. Commodity systems seem to be the most efficient way to do this, as long as you have good failure handling (and if you don't, you're screwed anyway.)
Then again, it was a year or so ago that I was involved in any of that.
Re:morphing, changing, not dying
on
The Dying PC Market
·
· Score: 4, Insightful
Which is entirely true. The mainframe has changed - the modern mainframe is a huge farm of commodity computers.
You make an excellent point, it just wasn't the one you intended.
I'm lazy, and Netflix saves me a huge amount of time.
I like variety. Netflix has almost everything I want, and when they don't, they tend to get it in quickly.
I consider Netflix to be reasonably cheap. $12 a month for me, and I pay four times that much for internet service and six times that much for electricity. It's just not a significant cost, and it easily pays for itself in convenience and selection.
"Wolfram's 2,3 Turing Machine Not Universal". What? Where'd you get that? This issue doesn't prove anything of the sort - it merely shows that this proof is invalid. It may be universal, it may not, but we still don't know.
So, ironically - whoa, not so fast there big editor.
There are rumors that BioWare is developing a 'Star Wars'-themed MMO, but if that's what inspired the purchase, the mystery only deepens: Sony Online's (SNE) MMO Star Wars Galaxies was a disappointment in relation to cost and anticipation, and that was released at the height of the buzz over a movie franchise that's since become old news.
Yes.
That's because it was a bad game. Bioware is a good company because they make good games.
If you take a turd, and put a "Star Wars" label on it, you still have a turd, it's just that now you have a branded turd. It might sell a bit better but it's not going to be extraordinary. Maybe someone in EA has actually realized this?
I don't agree. You're assuming that an attacker can exploit bugs in both App A and App B, at will. I don't think that's the case. In order to even touch the OS, you have to first exploit the virtualization framework.
I run virtualization because it seems stronger to me than not. Without virtualization, in order to root my box, the user needs to follow this order:
* Exploit a running process to get in * Find a hole in any root-permission process to get root privileges
(Note that these might be the same step in some cases.)
With virtualization, there's this order:
* Exploit a running process to get in * Find a hole in the virtualization layer that is accessible from a user level * Find a hole in any root-permission process to get root privileges
Or possibly, even worse:
* Exploit a running process to get in * Find a hole in any root-permission process to get root privileges * Find a hole in the virtualization layer that is accessible from a root level * Find a hole in any root-permission process to get root privileges
That seems quite a bit stronger to me.
No, virtualization isn't a security guarantee. But I do think it's a bonus. And, yes, it's arguable, and you could indeed argue that this is still less secure - but claiming that running VMWare on Apache means that an attacker can now choose to exploit either VMWare or Apache is simply misleading.
Perhaps. However, the article isn't talking about custom hardware, this is talking about using generic hardware as a highly parallel processor.
Also, what makes you think it would be cryptographically weak?
for($i = 0; $i 1000000; $i++)
$data = md5($data);
Go ahead and find a cryptographic flaw in this:P
Yes, if they get your password file and build custom hardware to implement your decryption routine, they'll have a big advantage. But that's expensive, and you can still make it a lot harder for them.
No, it's the same point. In any situation like this you can determine just how fast you want the password-checking step to be. If you want instant reaction, you can set it up so you can decrypt it in a nanosecond. That'd be pretty damn fast - but it also makes it a lot weaker. Alternatively, you could set it up so the decryption step takes, say, ten seconds, which is probably what I'd do if my company's most valuable data was on a hard drive.
Of course then you'd be completely screwed if the CEO died or forgot his password. But it's still the same point. You can determine, at the time you build the encryption schema, both how fast you want it to be accessed and how brute-force crackable you want it to be. (This being, of course, the same value.) People don't seem to realize this for some reason but it's true.
(To hold off anyone saying "lol a filesystem with 10 second access time, that would be terrible" - use a two-tiered encryption system. Ten seconds to decrypt the block with the "real" password in it, which is a 2048-bit symmetric key, then decrypt the rest of the filesystem using that one. It only takes ten seconds to open it, and then it's open and fast until you close it again.)
No, that is exactly my point. If it takes a hundredth of a second just to run the algorithm to check the password, it's going to be hellishly painful for them to crack that file. There's no way they can do ten million tests per second if it takes anywhere close to that long.
That's why the other person recommending sleep() was missing the point.
The password-cracking farm mentioned in the article is only useful if the person has a database of your encrypted passwords. Obviously, they're not going to write a sleep(10) in if they're trying to crack it - but doing ten thousand passes over MD5 isn't something they can just decide not to do.
With a local password authentication scheme, you of course want to limit the number of checks by IP (the sleep() is meaningless, they'd just hammer you with a million attempts at once and pretend like it's ten seconds of lag) - but that has nothing to do with the article or my post.
unless you're using a crappy password scheme like Vista's, for example.
This is a process that lets you brute-force passwords 25 times faster. That's pretty neat, I'm not arguing that. It's extremely clever. But this speed [i]shouldn't matter[/i], because cracking passwords a mere 25 times faster shouldn't matter either. The problem comes down to how people are designing a lot of password schemes. They're aiming for speed. The article says the new technique can try ten million passwords per second on a single computer. Division tells us that, beforehand, the computer could process 400,000 passwords per second.
When was the last time you had four hundred thousand users logging into a single computer per second?
Checking a password should be slow. Brutally slow. I mean, quite literally, that just checking to see if the user's password hashes correctly should take at least a hundredth of a second. You're not going to have a hundred users logging in per second on a single computer anyway, our modern database-driven sites couldn't handle the load of displaying the login pages, so why are we making our password schemes so flimsy?
If you use a slow password hash generation - and this can be something as simple as iterating MD5 over itself ten thousand times - whoever's trying to brute-force your password scheme is going to have a horrible, horrible time of it. Add a basic salt to the mix and you will not have anything to worry about from this. If your password checker takes a hundredth of a second, then 25 times faster means your adversary is going to spend $1300 on software in order to try 2500 passwords per second. If you have an appropriate salting system that's 2500 passwords for a single user. This is not the death knell for passwords, or anywhere near it. If anything, it's the death knell for crappy password hashes - but it's not even that, since you could trivially foresee things like this years in advance.
Brute-force password cracking, by its very nature, is millions of times more expensive than merely verifying a valid user. From there, it's up to you to determine how safe you want your passwords to be. Personally? I'm fine with wasting a few extra hundredths of a second per user.
It's because CPUs are designed to run long streams of sequential instructions very, very quickly, with utterly random access to data, while GPUs are designed to run huge numbers of instructions in parallel very, very quickly, with relatively restricted access to data.
A huge amount of modern CPU design is taken up simply by attempts to predict what will happen next, and attempts to allow blazing through a single long instruction stream as fast as possible. Parallelization gives tremendous speedups, as long as the problem you're working on is actually parallelizable. Password cracking is what's known as an embarrassingly parallel problem, so it's perfectly suited for this sort of processor. An OS, on the other hand, isn't even close to as parallel.
I actually got an advantage once because I didn't have Word. A company sent me a contract for moving in.doc format. I did my best with WordPad which was the closest thing I had available, but it ended up mangled. I sent it filled-out to the best of my ability, with a comment that I couldn't easily deal with it and I wasn't sure if it was usable.
Well, they ended up delaying my moving significantly and then asking me for some extra fees that I'd never known about. I objected, and they said this information was all in the doc file I'd signed.
"Oh, the one I could barely read? It wasn't shown in the version I saw, because I couldn't read much. I sent you what WordPad did with it - what I signed was that."
Turned out that a lot of the major clauses were missing in that version due to WordPad's crummy handling - but since I'd signed it, and they'd accepted it (I presume without looking at it, otherwise they would have seen how mangled it was), they had technically agreed to the modified version which didn't have any of those fees at all.
I was tired of dealing with them by then anyway, so I told them to either deliver my stuff at the price that I'd agreed to or send it back to the place they'd picked it up from and refund my money, as I'd certainly never agreed to give them more than they had already received. They delivered it in two days.
Several tiered fingerprints, as I remember, of increasing cost and accuracy. It's been a while since I was working on that project. It was indeed designed to scale to a huge amount of video - not the amount that YouTube has now, but I suspect it would have scaled up quite well.
Honestly, I never got to the point of optimization. And it obviously would depend heavily on the number of computers dedicated to it - I was making sure it was easily parallelizable.
I don't really know how slow it would have been, it would have been fast enough for the project specs but I wasn't designing it specifically for something like this:)
I've actually written a video comparison utility, and it would have neatly ignored every single one of these (with the exception of "backwards", which would have taken about five more minutes of work - it wasn't really important in my case.) Video is an interesting case because it's already so damaged by the very nature of compression, your tester has to be very lax to catch anything - but on the other hand, there's so much data that it's easier than you'd think to match up. Especially if you're willing to toss borderline cases at human checkers - you honestly end up with surprisingly few of those.
I don't know what Google is doing along these lines, though.
Slashdot Mirror
Personally, I encrypt things whenever it's convenient, simply because it helps mask people who are doing truly important or dangerous things.
In the process it masks people who are sharing music illegally, but I'm okay with that, honestly.
Old Mac keyboards had something similar to that - instead of an upside-down-T-shaped directional pad, the had the four arrow keys in the bottom-left, in a row. I no longer remember what order they were in (besides "awful".)
It was usable, once you got used to it, but not intuitive in any way whatsoever. I'm not sure anyone used it enough to determine if it was actually better.
It's just you. :)
Seriously though, we all get weirded out by different things. If the raised bit bothers you, why not move another key to the right and go with RDFG?
The biggest problem with these key layouts is rebinding all the game's keys. Also, you'd be amazed how many games hardcode the default keymap into the tutorial. "Press R to reload!" no, R makes me go forward. That doesn't help at all! Stupid game >:(
I always figured Gordon Freeman a bit differently.
He doesn't talk, and he never does anything particularly scientific. He's mute out of confusion. He's been dropped into this world, completely out of nowhere, and while there are people claiming to know him, people claiming to have been friends with him for decades, he, like us, has absolutely no memory of any of it.
He doesn't know who he is. He doesn't know what he's doing here. All he knows is that he's trying to survive, and things try to kill him, and . . . well, he could just walk away, right? But he never had a chance to get out during the events of Half-Life 1, and in some ways this entire mess is his fault, and, well, these people are relying on him.
So he soldiers on. But he still doesn't know any of the people, events, or places that this is happening in. So if he opens his mouth one time, people might realize he's not actually the person they think he is. So he keeps his mouth shut, and somehow things seem to work out, everyone always knows where he has to go next, and nobody suspects a thing.
Except, of course, for the G-Man, who knows everything that's happened, and knows where Gordon came from, and knows what Gordon is sent to do.
Is that all really subtle enough that people are missing it? It seems pretty clear from the beginning and ending of most of the games that, whatever Gordon is, he's certainly not just some random dude with a PhD. The sheer existence of the G-Man proves that. I'm honestly rather impressed that Valve's kept it up this long without spilling the beans. I honestly think that Gordon is just as in-the-dark about the world of Half-Life as we are.
Lemme try that again since I screwed up the last comment (too much vbulletin for me.)
A Japanese puzzle game tangentially based off Lineage.
Eyezmaze's games, especially the Grow series.
Both are puzzle games, just FYI.
A [url=http://lineage2.plaync.jp/l2fun/flashGame.aspx]Japanese puzzle games[/url] tangentially based off Lineage.
[url=http://www.eyezmaze.com/grow/cube/index.html]Eyezmaze's games[/url], especially the Grow series.
Both are puzzle games, just FYI.
I have to say, the thing I've always wondered about is the business side of things. I've heard, although I have no hard evidence, that Gamestop/EB stores don't make any significant profit off new games, which is why they're always pushing used games. Their profit sources are "used games" and "product placement" - publishers pay big bucks to have things like Halo 3 in the front-and-center of stores.
What I'm curious about is what they would do if you went to them and said "I have a game, I would like you to sell it, we've been doing advertising and it should sell quite a bit, we can't afford to pay you for placement but we'll sell the actual copies to you for $15 less so you can actually make a profit on it". Would they give some of that front-and-center space over to it in the hopes of selling more, or would they just relegate it to the back shelves because it's not paying the bucks?
Unfortunately it seems impossible to actually get information on the big business policies. Ah well.
The problem is that "copyright" and the logical extension of "patenting" physical objects are the same thing.
You don't copyright a stove, because people can't just copy it. You patent it, and now people can't build an identical stove, even if they could build something very stovelike. But with software, you copyright the software, and now people can't copy it. Patenting would, in theory, fulfill the exact same purpose - "you can't build the identical software" - and that's software patents are kind of bizarre and shouldn't even exist.
Instead, though, patents are being treated as "one step up from copyright" - you can't build an identical stove, and you "can't build software that does the same thing". Which isn't the equivalent of patents at all. It's more the equivalent of a concept monopoly. If software patents were imported right back into the physical world, you'd have people able to put patent on "cars", or "stoves", as an entire class of thing.
I don't think software patents need to be "fixed". I don't think they need to be "abolished". I think what's necessary is realization that the entire concept of "software patent" doesn't even make sense, and that there really is no parallel with the physical world here.
Most of the real server farms I've seen were running at a significant load - 30%+. It's rarely been a matter of wanting lots of computers, and generally been a matter of needing lots of CPU powers. Commodity systems seem to be the most efficient way to do this, as long as you have good failure handling (and if you don't, you're screwed anyway.)
Then again, it was a year or so ago that I was involved in any of that.
Which is entirely true. The mainframe has changed - the modern mainframe is a huge farm of commodity computers.
You make an excellent point, it just wasn't the one you intended.
I'm lazy, and Netflix saves me a huge amount of time.
I like variety. Netflix has almost everything I want, and when they don't, they tend to get it in quickly.
I consider Netflix to be reasonably cheap. $12 a month for me, and I pay four times that much for internet service and six times that much for electricity. It's just not a significant cost, and it easily pays for itself in convenience and selection.
Yeah, speaking of that . . .
"Wolfram's 2,3 Turing Machine Not Universal". What? Where'd you get that? This issue doesn't prove anything of the sort - it merely shows that this proof is invalid. It may be universal, it may not, but we still don't know.
So, ironically - whoa, not so fast there big editor.
Yes.
That's because it was a bad game. Bioware is a good company because they make good games.
If you take a turd, and put a "Star Wars" label on it, you still have a turd, it's just that now you have a branded turd. It might sell a bit better but it's not going to be extraordinary. Maybe someone in EA has actually realized this?
I don't agree. You're assuming that an attacker can exploit bugs in both App A and App B, at will. I don't think that's the case. In order to even touch the OS, you have to first exploit the virtualization framework.
I run virtualization because it seems stronger to me than not. Without virtualization, in order to root my box, the user needs to follow this order:
* Exploit a running process to get in
* Find a hole in any root-permission process to get root privileges
(Note that these might be the same step in some cases.)
With virtualization, there's this order:
* Exploit a running process to get in
* Find a hole in the virtualization layer that is accessible from a user level
* Find a hole in any root-permission process to get root privileges
Or possibly, even worse:
* Exploit a running process to get in
* Find a hole in any root-permission process to get root privileges
* Find a hole in the virtualization layer that is accessible from a root level
* Find a hole in any root-permission process to get root privileges
That seems quite a bit stronger to me.
No, virtualization isn't a security guarantee. But I do think it's a bonus. And, yes, it's arguable, and you could indeed argue that this is still less secure - but claiming that running VMWare on Apache means that an attacker can now choose to exploit either VMWare or Apache is simply misleading.
Perhaps. However, the article isn't talking about custom hardware, this is talking about using generic hardware as a highly parallel processor.
:P
Also, what makes you think it would be cryptographically weak?
for($i = 0; $i 1000000; $i++)
$data = md5($data);
Go ahead and find a cryptographic flaw in this
Yes, if they get your password file and build custom hardware to implement your decryption routine, they'll have a big advantage. But that's expensive, and you can still make it a lot harder for them.
No, it's the same point. In any situation like this you can determine just how fast you want the password-checking step to be. If you want instant reaction, you can set it up so you can decrypt it in a nanosecond. That'd be pretty damn fast - but it also makes it a lot weaker. Alternatively, you could set it up so the decryption step takes, say, ten seconds, which is probably what I'd do if my company's most valuable data was on a hard drive.
Of course then you'd be completely screwed if the CEO died or forgot his password. But it's still the same point. You can determine, at the time you build the encryption schema, both how fast you want it to be accessed and how brute-force crackable you want it to be. (This being, of course, the same value.) People don't seem to realize this for some reason but it's true.
(To hold off anyone saying "lol a filesystem with 10 second access time, that would be terrible" - use a two-tiered encryption system. Ten seconds to decrypt the block with the "real" password in it, which is a 2048-bit symmetric key, then decrypt the rest of the filesystem using that one. It only takes ten seconds to open it, and then it's open and fast until you close it again.)
No, that is exactly my point. If it takes a hundredth of a second just to run the algorithm to check the password, it's going to be hellishly painful for them to crack that file. There's no way they can do ten million tests per second if it takes anywhere close to that long.
That's why the other person recommending sleep() was missing the point.
Which completely misses the point of my post :P
The password-cracking farm mentioned in the article is only useful if the person has a database of your encrypted passwords. Obviously, they're not going to write a sleep(10) in if they're trying to crack it - but doing ten thousand passes over MD5 isn't something they can just decide not to do.
With a local password authentication scheme, you of course want to limit the number of checks by IP (the sleep() is meaningless, they'd just hammer you with a million attempts at once and pretend like it's ten seconds of lag) - but that has nothing to do with the article or my post.
It's easier than having to count pins - just short the green wire with any black wire. Voila.
unless you're using a crappy password scheme like Vista's, for example.
This is a process that lets you brute-force passwords 25 times faster. That's pretty neat, I'm not arguing that. It's extremely clever. But this speed [i]shouldn't matter[/i], because cracking passwords a mere 25 times faster shouldn't matter either. The problem comes down to how people are designing a lot of password schemes. They're aiming for speed. The article says the new technique can try ten million passwords per second on a single computer. Division tells us that, beforehand, the computer could process 400,000 passwords per second.
When was the last time you had four hundred thousand users logging into a single computer per second?
Checking a password should be slow. Brutally slow. I mean, quite literally, that just checking to see if the user's password hashes correctly should take at least a hundredth of a second. You're not going to have a hundred users logging in per second on a single computer anyway, our modern database-driven sites couldn't handle the load of displaying the login pages, so why are we making our password schemes so flimsy?
If you use a slow password hash generation - and this can be something as simple as iterating MD5 over itself ten thousand times - whoever's trying to brute-force your password scheme is going to have a horrible, horrible time of it. Add a basic salt to the mix and you will not have anything to worry about from this. If your password checker takes a hundredth of a second, then 25 times faster means your adversary is going to spend $1300 on software in order to try 2500 passwords per second. If you have an appropriate salting system that's 2500 passwords for a single user. This is not the death knell for passwords, or anywhere near it. If anything, it's the death knell for crappy password hashes - but it's not even that, since you could trivially foresee things like this years in advance.
Brute-force password cracking, by its very nature, is millions of times more expensive than merely verifying a valid user. From there, it's up to you to determine how safe you want your passwords to be. Personally? I'm fine with wasting a few extra hundredths of a second per user.
It's because CPUs are designed to run long streams of sequential instructions very, very quickly, with utterly random access to data, while GPUs are designed to run huge numbers of instructions in parallel very, very quickly, with relatively restricted access to data.
A huge amount of modern CPU design is taken up simply by attempts to predict what will happen next, and attempts to allow blazing through a single long instruction stream as fast as possible. Parallelization gives tremendous speedups, as long as the problem you're working on is actually parallelizable. Password cracking is what's known as an embarrassingly parallel problem, so it's perfectly suited for this sort of processor. An OS, on the other hand, isn't even close to as parallel.
I actually got an advantage once because I didn't have Word. A company sent me a contract for moving in .doc format. I did my best with WordPad which was the closest thing I had available, but it ended up mangled. I sent it filled-out to the best of my ability, with a comment that I couldn't easily deal with it and I wasn't sure if it was usable.
Well, they ended up delaying my moving significantly and then asking me for some extra fees that I'd never known about. I objected, and they said this information was all in the doc file I'd signed.
"Oh, the one I could barely read? It wasn't shown in the version I saw, because I couldn't read much. I sent you what WordPad did with it - what I signed was that."
Turned out that a lot of the major clauses were missing in that version due to WordPad's crummy handling - but since I'd signed it, and they'd accepted it (I presume without looking at it, otherwise they would have seen how mangled it was), they had technically agreed to the modified version which didn't have any of those fees at all.
I was tired of dealing with them by then anyway, so I told them to either deliver my stuff at the price that I'd agreed to or send it back to the place they'd picked it up from and refund my money, as I'd certainly never agreed to give them more than they had already received. They delivered it in two days.
Several tiered fingerprints, as I remember, of increasing cost and accuracy. It's been a while since I was working on that project. It was indeed designed to scale to a huge amount of video - not the amount that YouTube has now, but I suspect it would have scaled up quite well.
Honestly, I never got to the point of optimization. And it obviously would depend heavily on the number of computers dedicated to it - I was making sure it was easily parallelizable.
:)
I don't really know how slow it would have been, it would have been fast enough for the project specs but I wasn't designing it specifically for something like this
I've actually written a video comparison utility, and it would have neatly ignored every single one of these (with the exception of "backwards", which would have taken about five more minutes of work - it wasn't really important in my case.) Video is an interesting case because it's already so damaged by the very nature of compression, your tester has to be very lax to catch anything - but on the other hand, there's so much data that it's easier than you'd think to match up. Especially if you're willing to toss borderline cases at human checkers - you honestly end up with surprisingly few of those.
I don't know what Google is doing along these lines, though.