The fact that both the US and the USSR had nuclear weapons during the cold war scared both sides into being unable to use them. Mutually Assured Destruction was a valid theory because USSR fell not by military attack but simple political failure.
There was a high probability that a nuclear war could have been started by accident, and all of Europe, most of the USSR, and much of the US could have been destroyed.
MAD was an irrational gamble with the lives of a billion people, the majority of whom didn't even have a say in the matter. The fact that we got lucky in the end doesn't make the policy any more defensible.
In fact, the biggest threat the USA faces today is not from any organized state but from stateless terrorists who would love to get ahold of nuclear weapons, but don't have a government worth of resources to develop what history has proven is quite a hard thing to come accross and control.
The biggest threat to the US is that pampered US voters can't deal with a probable long-term decline in the US economy and US power. Politicians will, as a consequence, engage in one ill-conceived military campaign after another. Terrorism is just the blowback.
What is "bullshit" is your reasoning from first principles:
plutonium and neptunium are _not_ chemically toxic in any way. in biological systems they are chemically inert as no cells are capable of processing it, and it cannot substitute for any element used in biological systems (unlike radium, which can substitute for calcium).
Substances don't have to be "processed biologically" or "substitute for any element" in order to be toxic or dangerous. Even something like microscopic gold particles or noble gasses can be toxic.
but don't just take my word for it. try here.
Yes, and that web site states "Extremely small particles of plutonium on the order of micrograms can cause lung cancer if inhaled into the lungs." Whether that makes Plutonium more toxic than botulism toxin or not is a matter of semantics. I suspect a microgram of botulism toxin won't kill you no matter how you are exposed to it.
And the same web site states: "The chemical and radiological toxicity of plutonium should be distinguished from the danger of plutonium." So, contrary to your ramblings, the very web site you point to attributes both chemical and radioactive toxicity to Plutonium.
I don't know the actual danger from ingesting, inhaling, or otherwise coming in contact with Plutonium. But neither do you, nor anybody else. What I do know is that ignorant fools like you are responsible for exposing people to risks that people never agreed to being exposed to willingly. You seem think that just because you are unimaginative and stupid enough to figure out how something could be dangerous, it's OK to dump the stuff on the world. That kind of hubris is why so many people distrust science and scientists so much.
The conservative and prudent thing to do is that, when we have a choice, and we do when it comes to weapons, energy, and products, we don't risk exposing people to substances unless those substances have been proven safe beyond a reasonable doubt.
Open source just seems to be a more efficient way of developing software in many cases, otherwise, it wouldn't be getting so popular. And, yes, like other more efficient production methods of the past (mechanized agriculture, factories, robotics, etc.), it kills jobs. Like, for example, jobs at Microsoft. It's always unfortunate when people lose their jobs, but they can usually get new ones. Overall, the economy is better off. In fact, in times of technological progress, job losses are usually more than made up for by gains in other areas.
If we only tried to optimize our economy for job creation, we could just have people crush rocks or copy books by hand, like people used to. But that's just not a very efficient way of using our human resources, so we aren't doing it. Well, it's the same with 20th century software development models in the 21st century. Sorry, but the days where someone could get fabulously rich with writing a BASIC interpreter in 8bit assembly language are simply over.
The imperfections may be subject of those two books, but I really doubt that they are subject to those two books.
Re:This isn't about making cool browsers...
on
Browser Wars 2004
·
· Score: 3, Insightful
It's much easier to write UI code in HTML with some JavaScript that it is to write the same UI code with C++ or any other language for that matter.
Yes, but that's not because HTML+JavaScript is such great technology, it's because C++ or Java using common toolkits are such awful technology for writing GUIs.
It's also not clear to me why we need a "standard" for this. If you are going to write applications, you can pick a good toolkit to go with that and just use that. In fact, if you like writing HTML-based apps but don't like the constraints browsers impose, chances are the toolkit you already have and use lets you do just that: use its HTML widget. In fact, you'll probably get embedded IE or embedded Mozilla out of that.
Would Apple kindly stop stepping on names already used by the open source community? Calling Macintosh OS 10 "OS X" was bad enough ("are you running X on your Mac"?).
Dashboard is Nat Friedman's implicit query system for Gnome. That's been around for a while.
Well, part of the problem is that these PH.d's are 35, and have no actual experience.
Maybe your problem is with your selection of Ph.D.'s. On a normal academic schedule, people should complete their Ph.D.'s in their mid-to-late 20's, and afterwards, they should be gaining experience in industry or as postdocs. Furthermore, good universities will connect them with practical problems all throughout their education.
If he's using someone else's money to live on, he owes that someone the patent/copyright.
We had such a system for physical labor--it was called "feudalism", and we got rid of it because it is both unjust and inefficient.
The fact is that if I use someone else's resource to produce something, I owe them a fair return, based on their risk and their investment. If they manage to extract more than justified by their risk and their investment, then they have taken an unfair advantage, and that is something that is incompatible both with the law and with the efficient functioning of our economy.
If people would stop bombing everything out of jealousy, there would be more money available for research that could improve the quality of life for all humans; what a waste!
Imagine how you would react if the Soviet Union had come to the US, installed a repressive monarchy, relocated all New Yorkers to New Mexico to make room for new settlers, and was making deals with the new American royal family to get raw materials delivered to them at bargain basement prices. That's how US actions present themselves to the people of the Middle East.
That doesn't justify terrorism or bombings, but it certainly goes far beyond your simplistic ideas that terrorism is motivated by just jealousy.
Sorry, in my opinion, this isn't up to Mozilla and its opinion. If a particular handler cannot be trusted with certain arguments then either the OS should not provide the handler and it should be disabled, or the application that the handler calls should check the supplied data.
There are two types of handlers: those without restrictions that deal with trusted input (stuff a user types) and those with restrictions that deal with untrusted input (stuff that comes in over the web). On a desktop, you need both because you have both kinds of input. Either the OS may provide them or applications.
The only effective solution IMHO, is a layer at the operating system level defining either how "safe" an application is or even better - for the application that registers the handler to judge for itself.
It's not a "level" of safety, you need two different APIs (or a flag). Applications that treat all input as untrusted are unsuitable for desktop use. However, applications that know what they are dealing with (and Mozilla does) can transform untrusted input into trusted input. In fact, they already do that all the time anyway.
Remember - most people on Windows use Internet Explorer. If Internet Explorer doesn't understand a URL, it passes it to the OS - that's where the security layer should be.
Well, why don't we put everything into the OS then? Mozilla can become an IE theme, with all the rendering and handling of all web standards implemented by the OS.
But Mozilla has written on its banner that it implements web standards, and it tries to implement them better than whatever Windows does. That means Mozilla need to know how to interpret HTML and how to interpret URLs/URIs that it encounters. As part of those operations, Mozilla is highly qualified to determine which URLs/URIs are "safe".
Furthermore, no matter where this security layer "should be", the fact is that it isn't in Windows and that the Mozilla developers knew that. Therefore, they should have addressed this problem with a Mozilla-based workaround until Windows implemented what they thought was "the right way". Leaving users with gaping security holes is never the right thing to do, no matter what disagreements there may be between OS designers and application designers.
I think this approach to brainstorming raises some questions.
Yes, user studies and user feedback are part of software development, and it is great to develop software that meets the needs of users.
On the other hand, think about what would happen if every research group working on machine learning started polling users about "ideas for machine learning to be incorporated into popular program X"? How many polls would/could people have time to respond to? Their attention and willingness to answer polls is limited; do research groups who manage to get their posts on Slashdot first get all the responses (and ideas)? Are all the responses shared publicly?
And are the people who came up with the idea going to be co-authors? Who owns the ideas, academically or legally? Does the university know about this and has it approved it? How does this behavior relate to Stanford's code of academic conduct? Other kinds of polls for research have to follow certain guidelines, does this one?
I'm not saying this way of approaching research is necessarily bad, but I think such questions need to be answered clearly and explicitly to potential participants. Pre-Internet, asking 1000 people for such responses required extensive preparation (renting rooms, mailings, etc.), and as part of that, there were mechanisms to answer such questions and plenty of time to think about them. These days, anybody can do something like this on a whim, and maybe that's good, but some questions probably still need to be thought through.
What about when you click on a 'mailto:' link? Do you want Mozilla to pop up and say it can't handle it? Or do you want it to use your default mail application to start up a compose message window?
It should verify that the supplied address strictly conforms to E-mail address standards and then invoke the user's default mail application.
In general, Mozilla can invoke protocol handlers whose function it knows after verifying that the arguments passed to those protocol handlers are safe for that protocol. It can do that for mailto: because it understands its semantics. It can't do that for shell: because it doesn't even recognize the protocol, let alone know what kinds of arguments would be safe to pass to that protocol handler.
My real point is that companies can be monopolies, so long as they stay off the public radar.
I fully agree with that. And "staying off the public radar" means behaving in ways that doesn't cause people real problems.
My dad works for one such company, but no one knows they are a monopoly so no one cares.
Nobody would care that Microsoft is a monopoly if Microsoft wouldn't use their monopoly to cause real people real problems. That's not a question of "hearing" about the existence of Microsoft's monopoly, it's a question of Microsoft's actual behavior and the impact it has.
I am simply pointing out a general trend.
Yes, and you are wrong: the mere existence of a monopoly doesn't bother people, what bothers people is if that monopoly causes them problems. And you just demonstrated it: even after hearing about Sysco's monopoly from you and looking at what they do, I still don't care because you have failed to make a persuasive argument to me that Sysco's current corporate behavior impacts my life significantly.
Go read up on Sysco if you want one (they control basically all grain silos in the US). The ones people care about are the one that get press time. The ones that stay low on the radar, almost nobody cares about.
And Sysco stays "low on the radar" because they don't make a hell of a lot of difference to most people's lives. Maybe bread is a few cents more expensive because of Sysco, big deal. Maybe Sysco executives are fabulously wealthy, but why should anybody care?
But Microsoft doesn't stay low on the radar: plenty of people have to buy software, use software, and deal with bugs in Microsoft software, software that they would never have chosen to buy on their own.
So, the difference between Sysco and Microsoft is not some accident of press coverage or some unfair persecution of Microsoft, it really is due to how their respective products and corporate policies impact people's lives.
There are plenty of companies who do not charge you for bug fixes.
Of course, you shouldn't have to pay for bug fixes--bug fixes are fixes for a defective product. If your car manufacturer designed your model of car with faulty brakes, it goes without saying that they have to fix it for free.
So, where does that leave us? You give the company a valuable piece of information and you get back something that you should get for free anyway and nothing else of value. That's what makes having a large user community so valuable: companies get lots of free testing done for them without ever having to pay for it.
"That's one of the reasons why it is so important to use open source alternatives"
Or buy software from companies that give you bug fixes and updates for free. My company, for example, will never charge for bug fixes.
It doesn't work that way because every product will have to be upgraded sooner or later. You can give me the bug fix "for free" next week, certain in the knowledge that next year, I'll have to upgrade anyway at whatever price you choose to set.
Or, to look at it differently, it just doesn't make sense to break up your pricing into "bug fixes" and "enhancements": ultimately, all the money you get goes into a big pot anyway. If I send you a bug report, that adds to the value of your proprietary software and your intellectual property, if I instead send a bug report to an OSS project, that adds to the value of software in whose ownership I effectively share. It's the difference between paying $50 to rent something for a year and paying $50 to buy the same thing; which one usually makes more sense?
There really isn't an inherent advantage of open source to closed source here. Both can be hit or miss.
I have no idea what you mean by "hit or miss". With OSS software, the license guarantees me a cost structure and availability that is under my control and that is predictable in perpetuity. The pricing and availability of your proprietary product are based on arbitrary and unpredictable business decisions by your management. Of course, the OSS software has a huge advantage in terms of lower risk. When there is a functionally and qualitatively similar OSS alternative to proprietary software, the OSS alternative is usually preferable to the proprietary software.
The one universal feature among all our licenses is that they are not tied to a specific version of the software.
So what? If I send you a description of a bug that would cost you $50 to find, that's $50 added to your profit. And if I don't send that bug report to a comparable open source project, the open source project is going to be short those $50.
Trying to argue that your bug fixes are "free" and you only charge for the software is like a car salesman giving you a $2000 discount on the car and charging you $2000 extra in upgrades: either way, you are going to pay for it.
I think you haven't had a very wide range of experience.
And I think you are either playing some marketing game, or you just haven't thought this through. And you are trying to hide your discomfort behind being patronizing.
You are supposed to be able to type any URI in a run box (Which does exactly the same thing, call a URI handler) or an address bar in IE (Which does the same thing, call a URI handler) and not have your system comprimised,
Whatever I type into a runbox is my business; if I type "shell:format c:/y" into a runbox and it formats my C: drive, that's not a security problem. Whatever I type may be stupid, but it is trusted.
The problem here is that Mozilla hands an untrusted input that it doesn't understand off to some part of the system that does not specify that it can securely handle untrusted input. In fact, if you think that that handler was designed to do the right thing for things that I might type into a run box, then that handler clearly is not designed to handle untrusted input. This distinction between untrusted and trusted URIs has existed as long as the web and Mozilla already makes it in many places. Even file:, http:, https:, and telnet: URIs have security implications and should not be handled by Mozilla without careful scrutiny.
Mozilla can't see the future. What if tomorrow MS adds shell2:, or even_less_secure_shell:?
Until "shell2:" becomes a well-known, well-defined web standard, there is never a reason for Mozilla to do anything with that protocol other than to complain loudly and refuse to touch it. Even if passing unknown protocols or mysterious URIs to the OS weren't the glaring security problem that it so obviously is, providing that kind of haphazard extensibility of the URI namespace is an assault on web standards. Microsoft may do that, but Mozilla should not become complicit in it.
In the end, Mozilla is forced to handle URIs the same way it handles file extensions... fob the responsiblity off on the user because Windows can't seem to get its act together
Mozilla is a web browser. Of course, Mozilla should figure out which protocols and file types are legitimate, what the security implications are of handling them, and how to handle them. That's one of the main functions of a web browser, and it is not at all the function of a desktop operating system.
No, they don't guarantee anything, so we shouldn't ever connect a windows machine to the internet?
The world would be better off for it. And Microsoft would quickly add the right documentation and guarantees to their APIs.
This is a function to handle an URL. So, it gets used for handling an URL.
And what makes you think that handling arbitrary URLs is secure? It clearly isn't secure even if you stick to the traditional web-based URLs, like http:, https:, telnet:, file:, etc.
More importantly, the Mozilla developers apparently knew about shell: but chose not to do anything about it because they thought it wasn't their problem.
Maybe a function to "display an image". It could just as well be "Display an image, unless the upper left pixel is red. In that case execute a shell command".
You are quite right: calling a function that is merely described in the documentation as a function to "display an image" is indeed highly insecure and might well involve the invocation of shells. An application like Mozilla should not invoke such a function and instead use something that is better defined. If there exists nothing on that platform that is better defined, then Mozilla can't securely provide that functionality and, hence, should not provide it at all.
Getting informed is the only way I know to get better. The day we don't get heated feedback I'll be concerned.
Every time you complain to any software company about a bug, a misfeature, or a problem, you are giving them something pretty valuable, something they would otherwise have to pay a lot of money to find through testing. But all your investment in time and bug reporting is repaid by--having to pay for the next upgrade.
It's like sending the company a $50 donation and then still paying $200 for the next upgrade.
That's one of the reasons why it is so important to use open source alternatives when available: when you report bugs in OSS, you don't pay for the resulting improvements over and over again.
Users, not programmers or lines of code, are the most valuable asset any software project has.
Because Microsoft wrote a dangerous handler that's not secure.
Do they guarantee anywhere that their handler API is secure against arbitrary Internet strings?
In fact, they don't, as should have been obvious to any developer who discovered the existence of shell:, which Mozilla developers did two years ago.
That fact that Microsoft themselves have fixed this bug in the next XP service pack doesn't tell you it's an MS bug?
No, it tells you that they are pragmatists.
(In any case, wouldn't you think that protocol handlers can be added via the registry anyway? So why would you expect this patch to make things secure?)
Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.
The only real options the Mozilla developers have is to black/white list known dangerous protocols or simply don't allow protocols Mozilla itself doesn't handle.
Bingo.
Neither are optimal. If you can't trust the OS you're on, you really limit yourself, bugs or not.
What's there to trust? Does the Windows API spec state "you can safely pass any untrusted string from the Internet to the protocol handler and be assured that the system will not be compromised"? If it doesn't say that, you can't expect that it handles untrusted content without bad consequences.
This really isn't any different than plugins, which are in a sense, external protocol handlers. i.e. they know how to handle certain content...just like a protocol handler. What if there is an exploit in a plugin?
It is quite different. Plug-ins are specifically and explicitly designed for Internet content, but protocol handlers are already used for handling URLs that serve local purposes and may do destructive things. So, while the Flash plugin may have bugs, it actually tries to be secure no matter what content you hand it, but the protocol handlers don't.
Agreed. It's not really a bug in the browser, it's a flaw in Windows.
No, it's not. If you want to fault Windows for something, you can fault it for not providing a protocol handler API that has a "trusted" boolean flag when you call it.
I think you have the wrong system. Having just rebuilt a failed power supply on a VAX TK50 tape drive
There have been many different VAX systems, many different tape drives, and many different mounting options. Some tape drives for the VAX were, indeed, mounted at shoulder level inside a closet (which may or may not have had other electronics inside it).
Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme
The question remains: why does Mozilla "hand off" stuff from the Internet to the operating system? It obviously can't determine that doing so is safe, so it shouldn't do it.
If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.
Oh, nonsense. Mozilla doesn't run with "real restricted user accounts" on UNIX/Linux either. The responsibility of deciding what is trusted and what is safe to "hand off" to the OS rests firmly with applications on most modern operating systems; every application programmer should know that, and it is not hard to program accordingly.
However, you can also run VAX VMS on a free i386 VAX emulator called SIMH [...] However, you can run NetBSD/VAX on it out of the box,
It's just not the same as loading the latest BSD distribution tape into the closet-sized tape drive and hearing the gentle rumbling of the disk drives on their "spin cycle".
Slashdot Mirror
The fact that both the US and the USSR had nuclear weapons during the cold war scared both sides into being unable to use them. Mutually Assured Destruction was a valid theory because USSR fell not by military attack but simple political failure.
There was a high probability that a nuclear war could have been started by accident, and all of Europe, most of the USSR, and much of the US could have been destroyed.
MAD was an irrational gamble with the lives of a billion people, the majority of whom didn't even have a say in the matter. The fact that we got lucky in the end doesn't make the policy any more defensible.
In fact, the biggest threat the USA faces today is not from any organized state but from stateless terrorists who would love to get ahold of nuclear weapons, but don't have a government worth of resources to develop what history has proven is quite a hard thing to come accross and control.
The biggest threat to the US is that pampered US voters can't deal with a probable long-term decline in the US economy and US power. Politicians will, as a consequence, engage in one ill-conceived military campaign after another. Terrorism is just the blowback.
Substances don't have to be "processed biologically" or "substitute for any element" in order to be toxic or dangerous. Even something like microscopic gold particles or noble gasses can be toxic.
but don't just take my word for it. try here.
Yes, and that web site states "Extremely small particles of plutonium on the order of micrograms can cause lung cancer if inhaled into the lungs." Whether that makes Plutonium more toxic than botulism toxin or not is a matter of semantics. I suspect a microgram of botulism toxin won't kill you no matter how you are exposed to it.
And the same web site states: "The chemical and radiological toxicity of plutonium should be distinguished from the danger of plutonium." So, contrary to your ramblings, the very web site you point to attributes both chemical and radioactive toxicity to Plutonium.
I don't know the actual danger from ingesting, inhaling, or otherwise coming in contact with Plutonium. But neither do you, nor anybody else. What I do know is that ignorant fools like you are responsible for exposing people to risks that people never agreed to being exposed to willingly. You seem think that just because you are unimaginative and stupid enough to figure out how something could be dangerous, it's OK to dump the stuff on the world. That kind of hubris is why so many people distrust science and scientists so much.
The conservative and prudent thing to do is that, when we have a choice, and we do when it comes to weapons, energy, and products, we don't risk exposing people to substances unless those substances have been proven safe beyond a reasonable doubt.
Open source just seems to be a more efficient way of developing software in many cases, otherwise, it wouldn't be getting so popular. And, yes, like other more efficient production methods of the past (mechanized agriculture, factories, robotics, etc.), it kills jobs. Like, for example, jobs at Microsoft. It's always unfortunate when people lose their jobs, but they can usually get new ones. Overall, the economy is better off. In fact, in times of technological progress, job losses are usually more than made up for by gains in other areas.
If we only tried to optimize our economy for job creation, we could just have people crush rocks or copy books by hand, like people used to. But that's just not a very efficient way of using our human resources, so we aren't doing it. Well, it's the same with 20th century software development models in the 21st century. Sorry, but the days where someone could get fabulously rich with writing a BASIC interpreter in 8bit assembly language are simply over.
The imperfections may be subject of those two books, but I really doubt that they are subject to those two books.
It's much easier to write UI code in HTML with some JavaScript that it is to write the same UI code with C++ or any other language for that matter.
Yes, but that's not because HTML+JavaScript is such great technology, it's because C++ or Java using common toolkits are such awful technology for writing GUIs.
It's also not clear to me why we need a "standard" for this. If you are going to write applications, you can pick a good toolkit to go with that and just use that. In fact, if you like writing HTML-based apps but don't like the constraints browsers impose, chances are the toolkit you already have and use lets you do just that: use its HTML widget. In fact, you'll probably get embedded IE or embedded Mozilla out of that.
Would Apple kindly stop stepping on names already used by the open source community? Calling Macintosh OS 10 "OS X" was bad enough ("are you running X on your Mac"?).
Dashboard is Nat Friedman's implicit query system for Gnome. That's been around for a while.
Well, part of the problem is that these PH.d's are 35, and have no actual experience.
Maybe your problem is with your selection of Ph.D.'s. On a normal academic schedule, people should complete their Ph.D.'s in their mid-to-late 20's, and afterwards, they should be gaining experience in industry or as postdocs. Furthermore, good universities will connect them with practical problems all throughout their education.
If he's using someone else's money to live on, he owes that someone the patent/copyright.
We had such a system for physical labor--it was called "feudalism", and we got rid of it because it is both unjust and inefficient.
The fact is that if I use someone else's resource to produce something, I owe them a fair return, based on their risk and their investment. If they manage to extract more than justified by their risk and their investment, then they have taken an unfair advantage, and that is something that is incompatible both with the law and with the efficient functioning of our economy.
If people would stop bombing everything out of jealousy, there would be more money available for research that could improve the quality of life for all humans; what a waste!
Imagine how you would react if the Soviet Union had come to the US, installed a repressive monarchy, relocated all New Yorkers to New Mexico to make room for new settlers, and was making deals with the new American royal family to get raw materials delivered to them at bargain basement prices. That's how US actions present themselves to the people of the Middle East.
That doesn't justify terrorism or bombings, but it certainly goes far beyond your simplistic ideas that terrorism is motivated by just jealousy.
Sorry, in my opinion, this isn't up to Mozilla and its opinion. If a particular handler cannot be trusted with certain arguments then either the OS should not provide the handler and it should be disabled, or the application that the handler calls should check the supplied data.
There are two types of handlers: those without restrictions that deal with trusted input (stuff a user types) and those with restrictions that deal with untrusted input (stuff that comes in over the web). On a desktop, you need both because you have both kinds of input. Either the OS may provide them or applications.
The only effective solution IMHO, is a layer at the operating system level defining either how "safe" an application is or even better - for the application that registers the handler to judge for itself.
It's not a "level" of safety, you need two different APIs (or a flag). Applications that treat all input as untrusted are unsuitable for desktop use. However, applications that know what they are dealing with (and Mozilla does) can transform untrusted input into trusted input. In fact, they already do that all the time anyway.
Remember - most people on Windows use Internet Explorer. If Internet Explorer doesn't understand a URL, it passes it to the OS - that's where the security layer should be.
Well, why don't we put everything into the OS then? Mozilla can become an IE theme, with all the rendering and handling of all web standards implemented by the OS.
But Mozilla has written on its banner that it implements web standards, and it tries to implement them better than whatever Windows does. That means Mozilla need to know how to interpret HTML and how to interpret URLs/URIs that it encounters. As part of those operations, Mozilla is highly qualified to determine which URLs/URIs are "safe".
Furthermore, no matter where this security layer "should be", the fact is that it isn't in Windows and that the Mozilla developers knew that. Therefore, they should have addressed this problem with a Mozilla-based workaround until Windows implemented what they thought was "the right way". Leaving users with gaping security holes is never the right thing to do, no matter what disagreements there may be between OS designers and application designers.
I think this approach to brainstorming raises some questions.
Yes, user studies and user feedback are part of software development, and it is great to develop software that meets the needs of users.
On the other hand, think about what would happen if every research group working on machine learning started polling users about "ideas for machine learning to be incorporated into popular program X"? How many polls would/could people have time to respond to? Their attention and willingness to answer polls is limited; do research groups who manage to get their posts on Slashdot first get all the responses (and ideas)? Are all the responses shared publicly?
And are the people who came up with the idea going to be co-authors? Who owns the ideas, academically or legally? Does the university know about this and has it approved it? How does this behavior relate to Stanford's code of academic conduct? Other kinds of polls for research have to follow certain guidelines, does this one?
I'm not saying this way of approaching research is necessarily bad, but I think such questions need to be answered clearly and explicitly to potential participants. Pre-Internet, asking 1000 people for such responses required extensive preparation (renting rooms, mailings, etc.), and as part of that, there were mechanisms to answer such questions and plenty of time to think about them. These days, anybody can do something like this on a whim, and maybe that's good, but some questions probably still need to be thought through.
What about when you click on a 'mailto:' link? Do you want Mozilla to pop up and say it can't handle it? Or do you want it to use your default mail application to start up a compose message window?
It should verify that the supplied address strictly conforms to E-mail address standards and then invoke the user's default mail application.
In general, Mozilla can invoke protocol handlers whose function it knows after verifying that the arguments passed to those protocol handlers are safe for that protocol. It can do that for mailto: because it understands its semantics. It can't do that for shell: because it doesn't even recognize the protocol, let alone know what kinds of arguments would be safe to pass to that protocol handler.
My real point is that companies can be monopolies, so long as they stay off the public radar.
I fully agree with that. And "staying off the public radar" means behaving in ways that doesn't cause people real problems.
My dad works for one such company, but no one knows they are a monopoly so no one cares.
Nobody would care that Microsoft is a monopoly if Microsoft wouldn't use their monopoly to cause real people real problems. That's not a question of "hearing" about the existence of Microsoft's monopoly, it's a question of Microsoft's actual behavior and the impact it has.
I am simply pointing out a general trend.
Yes, and you are wrong: the mere existence of a monopoly doesn't bother people, what bothers people is if that monopoly causes them problems. And you just demonstrated it: even after hearing about Sysco's monopoly from you and looking at what they do, I still don't care because you have failed to make a persuasive argument to me that Sysco's current corporate behavior impacts my life significantly.
Go read up on Sysco if you want one (they control basically all grain silos in the US). The ones people care about are the one that get press time. The ones that stay low on the radar, almost nobody cares about.
And Sysco stays "low on the radar" because they don't make a hell of a lot of difference to most people's lives. Maybe bread is a few cents more expensive because of Sysco, big deal. Maybe Sysco executives are fabulously wealthy, but why should anybody care?
But Microsoft doesn't stay low on the radar: plenty of people have to buy software, use software, and deal with bugs in Microsoft software, software that they would never have chosen to buy on their own.
So, the difference between Sysco and Microsoft is not some accident of press coverage or some unfair persecution of Microsoft, it really is due to how their respective products and corporate policies impact people's lives.
There are plenty of companies who do not charge you for bug fixes.
Of course, you shouldn't have to pay for bug fixes--bug fixes are fixes for a defective product. If your car manufacturer designed your model of car with faulty brakes, it goes without saying that they have to fix it for free.
So, where does that leave us? You give the company a valuable piece of information and you get back something that you should get for free anyway and nothing else of value. That's what makes having a large user community so valuable: companies get lots of free testing done for them without ever having to pay for it.
"That's one of the reasons why it is so important to use open source alternatives"
Or buy software from companies that give you bug fixes and updates for free. My company, for example, will never charge for bug fixes.
It doesn't work that way because every product will have to be upgraded sooner or later. You can give me the bug fix "for free" next week, certain in the knowledge that next year, I'll have to upgrade anyway at whatever price you choose to set.
Or, to look at it differently, it just doesn't make sense to break up your pricing into "bug fixes" and "enhancements": ultimately, all the money you get goes into a big pot anyway. If I send you a bug report, that adds to the value of your proprietary software and your intellectual property, if I instead send a bug report to an OSS project, that adds to the value of software in whose ownership I effectively share. It's the difference between paying $50 to rent something for a year and paying $50 to buy the same thing; which one usually makes more sense?
There really isn't an inherent advantage of open source to closed source here. Both can be hit or miss.
I have no idea what you mean by "hit or miss". With OSS software, the license guarantees me a cost structure and availability that is under my control and that is predictable in perpetuity. The pricing and availability of your proprietary product are based on arbitrary and unpredictable business decisions by your management. Of course, the OSS software has a huge advantage in terms of lower risk. When there is a functionally and qualitatively similar OSS alternative to proprietary software, the OSS alternative is usually preferable to the proprietary software.
The one universal feature among all our licenses is that they are not tied to a specific version of the software.
So what? If I send you a description of a bug that would cost you $50 to find, that's $50 added to your profit. And if I don't send that bug report to a comparable open source project, the open source project is going to be short those $50.
Trying to argue that your bug fixes are "free" and you only charge for the software is like a car salesman giving you a $2000 discount on the car and charging you $2000 extra in upgrades: either way, you are going to pay for it.
I think you haven't had a very wide range of experience.
And I think you are either playing some marketing game, or you just haven't thought this through. And you are trying to hide your discomfort behind being patronizing.
You are supposed to be able to type any URI in a run box (Which does exactly the same thing, call a URI handler) or an address bar in IE (Which does the same thing, call a URI handler) and not have your system comprimised,
Whatever I type into a runbox is my business; if I type "shell:format c:/y" into a runbox and it formats my C: drive, that's not a security problem. Whatever I type may be stupid, but it is trusted.
The problem here is that Mozilla hands an untrusted input that it doesn't understand off to some part of the system that does not specify that it can securely handle untrusted input. In fact, if you think that that handler was designed to do the right thing for things that I might type into a run box, then that handler clearly is not designed to handle untrusted input. This distinction between untrusted and trusted URIs has existed as long as the web and Mozilla already makes it in many places. Even file:, http:, https:, and telnet: URIs have security implications and should not be handled by Mozilla without careful scrutiny.
Mozilla can't see the future. What if tomorrow MS adds shell2:, or even_less_secure_shell:?
Until "shell2:" becomes a well-known, well-defined web standard, there is never a reason for Mozilla to do anything with that protocol other than to complain loudly and refuse to touch it. Even if passing unknown protocols or mysterious URIs to the OS weren't the glaring security problem that it so obviously is, providing that kind of haphazard extensibility of the URI namespace is an assault on web standards. Microsoft may do that, but Mozilla should not become complicit in it.
In the end, Mozilla is forced to handle URIs the same way it handles file extensions... fob the responsiblity off on the user because Windows can't seem to get its act together
Mozilla is a web browser. Of course, Mozilla should figure out which protocols and file types are legitimate, what the security implications are of handling them, and how to handle them. That's one of the main functions of a web browser, and it is not at all the function of a desktop operating system.
No, they don't guarantee anything, so we shouldn't ever connect a windows machine to the internet?
The world would be better off for it. And Microsoft would quickly add the right documentation and guarantees to their APIs.
This is a function to handle an URL. So, it gets used for handling an URL.
And what makes you think that handling arbitrary URLs is secure? It clearly isn't secure even if you stick to the traditional web-based URLs, like http:, https:, telnet:, file:, etc.
More importantly, the Mozilla developers apparently knew about shell: but chose not to do anything about it because they thought it wasn't their problem.
Maybe a function to "display an image". It could just as well be "Display an image, unless the upper left pixel is red. In that case execute a shell command".
You are quite right: calling a function that is merely described in the documentation as a function to "display an image" is indeed highly insecure and might well involve the invocation of shells. An application like Mozilla should not invoke such a function and instead use something that is better defined. If there exists nothing on that platform that is better defined, then Mozilla can't securely provide that functionality and, hence, should not provide it at all.
Getting informed is the only way I know to get better. The day we don't get heated feedback I'll be concerned.
Every time you complain to any software company about a bug, a misfeature, or a problem, you are giving them something pretty valuable, something they would otherwise have to pay a lot of money to find through testing. But all your investment in time and bug reporting is repaid by--having to pay for the next upgrade.
It's like sending the company a $50 donation and then still paying $200 for the next upgrade.
That's one of the reasons why it is so important to use open source alternatives when available: when you report bugs in OSS, you don't pay for the resulting improvements over and over again.
Users, not programmers or lines of code, are the most valuable asset any software project has.
Because Microsoft wrote a dangerous handler that's not secure.
Do they guarantee anywhere that their handler API is secure against arbitrary Internet strings?
In fact, they don't, as should have been obvious to any developer who discovered the existence of shell:, which Mozilla developers did two years ago.
That fact that Microsoft themselves have fixed this bug in the next XP service pack doesn't tell you it's an MS bug?
No, it tells you that they are pragmatists.
(In any case, wouldn't you think that protocol handlers can be added via the registry anyway? So why would you expect this patch to make things secure?)
Mozilla should just handle the protocols it knows to handle and give an error message for everything else. What it is actually doing, handing off unknown things to the OS is just the sort of OS integration that causes so many problems for Microsoft applications as well.
The only real options the Mozilla developers have is to black/white list known dangerous protocols or simply don't allow protocols Mozilla itself doesn't handle.
Bingo.
Neither are optimal. If you can't trust the OS you're on, you really limit yourself, bugs or not.
What's there to trust? Does the Windows API spec state "you can safely pass any untrusted string from the Internet to the protocol handler and be assured that the system will not be compromised"? If it doesn't say that, you can't expect that it handles untrusted content without bad consequences.
This really isn't any different than plugins, which are in a sense, external protocol handlers. i.e. they know how to handle certain content...just like a protocol handler. What if there is an exploit in a plugin?
It is quite different. Plug-ins are specifically and explicitly designed for Internet content, but protocol handlers are already used for handling URLs that serve local purposes and may do destructive things. So, while the Flash plugin may have bugs, it actually tries to be secure no matter what content you hand it, but the protocol handlers don't.
Agreed. It's not really a bug in the browser, it's a flaw in Windows.
No, it's not. If you want to fault Windows for something, you can fault it for not providing a protocol handler API that has a "trusted" boolean flag when you call it.
I think you have the wrong system. Having just rebuilt a failed power supply on a VAX TK50 tape drive
There have been many different VAX systems, many different tape drives, and many different mounting options. Some tape drives for the VAX were, indeed, mounted at shoulder level inside a closet (which may or may not have had other electronics inside it).
Mozilla hands off schemes it doesn't know to the operating system (Windows), and WINDOWS executes the shell scheme
The question remains: why does Mozilla "hand off" stuff from the Internet to the operating system? It obviously can't determine that doing so is safe, so it shouldn't do it.
If you were able to run Windows with real restricted user accounts, this wouldn't really be such a problem.
Oh, nonsense. Mozilla doesn't run with "real restricted user accounts" on UNIX/Linux either. The responsibility of deciding what is trusted and what is safe to "hand off" to the OS rests firmly with applications on most modern operating systems; every application programmer should know that, and it is not hard to program accordingly.
However, you can also run VAX VMS on a free i386 VAX emulator called SIMH [...] However, you can run NetBSD/VAX on it out of the box,
It's just not the same as loading the latest BSD distribution tape into the closet-sized tape drive and hearing the gentle rumbling of the disk drives on their "spin cycle".