I would pick holes in just about all his arguments - he seems to ignore the initial training and years of condition on how a car works. The same with a TV set. I'm sure I could find somebody that has horror stories trying to figure them out for the first time and could write an article on how counter-intuitive these items are (like, why do you need a key for a car ignition when you've unlocked the door?).
The car designers agree with you. That's why newer cars, such as some MBs and, IIRC, the Toyota Prius (and probably others) don't require you to do so. The Prius is the best example - you get in, you touch the power button to let the car know that you want to move (since activating the car when you just want to get something from inside it is potentially hazardous), and you go. So while your comment was tongue-in-cheek, its being addressed even so.
I've seen many articles like this on the VCR, not to mention ones complaining about more sophisticated cars, kitchen appliances, telephones, heating/air-conditioning systems, all of them wanting the systems to be simpler (and most, like this one, wanting to return to simpler times).
And why not? Look at the PVR - isn't that a VCR made simpler, addressing the problem domain ("I want to watch Buffy later") rather than the system domain ("I want to make tape insertion smoother")? Or an A/C system - my thermostat lets me set an upper/lower bound. It does everything else - even switching from furnace to A/C as needed. After all, its not like the problem domain of wanting a stable house temperature has changed, so why should the interfaces get more complicated?
If there is complexity, it maps directly to the problem domain and not to the UI design. That makes it far easier to deal with, because it "just makes sense."
Think about how much more complex it would be to configure and maintain a vehicle that:...
Yes, well. But you know what? Some of your examples already exist. Minivans, etc, have reconfigurable interiors. I've had two cars with adjustable suspensions. You know something?
At no point did I have do select an interior, or make a suspension setting, just to go to the store! And that's the point of the article. Sure, knowing that I can tweak my suspension to ride 2" lower and a little firmer may make for a better highway ride. But I can ignore that and still accomplish my objective - going from point A to point B. If I had a minivan, I wouldn't have to remove and reinstall the seats every time that I drove it. Or every time I wanted to change the radio station.
Compare this with the much-attacked system on modern Mercedes vehicles, where accomplishing simple tasks was made harder through their new interface. Not only are they redoing it, but their competitors (Audi, BMW, et al) all tout the friendliness and intuitiveness of their interfaces now. I'd say that its important to a lot of people.
The most common mistake that non-techies make is the assumption that the computer understands the context the same way you do. It doesn't.
And the most common mistake that techies make is that non-techies care. Heck, a car doesn't move in the same way that a human moves - it rolls, its got an engine, etc. And people used to have to know a ton about how it worked to get it to move anywhere at all reliably. Now they don't. The same thing is happening with computer software, and about time too.
With a PS2/XBox/Gamecube game they all have the same hardware so any settings that are hardware reliant can be pre-set. With computers we cannot assume the hardware platform, or Operating system to be run on. For example for a game or high graphics use program. What video card is used? how much memory does it have? And then there are things that we need to know for some other features.
Yes, but surely most modern games can probe your system rather than asking you, the user, how much memory your system has. Ideally they would start out by doing some calculations and setting the highest level of detail possible while still retaining a decent frame rate. This could then be tweaked to the end-user's desire, but people who just want to sit down and try out a new game can at least get going easily. I haven't played any new games for years, do they really not do this already?
The big problem is... as programmers we can't assume what features the customers are going to use 90% of the time unless the software is for one specific company, and only one use in that company. Take an Inventory system for example.. do the Cashiers at the store care how the stuff is entered to the Database? No, they just wanna be able to scan the customer product, and tell them how much it costs.
That was kind of the point of the article too. The cashiers shouldn't have to know. If there are some circumstances where seeing that information would be useful then by all means continue making it available, but discretely and out of the standard flow.
Do you use Excel "If" functions? I do,..
And I generally don't. But the IF() feature in Excel almost never intudes into my Excel world and when it does, it does so as insignificantly as possible (showing up as one line in a drop-down). Not a problem.
That's another great book for UI design. It talks about the UIs that are all around us. Ever encountered a glass door (shopping malls are bad at this) with a bar that goes all the way across it, mirrored on the other side? Do you push, or pull? On the left or on the right? Its not difficult, but it is an example of bad UI design. Contrast that to a door with a flat "Push" panel on one side, backed by a protruding handle on the other. You now whether you're pushing or pulling, and on which side of the door to perform the action. No documentation required, almost zero chance of failure - this door wants to be opened and makes it easy for you. A lot of computer software has exactly the same design mentality as the first door. Or worse, because the door has been "skinned" to look like a slice of pizza as well.
Using the GPS and the automobile are not really related in that way. However, before using the GPS (not the car) you do need to setup a few features before using it. For example, adding the location for your house, the area in which you live or will be searching for addresses to. Now, if you want to complain about GPS and features/setup, let's talk about how they need to ALL be voice activated or touch screens capable...
What? Oh, please. This is exactly the kind of problem that we have in a lot of software, especially smaller projects. First of all, why should I tell the car where I live just because I want to find the nearest Taco Bell? A perfect (although unintended) example.
As far as Televisions go.. this really isn't the case anymore. With more and more high-end TVs taking over the market and as they continue to do so in the future, thanks in part to HDTV, there will be a brutal setup process just to turn it on and start watching any kind of TV.
My TV has an annoying tendency to go into a reconfigure-me mode if its been without power for too long. Oddly enough, it never loses its settings (weird). Anyway, you know what I do? Its the equiv. of Next->Next->Next->Next->OK but more annoying.
Even if it did lose its settings, instead of prompting me to check the convergence it could just power on with a set of defaults. Probe to see if a coax is attached. If it is, check to see if there are channels with signals on them. Check to see if there are powered devices on the line-in and component-in ports. All of that. Then it could stick a little note up in the main menu that says, "You have not performed advanced configuration yet. Doing so will result in a superior picture. Press (X) to configure your TV." Or something.
The vast majority of programs fail to properly guard against user input. Its no different than the number of non-bind-var database applications that don't properly escape characters every time, allowing you to enter in a username like x'; delete * from users; and have it actually go through. This kind of hole is a lot more prevelant than most people would like to admit - both at a filesystem and at a database level. One of those things that people tend to ignore when they wonder why it takes large companies so long (and costs so much money) to do development is the testing and prevention of security holes like this. And they still appear anyway - but a whole lot less than they might.
Mozilla hands off protocols to windows in a simplistic way because it is not a part of the OS - just as any other program does.
Ah, but the difference is that Mozilla isn't taking protocols that, say, the user has entered when looking up a file, or URIs that were generated at compile-time - but rather, URIs that were pulled randomly from the 'net. Very few other programs do that, and that's the key difference here.
And it should be pointed out (ideally in the writeup, but who are we kidding here) that this is specifically talking about UPCs. Barcodes are still an unregulated item, as are other generics like "words", "sentences" and "labels".
But yes, there's a lot of rewriting to be done. The actual mods will be fairly simple, even on older systems, but the hard (and expensive) part comes when its time to test all of the millions of lines of code that hadn't changed in years, that have now just been impacted. And yes, in enterprise software you should test everything that might have been impacted - just in case.
Luckily most UPC-aware software doesn't try to decode it, but either reads it, writes it, or treats it as a lookup key. That makes life an order of magnitude easier than it might have been.
--
Enterprise software - for when "Close enough" doesn't cut it.
An interesting piece of vitriolic prose. I'm only going to comment on one sentence though:
Where is the phone number I can call to promptly and properly have Illegal or Undesirable Aliens DEPORTED?
And there you raised my hackles. Because my friend, to me what makes the United States great is not so much its constitution, or its purported love of "freedom," but its process. It is a country, more than almost any others, founded on law. There is no arbitrary "will of the people" just as there is no "droigt de seignuer". The same law, for one and all.
So. Deport illegal aliens? Sure - the law of the land is written such that that is the proper response. Deport undesirable aliens? Never! The day that we start (started?) allowing our personal biases to override the rule of law is (was?) a sad day for these United States.
The man pages on BSD simply rock. As opposed to the man pages on most Linux distros, many of which say, "This hasn't been updated since the dawn of time, you should be using our proprietary hypertext system 'info' to get your information, dumbass." Not including the ones that were taken (as is allowed under the BSD license) directly from the BSD folk, of course. And most tools written by people influenced by their system provide equally usable man pages. Its a great cycle of documentary bliss! Or something. Either way, its pretty cool.
Is the check for security clearance within MS Windows accessible to every local program?
Urm, I surely do believe so. That's why the user can even set it in their control panel - Internet Settings I believe - rather than just in IE (although IE does wrapper that.cpl to let you set them from with itself as well, purely for convenience). Its been a while since I did any Windows coding though so I couldn't tell you off the top of my head, and I'm too lazy to go look.
The Mozilla apps in general do seem to shun using standard approaches to things like this. At least they use local printers, though, they're not falling completely into the WordPerfect trap of providing "better" (mostly but not always) solutions to things they don't need to mess with. This is just an example of failing to take existing (yet OS-dependent) features into account.
...they didn't realise at that point that this could be launched without user interaction, that is what was posted to full disclosure - when that was written it was believed that a user had to be fooled into clicking on that link - a whole different ballgame.
Be fair. A slightly different ballgame. You're still executing arbitrary code from an insecure site in a secure context without a sandbox.
Yup. Because Mozilla, as a local application, has a much higher set of privs than a remote website does. This is basically taking code (high-level instructions, but code) from a known insecure zone and telling the OS to run it without any built-in safeguards. And what do you know: we have an exploit.
Here's a fun example of how IE gets it right. Take the URI file:///c:/windows/system32/mspaint.exe from another example on this discussion. Type that into start/run on a Windows box - it works. Type it into the Address bar of IE - it works. Toss it into a webpage on the local machine and click on it - it works. Toss that webpage onto a remote server and click on it - it doesn't work any more. Different behaviors for different levels of trust. Mozilla defeats this by passing things to the shell with the same level of trust as the user has given it, the local program, which includes the (necessary) ability to mess with the filesystem.
Also note that this is a problem with Windows URI Handler rather than Mozilla. Mozilla passes any protocol it doesn't understand to Windows, and Windows uses it to execute a local file. That's why this problem doesn't exist in anything but Windows.
By that argument if someone asked Mozilla to delete some files, but rather than deleting them through unlink() it passed it off to the shell to do through rm, that would be Linux's fault? C'mon. At best, its passing unvalidated input to a secure user context (which Mozilla needs to allow its users to do things like save files, delete cache entries, etc).
This just goes to show that Microsoft makes insecure software, and that insecurity often bleeds into otherwise trustworthy programs
Hey, I like Firefox as much as the next guy (especially its DOM explorer), but there's no need to join the FUD camp to bash its rivals.
Not really - there's a difference between typing it into the "Address" bar and clicking on it in some website. Or clicking a link within your intranet for that matter. IE has different security zones with different models for just this reason. In fact, checking it on a website shows that clicking on such a link as you provided does absolutely nothing, whereas keying it into the address bar launches the app. Your security settings may vary, of course.
[W]what makes Mozilla different is that bugs are fixed instantly...
------- Additional Comment #2 From Jesse Ruderman 2002-09-11 16:58 PDT [reply] ------- It's not hard for a malicious site to get a visitor to click a link. Requiring a click or an equivalent keyboard action can be useful for limiting how much a web site can annoy you (pop-up windows, etc.) but I don't think it's useful for larger security issues.
Not to be too trollish, but if you are building a bridge to hold 10 tons and it ends up holding 100 tons, you are wasting resources.
That's easy enough to do when you're doing something that's been done thousands of times before. Very difficult when breaking new ground (so to speak). And, to stick with your bridge theme, its the reason that the Brooklyn bridge is still standing when almost none of its contemporaries are. The designer realized that he was going beyond the bounds of his experience and the current state-of-the-art (as the rover builders did), and intentionally overengineered it - not to compensate for the factors he had already taken into account, but to give it a fighting chance against factors he didn't even know existed. Same goes for Mars, doubly so because there's no hope of a mid-project refit.
I may be reading you wrong, but my impression is that you were saying that commercial enterprise software is better-documented and better-understood in general *because* it's commercial and commercial organizations can provide a level of "thoroughness" that F/LOSS doesn't. I disagree. I think mature F/LOSS projects typically have far more information available, although it may not be packaged quite as neatly (mailing list archives vs. formal best practices documents).
I'd say its about the same, although part of what I like are things like best practices documents (and while there are some good OSS examples, a lot of more recent docs - a la the ORA series - leave a lot to be desired... lots of help for people in months 2..6 of an adoption, but not much targeted at the enterprise or the true novice).
Its more about overall system maturity. JBoss is a good example of a mature, well-documented OSS product. Apache would be another one. I don't think that anyone would seriously suggest using something like Mono in an enterprise-level project at this point though, just because there'd be too much risk of being the first team to find things out about it if you know what I mean.
The MySQL example was in a side-response (don't remember if it was in the direct thread or just close) to someone talking about moving from MySQL which they understood, to Sql Server (which they didn't) and having problems. Sql Server has its share of issues, but they're very well known and worked around by those who use it on a regular basis - or by those willing to do a little research by reading easy-to-find documentation. Note: I'm not a Sql Server fan, just continuing the conversation.
As for the bugs/mailing-lists - I guess the point that I was trying to make is that I don't want to be getting into those situations in the first place. Its good to be able to do the research, but better to have followed a best-practices type guide and never needed it, because hundreds of people have used the product in the same way that you're using it. Which is often the case for the larger closed-source products (from vendors like ORCL, MSFT, etc). And the larger open-source ones too, but there aren't (yet) as many of those targeted at the same issues.
Someone else on the thread brought up the problem of integrating two disparate Windows 2003 Active Directory installations when two companies merge. I know nothing about this, but I would have to guess that there are people out there who've done it before, and can give you a recipie (or at least a decent consultant with good references). On similar issues with smaller market-share projects, even if you can talk to the developer, there's no guarantee that anyone has had the same issue that you're experiencing. Sure, with the larger products there's no guarantee either, but its a much stronger probability.
Again, I have no problem with OSS challenging the big closed guys, but my original point was that going with a large industry standard solution - regardless of the source license - brings with it a lot of additional benefits in the areas of predictibility vs. going with a quickly-evolving OSS-dev-style application.
It's just a matter of maturity and, to a large extent, how many other enterprises are using the product.
Absolutely agreed. And for better or for worse, when a lot of people are using MSFT products, that's a lot of eyeballs - at least on their behavior. They may not be reading the source code, but then again neither are the vast majority of OSS users these days. And from an end-user/admins point of view, I'm more concerned about known, repeatable behaviors than "perfect" behaviors.
At least for my day job. Hobbies are another matter entirely, for which I say bring on the lightly tested new releases! But that doesn't help to discuss why more businesses aren't jumping to emerging software for their enterprise apps.
Ah, yes - although that law's been around for decades at this point, sorry. I even felt like adding, "I'm sure that there's a mistake in there somewhere too," but didn't bother. But hey, my... how did the parent post put it - "grammer" I believe - was spot on at least.
Er, that was my point. There is no non-upgrade price. Everyone is upgrading already. But one could reasonably posit that it would be more than the upgrade price, hence my $499. Sorry for not using enough emoticons and faux-html to be clear:)
I always wondered why they don't use off the shelf VHS tapes for data backup. You could probably build an inexpensive, yet reasonably reliable backup unit from the mechanism+record/playback heads of a low end VCR.
You said it yourself. "Reasonably reliable." For the vast majority of us in the business world, the whole reason that we make backups is because disks themselves are only "Reasonably reliable." I'm paying for "highly reliable" or greater. Without it, I'll take my chances on a nice RAID array with redundant error-checking controllers or something and not worry. But if I don't know that my backups are good, then they're almost worthless.
As others have mentioned elsewhere, this brings up the good point - test your backups! And your whole disaster recovery scenario for that matter. If you wouldn't bet the company on a test, make sure that you're not betting the company on the real thing.
Slashdot Mirror
I can safely expect my violin not to emit strange odors, not to grope me, and not to make me taste onions when I play it.
Hmm. I think I may need to have my violin checked out then.
I would pick holes in just about all his arguments - he seems to ignore the initial training and years of condition on how a car works. The same with a TV set. I'm sure I could find somebody that has horror stories trying to figure them out for the first time and could write an article on how counter-intuitive these items are (like, why do you need a key for a car ignition when you've unlocked the door?).
The car designers agree with you. That's why newer cars, such as some MBs and, IIRC, the Toyota Prius (and probably others) don't require you to do so. The Prius is the best example - you get in, you touch the power button to let the car know that you want to move (since activating the car when you just want to get something from inside it is potentially hazardous), and you go. So while your comment was tongue-in-cheek, its being addressed even so.
I've seen many articles like this on the VCR, not to mention ones complaining about more sophisticated cars, kitchen appliances, telephones, heating/air-conditioning systems, all of them wanting the systems to be simpler (and most, like this one, wanting to return to simpler times).
And why not? Look at the PVR - isn't that a VCR made simpler, addressing the problem domain ("I want to watch Buffy later") rather than the system domain ("I want to make tape insertion smoother")? Or an A/C system - my thermostat lets me set an upper/lower bound. It does everything else - even switching from furnace to A/C as needed. After all, its not like the problem domain of wanting a stable house temperature has changed, so why should the interfaces get more complicated?
If there is complexity, it maps directly to the problem domain and not to the UI design. That makes it far easier to deal with, because it "just makes sense."
Nicely said.
Think about how much more complex it would be to configure and maintain a vehicle that: ...
Yes, well. But you know what? Some of your examples already exist. Minivans, etc, have reconfigurable interiors. I've had two cars with adjustable suspensions. You know something?
At no point did I have do select an interior, or make a suspension setting, just to go to the store! And that's the point of the article. Sure, knowing that I can tweak my suspension to ride 2" lower and a little firmer may make for a better highway ride. But I can ignore that and still accomplish my objective - going from point A to point B. If I had a minivan, I wouldn't have to remove and reinstall the seats every time that I drove it. Or every time I wanted to change the radio station.
Compare this with the much-attacked system on modern Mercedes vehicles, where accomplishing simple tasks was made harder through their new interface. Not only are they redoing it, but their competitors (Audi, BMW, et al) all tout the friendliness and intuitiveness of their interfaces now. I'd say that its important to a lot of people.
The most common mistake that non-techies make is the assumption that the computer understands the context the same way you do. It doesn't.
And the most common mistake that techies make is that non-techies care. Heck, a car doesn't move in the same way that a human moves - it rolls, its got an engine, etc. And people used to have to know a ton about how it worked to get it to move anywhere at all reliably. Now they don't. The same thing is happening with computer software, and about time too.
With a PS2/XBox/Gamecube game they all have the same hardware so any settings that are hardware reliant can be pre-set. With computers we cannot assume the hardware platform, or Operating system to be run on. For example for a game or high graphics use program. What video card is used? how much memory does it have? And then there are things that we need to know for some other features.
Yes, but surely most modern games can probe your system rather than asking you, the user, how much memory your system has. Ideally they would start out by doing some calculations and setting the highest level of detail possible while still retaining a decent frame rate. This could then be tweaked to the end-user's desire, but people who just want to sit down and try out a new game can at least get going easily. I haven't played any new games for years, do they really not do this already?
The big problem is... as programmers we can't assume what features the customers are going to use 90% of the time unless the software is for one specific company, and only one use in that company. Take an Inventory system for example.. do the Cashiers at the store care how the stuff is entered to the Database? No, they just wanna be able to scan the customer product, and tell them how much it costs.
That was kind of the point of the article too. The cashiers shouldn't have to know. If there are some circumstances where seeing that information would be useful then by all means continue making it available, but discretely and out of the standard flow.
Do you use Excel "If" functions? I do,..
And I generally don't. But the IF() feature in Excel almost never intudes into my Excel world and when it does, it does so as insignificantly as possible (showing up as one line in a drop-down). Not a problem.
That's another great book for UI design. It talks about the UIs that are all around us. Ever encountered a glass door (shopping malls are bad at this) with a bar that goes all the way across it, mirrored on the other side? Do you push, or pull? On the left or on the right? Its not difficult, but it is an example of bad UI design. Contrast that to a door with a flat "Push" panel on one side, backed by a protruding handle on the other. You now whether you're pushing or pulling, and on which side of the door to perform the action. No documentation required, almost zero chance of failure - this door wants to be opened and makes it easy for you. A lot of computer software has exactly the same design mentality as the first door. Or worse, because the door has been "skinned" to look like a slice of pizza as well.
Using the GPS and the automobile are not really related in that way. However, before using the GPS (not the car) you do need to setup a few features before using it. For example, adding the location for your house, the area in which you live or will be searching for addresses to. Now, if you want to complain about GPS and features/setup, let's talk about how they need to ALL be voice activated or touch screens capable...
What? Oh, please. This is exactly the kind of problem that we have in a lot of software, especially smaller projects. First of all, why should I tell the car where I live just because I want to find the nearest Taco Bell? A perfect (although unintended) example.
As far as Televisions go.. this really isn't the case anymore. With more and more high-end TVs taking over the market and as they continue to do so in the future, thanks in part to HDTV, there will be a brutal setup process just to turn it on and start watching any kind of TV.
My TV has an annoying tendency to go into a reconfigure-me mode if its been without power for too long. Oddly enough, it never loses its settings (weird). Anyway, you know what I do? Its the equiv. of Next->Next->Next->Next->OK but more annoying.
Even if it did lose its settings, instead of prompting me to check the convergence it could just power on with a set of defaults. Probe to see if a coax is attached. If it is, check to see if there are channels with signals on them. Check to see if there are powered devices on the line-in and component-in ports. All of that. Then it could stick a little note up in the main menu that says, "You have not performed advanced configuration yet. Doing so will result in a superior picture. Press (X) to configure your TV." Or something.
The vast majority of programs fail to properly guard against user input. Its no different than the number of non-bind-var database applications that don't properly escape characters every time, allowing you to enter in a username like x'; delete * from users; and have it actually go through. This kind of hole is a lot more prevelant than most people would like to admit - both at a filesystem and at a database level. One of those things that people tend to ignore when they wonder why it takes large companies so long (and costs so much money) to do development is the testing and prevention of security holes like this. And they still appear anyway - but a whole lot less than they might.
Mozilla hands off protocols to windows in a simplistic way because it is not a part of the OS - just as any other program does.
Ah, but the difference is that Mozilla isn't taking protocols that, say, the user has entered when looking up a file, or URIs that were generated at compile-time - but rather, URIs that were pulled randomly from the 'net. Very few other programs do that, and that's the key difference here.
And it should be pointed out (ideally in the writeup, but who are we kidding here) that this is specifically talking about UPCs. Barcodes are still an unregulated item, as are other generics like "words", "sentences" and "labels".
But yes, there's a lot of rewriting to be done. The actual mods will be fairly simple, even on older systems, but the hard (and expensive) part comes when its time to test all of the millions of lines of code that hadn't changed in years, that have now just been impacted. And yes, in enterprise software you should test everything that might have been impacted - just in case.
Luckily most UPC-aware software doesn't try to decode it, but either reads it, writes it, or treats it as a lookup key. That makes life an order of magnitude easier than it might have been.
--
Enterprise software - for when "Close enough" doesn't cut it.
Insightful? Funny, maybe (not IMO, but I could see it), but insightful? C'mon.
Whoop, there goes another karma point for me...
An interesting piece of vitriolic prose. I'm only going to comment on one sentence though:
Where is the phone number I can call to promptly and properly have Illegal or Undesirable Aliens DEPORTED?
And there you raised my hackles. Because my friend, to me what makes the United States great is not so much its constitution, or its purported love of "freedom," but its process. It is a country, more than almost any others, founded on law. There is no arbitrary "will of the people" just as there is no "droigt de seignuer". The same law, for one and all.
So. Deport illegal aliens? Sure - the law of the land is written such that that is the proper response. Deport undesirable aliens? Never! The day that we start (started?) allowing our personal biases to override the rule of law is (was?) a sad day for these United States.
BTW, thanks for the civilized discussion - its sufficiently rare enough on /. to have a such a thing that its worth pointing out, IMO.
The man pages on BSD simply rock. As opposed to the man pages on most Linux distros, many of which say, "This hasn't been updated since the dawn of time, you should be using our proprietary hypertext system 'info' to get your information, dumbass." Not including the ones that were taken (as is allowed under the BSD license) directly from the BSD folk, of course. And most tools written by people influenced by their system provide equally usable man pages. Its a great cycle of documentary bliss! Or something. Either way, its pretty cool.
Is the check for security clearance within MS Windows accessible to every local program?
.cpl to let you set them from with itself as well, purely for convenience). Its been a while since I did any Windows coding though so I couldn't tell you off the top of my head, and I'm too lazy to go look.
Urm, I surely do believe so. That's why the user can even set it in their control panel - Internet Settings I believe - rather than just in IE (although IE does wrapper that
The Mozilla apps in general do seem to shun using standard approaches to things like this. At least they use local printers, though, they're not falling completely into the WordPerfect trap of providing "better" (mostly but not always) solutions to things they don't need to mess with. This is just an example of failing to take existing (yet OS-dependent) features into account.
...they didn't realise at that point that this could be launched without user interaction, that is what was posted to full disclosure - when that was written it was believed that a user had to be fooled into clicking on that link - a whole different ballgame.
Be fair. A slightly different ballgame. You're still executing arbitrary code from an insecure site in a secure context without a sandbox.
Is it still security hole in Mozilla????
Yup. Because Mozilla, as a local application, has a much higher set of privs than a remote website does. This is basically taking code (high-level instructions, but code) from a known insecure zone and telling the OS to run it without any built-in safeguards. And what do you know: we have an exploit.
Here's a fun example of how IE gets it right. Take the URI file:///c:/windows/system32/mspaint.exe from another example on this discussion. Type that into start/run on a Windows box - it works. Type it into the Address bar of IE - it works. Toss it into a webpage on the local machine and click on it - it works. Toss that webpage onto a remote server and click on it - it doesn't work any more. Different behaviors for different levels of trust. Mozilla defeats this by passing things to the shell with the same level of trust as the user has given it, the local program, which includes the (necessary) ability to mess with the filesystem.
Also note that this is a problem with Windows URI Handler rather than Mozilla. Mozilla passes any protocol it doesn't understand to Windows, and Windows uses it to execute a local file. That's why this problem doesn't exist in anything but Windows.
By that argument if someone asked Mozilla to delete some files, but rather than deleting them through unlink() it passed it off to the shell to do through rm, that would be Linux's fault? C'mon. At best, its passing unvalidated input to a secure user context (which Mozilla needs to allow its users to do things like save files, delete cache entries, etc).
This just goes to show that Microsoft makes insecure software, and that insecurity often bleeds into otherwise trustworthy programs
Hey, I like Firefox as much as the next guy (especially its DOM explorer), but there's no need to join the FUD camp to bash its rivals.
Not really - there's a difference between typing it into the "Address" bar and clicking on it in some website. Or clicking a link within your intranet for that matter. IE has different security zones with different models for just this reason. In fact, checking it on a website shows that clicking on such a link as you provided does absolutely nothing, whereas keying it into the address bar launches the app. Your security settings may vary, of course.
[W]what makes Mozilla different is that bugs are fixed instantly...
------- Additional Comment #2 From Jesse Ruderman 2002-09-11 16:58 PDT [reply] -------
It's not hard for a malicious site to get a visitor to click a link. Requiring
a click or an equivalent keyboard action can be useful for limiting how much a
web site can annoy you (pop-up windows, etc.) but I don't think it's useful for
larger security issues.
Er, yeah. Instantly. Cool.
Not to be too trollish, but if you are building a bridge to hold 10 tons and it ends up holding 100 tons, you are wasting resources.
That's easy enough to do when you're doing something that's been done thousands of times before. Very difficult when breaking new ground (so to speak). And, to stick with your bridge theme, its the reason that the Brooklyn bridge is still standing when almost none of its contemporaries are. The designer realized that he was going beyond the bounds of his experience and the current state-of-the-art (as the rover builders did), and intentionally overengineered it - not to compensate for the factors he had already taken into account, but to give it a fighting chance against factors he didn't even know existed. Same goes for Mars, doubly so because there's no hope of a mid-project refit.
I may be reading you wrong, but my impression is that you were saying that commercial enterprise software is better-documented and better-understood in general *because* it's commercial and commercial organizations can provide a level of "thoroughness" that F/LOSS doesn't. I disagree. I think mature F/LOSS projects typically have far more information available, although it may not be packaged quite as neatly (mailing list archives vs. formal best practices documents).
I'd say its about the same, although part of what I like are things like best practices documents (and while there are some good OSS examples, a lot of more recent docs - a la the ORA series - leave a lot to be desired... lots of help for people in months 2..6 of an adoption, but not much targeted at the enterprise or the true novice).
Its more about overall system maturity. JBoss is a good example of a mature, well-documented OSS product. Apache would be another one. I don't think that anyone would seriously suggest using something like Mono in an enterprise-level project at this point though, just because there'd be too much risk of being the first team to find things out about it if you know what I mean.
The MySQL example was in a side-response (don't remember if it was in the direct thread or just close) to someone talking about moving from MySQL which they understood, to Sql Server (which they didn't) and having problems. Sql Server has its share of issues, but they're very well known and worked around by those who use it on a regular basis - or by those willing to do a little research by reading easy-to-find documentation. Note: I'm not a Sql Server fan, just continuing the conversation.
As for the bugs/mailing-lists - I guess the point that I was trying to make is that I don't want to be getting into those situations in the first place. Its good to be able to do the research, but better to have followed a best-practices type guide and never needed it, because hundreds of people have used the product in the same way that you're using it. Which is often the case for the larger closed-source products (from vendors like ORCL, MSFT, etc). And the larger open-source ones too, but there aren't (yet) as many of those targeted at the same issues.
Someone else on the thread brought up the problem of integrating two disparate Windows 2003 Active Directory installations when two companies merge. I know nothing about this, but I would have to guess that there are people out there who've done it before, and can give you a recipie (or at least a decent consultant with good references). On similar issues with smaller market-share projects, even if you can talk to the developer, there's no guarantee that anyone has had the same issue that you're experiencing. Sure, with the larger products there's no guarantee either, but its a much stronger probability.
Again, I have no problem with OSS challenging the big closed guys, but my original point was that going with a large industry standard solution - regardless of the source license - brings with it a lot of additional benefits in the areas of predictibility vs. going with a quickly-evolving OSS-dev-style application.
It's just a matter of maturity and, to a large extent, how many other enterprises are using the product.
Absolutely agreed. And for better or for worse, when a lot of people are using MSFT products, that's a lot of eyeballs - at least on their behavior. They may not be reading the source code, but then again neither are the vast majority of OSS users these days. And from an end-user/admins point of view, I'm more concerned about known, repeatable behaviors than "perfect" behaviors.
At least for my day job. Hobbies are another matter entirely, for which I say bring on the lightly tested new releases! But that doesn't help to discuss why more businesses aren't jumping to emerging software for their enterprise apps.
Ah, yes - although that law's been around for decades at this point, sorry. I even felt like adding, "I'm sure that there's a mistake in there somewhere too," but didn't bother. But hey, my ... how did the parent post put it - "grammer" I believe - was spot on at least.
Er, that was my point. There is no non-upgrade price. Everyone is upgrading already. But one could reasonably posit that it would be more than the upgrade price, hence my $499. Sorry for not using enough emoticons and faux-html to be clear :)
I always wondered why they don't use off the shelf VHS tapes for data backup. You could probably build an inexpensive, yet reasonably reliable backup unit from the mechanism+record/playback heads of a low end VCR.
You said it yourself. "Reasonably reliable." For the vast majority of us in the business world, the whole reason that we make backups is because disks themselves are only "Reasonably reliable." I'm paying for "highly reliable" or greater. Without it, I'll take my chances on a nice RAID array with redundant error-checking controllers or something and not worry. But if I don't know that my backups are good, then they're almost worthless.
As others have mentioned elsewhere, this brings up the good point - test your backups! And your whole disaster recovery scenario for that matter. If you wouldn't bet the company on a test, make sure that you're not betting the company on the real thing.