The Motley Fool Discussion Boards
Computers, Phones & Internet / Help with this STUPID computer!
|Subject: Re: Yet another Java flaw||Date: 10/2/2012 8:59 PM|
|Author: mmrmnhrm||Number: 182040 of 192386|
I suppose it's not much different at all. But it is different from, say, installing Office or a game or some utility. With those, you know you're installing a program and have some idea of who wrote it and, presumably, you trust them. With these web-based programs, you have no idea what's going on. (Although doesn't ASP run on the server side and not on the client computer?) You're turning over your computer to some unknown programmer. And you may not even realize that you're doing so.
The only difference, in this context, is that a program like Office requires you to consciously go to a store (whether it's brick-and-mortar or an online e-store doesn't really matter) and install it, while a Java program is often automatically executed by the browser without bothering to ask the user first (because, y'know, if they didn't want the program, they wouldn't have come to the website, amiright?). This isn't really the user's fault, but rather the browser's for just running any executable that it happens to encounter along the way. A user can cause just as much damage to their system by opening a malicious Word document as they can by running a Java program. The only difference is that with Word, there's the added step of "Please download and mail this file to begin your warranty claim" (or whatever reason-du-jour provided by the phishing email is).
Really? I've only taken a couple of programming classes (mainly in that venerable BASIC, and a great many moons ago), and handling errors was one of the few things I took away from the class. Maybe I was lucky in the instruction I received.
Still, if they're not doing a good job of handling error situations, that creates the opportunities the black hats are exploiting.
Yup. Though in many instances, it's also a question of scope. By any measure, BASIC was pretty limited in what it allowed one to do with a system: load/save files, make the speaker emit strange noises, draw graphics. But by being limited, the worst you could do to your system was overwrite a system file (oops! boot from floppy and restore). Divide by zero? Program would either crash back to the interpreter command line, or return something silly. Divide zero by zero (c'mon, I know you want to)? Same. Some might say it's the programmer's job to handle all errors (like the academic exercise of throwing junk at a sine function I mentioned earlier), but that just isn't realistically going to happen. Once an error escape's the programmer's scope, it's up to the runtime environment to prevent things from getting out of hand. This is where the *NIX world shines, with very granular limits on both what programs are allowed to do, and also on what users are allowed to do. Not only does the program need permission to do something, but the user running that program also needs permission. If either check fails, the operation also fails. Unfortunately, Windows hasn't gotten to that level yet (which is why, despite the falling number of successful attacks on Windows itself, the problem is getting worse instead of better because such restrictions aren't enforced on client software like Adobe Reader, Word/Excel macros, and, yes, Java).
Perhaps that gets to the action item for us mere mortals. If you refuse to use Java, you may have to use other ways of accomplishing something on the web. If that means you are calling customer service instead of handling it on a company's web site, you're making a statement to the company that their web site is not doing what you need it to do. Call my glasses rose-colored if you wish, but if enough people do that often enough, the company may change their web site to work without Java.
You're going back to blaming the messenger and not the message. There's no reason why *JAVA* is bad. The problem is that browsers just