UTs are (generally) not keyed to data. Of course, they should’ve tested for the extreme edge case ("/"), but generally you’d be testing the blacklisting code and not data in the UT file except for maybe empty-url/null-url check… besides, you’d be surprised at how little UT goes on in the most respected places.
As I said above, config (IMO) is the most common of production crashes that slip by QA. Programmers tend to think of data / configuration as something that does not need a rigorous QA process, which costs the company valuable money and time. The zone file is another great example.
Why wasn’t it caught? Who knows? The changes may not even have gone through programmers. A lot of the non-static content is set up so that it is completely self-service and goes straight to copywriters, and I’d imagine that “dangerous sites” are another one of those cases that are too numerous to require manual approval. You don’t want a programmer to have to manually check every new advertisement that goes through.
This mistake was nothing. I’d think a simple slap on the wrist once they find out why the guy made the mistake, even if it was a simple mistake to make.
Now, the folks that got 30 seconds of free porn in Arizona during the Superbowl–whoever is responsible for that is going to get the boot. Hopefully.
I blame the person who wrote the code that made “/” into a wildcard, not the person who entered “/” into the badware list. Under what circumstances was that going to be a good idea? When would you want every web site in the world to be flagged as bad?
I could be completely wrong here, but I didn’t read it as “/” being a wildcard, but rather that the google checks every website against the list and since every URL contained a “/” it was tagged as a dangerous site, sort of like if the list contained ‘.’
You wouldn’t want that, but you might want every website that begins “http://www.getyourmalwarehere.com/” to be flagged as bad. Making hte final slash a wildcard would accomplish that.
I can’t find a current news article to support my assertion, but I had thought that the bad entry was a single URL of “/”, and the software interpreted that much like “*” is used as a big wildcard, a “match everything” symbol in other situations.
So when http://anyurl.com was fed to the matching routine, it came back with a match to badware everytime, since “http://anyurl.com” = “/” (=true). Nothing could escape.
I don’t add error checking for stuff like that to our in-house programs, but if I was accepting data from third-parties I would definitely validate it every way I could think of. Of course for every program there’s always a user that stumbles into a way to break it that you never would have conceived.