Slashdot Mirror
Hackers Find Use for Google Code Search
An anonymous reader wrote in to say that "Google has inadvertently given online attackers a new tool. The company's new source-code search engine, unveiled Thursday as a tool to help simplify life for developers, can also be misused to search for software bugs, password information and even proprietary code that shouldn't have been posted to the Internet, security experts said Friday.
"
"Powered by phpBB" in order to find phpBB boards that were vulnerable to an exploit to hack. This isn't exactly a new technique. Well ok I know it's not exactly the same thing but the idea is still the same.
I can't read code - it means absolutely nothing to me. So this whole point on OSS being transparent and knowing what the software really does, doesn't apply to me. Hell, if someone were to show me the source code to both Windows and Linux, I probably wouldn't even be able to tell which OS was which. All I care about is whether the software does what I need it to do; I don't plan on spending any evenings curled up to the fire reading source code.
So this leads us to the next pro-OSS argument, that if the program doesn't do what you want you can either make a solution or hire someone to do it for you. I've tried this (several times in fact), and it didn't work. Since I don't program I have to go out and hire someone to code the solution I want. Never mind that finding a coder can often be a royal pain, but each and every time not only has (or would have) it been more expensive to hire someone to code the solution, but it took longer than had I gone out and bought a commercial closed source package (or two) that did do what I want.
Lastly, I keep hearing how OSS programs are more nimble and should a bug or needed feature be identified, 'the community' will solve the problem much faster than a closed source solution. That may be for popular projects like Linux or Firefox, but in my experience I find the OSS programs to be less responsive to requests and needs than the closed source solutions.
As a scientist, I'm all for transparency and free flowing information. However, when push comes to shove, I need programs that work, and, while I really hate to say this, the OSS programs have always fallen short.
Some search strings to try out:
e r+%22should+be+enough%22&btnG=Searcha n+be+fixed+later%22&btnG=Search+ don't+understand%22&btnG=Searcho t+very+safe%22&btnG=Searche s%22&btnG=Search+Code
http://www.google.com/codesearch?hl=en&lr=&q=buff
http://www.google.com/codesearch?hl=en&lr=&q=%22c
http://www.google.com/codesearch?hl=en&lr=&q=%22I
http://www.google.com/codesearch?hl=en&lr=&q=%22n
http://www.google.com/codesearch?q=%22but+who+car
In practice the US Military does this quite a bit, unfortunately.
It's actually kinda funny (read: ironic.) My roommate works on Jaam (actually, my roommate and his boss *are* Jaam,) and according to him, he's allowed to know far more about Red aircraft than he is about Blue. Why? Because info on Red aircraft were obtained through spying or diplomacy, information about Blue aircraft is tightly controlled by the companies that make them.
And that's your daily dose of "our government is insane."
"Build a man a fire warm him for a day, set a man on fire and warm him for the rest of his life."
I ran into a situation at work recently where we (note, we're statisticians, not programmers) discovered firsthand the value of having the source code to a piece of software. A proprietary program we purchased was calculating a value incorrectly because it wasn't taking a certain factor into account that most people don't need, and there was no way to get it to do that. My boss' comment: "And we can't fix it because we don't have the code."
Her point was right on target - if we had the code, we could've easily contracted out fixing the program; it probably would've taken a competent programmer a couple hours to put the fix in and test it. But instead, we're stuck with a software package that's useless for many of the situations we wanted it for, unless the developer decides we're important enough to fix the software.
When this happened, I realized that the general public is becoming much more aware of the potential problems with closed-source software. For now it might just matter mostly to programmers, but sooner or later, it'll matter to a lot more people, too.
Her point was right on target - if we had the code, we could've easily contracted out fixing the program; it probably would've taken a competent programmer a couple hours to put the fix in and test it. But instead, we're stuck with a software package that's useless for many of the situations we wanted it for, unless the developer decides we're important enough to fix the software.
Just out of curiosity -- HAVE you contacted the developer asking for a fix? Just because its a closed-source solution you can't fix yourself, doesn't mean the vendor won't fix it if someone asks. Especially if its really as simple as a couple of hours (although there is always extra overhead, such as back-testing, etc.)
Disclaimer: I work for a closed-source software vendor, but we try very hard to meet the needs of all of our customers, so if they identify a critical issue we generally try to either find an acceptable work-around, or patch the code when possible. And (ideally) that would be done in such a way that you won't lose that fix when you upgrade. If you custom-fix your OSS solution, you either have to never upgrade, or patch every version that comes out; that seems to be a lot of long-term hassle.
Customer satisfaction is a big part of being a software vendor -- sure, you may be a small customer, but if my company is responsive to your needs then that builds good relations with you, and you may be an excellent referral source for us later (or become a larger customer yourself). That's a strong motivation for businesses that really care about their customers. And for professional-type products, buyers are more likely to pay extra for that good service.