Pain from a statistics-collection point of view. I can tell when cookies are completely rejected, I can't tell that they're being forced to session-only.
Yes, Apple's information is Apple's property and should stay on their campus. However, it's Apple's responsibility to maintain confidentiality. Contrary to what your letter states, Nick Ciarelli hasn't signed any non-disclosure agreement with Apple. He's under no legal obligation to maintain confidentiality of their information if he obtains it lawfully. It's entirely up to them to keep it from reaching him, eg. by enforcing it's own NDAs so that people with the information don't give it to Nick in violation of the NDA. If Apple can't or doesn't do that, that's not Nick's problem. Yes, it'll hurt Apple. Again, that's not Nick's problem. Harsh, but true.
The only opening Apple has is if they can show that a) the information came to Nick from someone under NDA or otherwise obligated to maintain confidentiality, and b) Nick knew when he received the information (he can't be told afterwards, he has to know at the time) that that specific source is obligated to keep confidential that specific information. And being able to assume all Apple employees are under NDA isn't enough, assumption isn't knowledge (I got that hammered into me by Legal regarding the other side of that coin).
IANAL, but IIRC he's only under any obligation not to publish Apple's trade secrets if he obtained them while under some form of agreement with Apple to keep them confidential, or if he obtained them from someone who he at the time was or should have been aware was under such a confidentiality obligation. Note that Apple telling him the information is confidential and secret doesn't constitute his agreeing to keep it confidential, so legally Apple's warnings have only limited effect (basically they oblige him to check carefully if he receives that information from someone he knows has connections to Apple after he received the warnings). Apple's going to have to show that the person who supplied the information to Nick was under a confidentiality agreement (should be trivial) and that Nick knew this at the time he received the information (not so trivial).
That's one of the gotchas to NDAs: people who didn't sign them aren't bound by them.
When you make statements in public with my name attached to them when that name isn't also your own, you are presenting yourself as me. This is especially the case here, where the party mis-using the name knew it belonged to someone else and knew exactly who it belonged to. The two statements I made are very directly related.
He crossed the line when he used another person's name. You using a pseudonym is fine. You using my name as a psuedonym, effectively representing to other people that you are me, stands on the wrong side of the line.
This one should be a slam-dunk for Fitch. Whether the cartoon is protected free speech or not should be irrelevant. The right to free speech doesn't include the right to attribute your speech to someone else without permission.
Won't work. The shuttle doesn't have an emergency vehicle, and unless you pare payload to the absolute minimum it doesn't have enough delta-v to boost up to the orbit of the ISS and rendevous. If they found something wrong, there's four choices: fix it on the spot out of on-board supplies, have a rescue ship sent up, re-enter and pray, or sit there until the air runs out. #2 usually isn't possible, there's nothing that can make the launch window, #3 isn't real attractive and #4 downright sucks.
What we need is a low-orbit supply depot where the shuttle can pick up fuel, O2, scrubber filters and the like if it needs to.
The GPL has been the subject of legal battles. So far, every company that's been faced with copyright violation charges stemming from including GPL'd code in their products while not complying with the terms of the GPL has, after having their lawyers review the GPL, elected to comply with it's terms rather than risk going to court. Even companies like Cisco who certainly have good lawyers and enough money for that not to be an issue. If it were that easy to rip the GPL to shreds, wouldn't someone have decided they had a good enough chance of winning to take on the copyright holder?
You're forgetting RMS's comment: "It's free as in speech, not free as in beer.". You're talking about free-as-in-beer software, which doesn't have to be open-souce at all. Closed-source free software has all the problems you describe. I tend to call it no-payment-required software.
The distinction between free-as-in-speech software and open-source software is, IMHO, an important one, though. Open-source software is satisfied with the source as-in being available. Free software aims to make sure the source stays free. You can see the difference in how the BSD license affects software vs. the GPL. If you write software and release it under the BSD license, I can go and take that software, modify it, build a product around it, rake in the profits from that product and neither pay you a penny for it nor show anyone any of the modifications I've made to it. I can even release it under a non-BSD license that precludes access to the source code and you even as the author of the code can't touch me for it. This would make your code open-source but not free (because I can come along and make it non-open-source). The GPL, OTOH, goes a little further by insuring the code stays open-source. If I want to build my product around someone else's GPL'd code, I've got to keep the GPL'd code under the GPL. Note that it's not saying I have to keep my code under the GPL, but if I can't seperate my code from the original GPL'd code in the final product as delivered (the standard is basically that someone can, in the product as delivered, replace the GPL'd portion without breaking the product (unless the replacement code itself is broken)) then I'm either going to have to comply with the GPL or I'm going to have to go back to you and negotiate a non-GPL license for your code.
Both sorts of license have uses. So does the LGPL, which is a variation suitable for libraries or loadable modules. I think there's a use for all three types of licenses, and which one is best depends on what the author of the code wants done with it.
Exactly. But it depends on the corporations being able to tie that imported labor down to their initial low wages. So we close the loophole, and then make the corporations eat their own paens to "competition" by making them compete for labor. They've told us that if US labor can't offer a better deal than foreign labor then US labor should suffer, they should have no problem with the idea that if they can't offer their foreign labor a better deal than their competitor then they should suffer.:)
Yes, I know they won't go for that. That's why we smile sweetly and repeat their own lines back at them.
I don't care for the H1B program, but I can't come up with a rational reason for denying someone from another country work that doesn't boil down to "I don't want my job at risk.". I don' like that as a reason either. So rather than eliminate the H1B/L1 program, change it so those visas belong to the worker and not the company bringing them in. That way, when an H1B worker gets a better offer from the competition, he can walk under no more restriction than any US worker and take his H1B along with him. That should put a nice upward pressure on H1B wages, while not doing anything the companies that want low-paid H1B workers can complain about (or at least that can't be rebutted by the company's own arguments about competition).
I qualify under the settlement, but it wasn't satisfaction with Microsoft or simple indifference that made me not file for it. It's the settlement itself. What do I get from it? A paltry $5 off Word, for example, or $30 off the complete Office suite. That isn't even enough to offset the sales tax on those products. And I have to buy products from the same company being punished. They've abused their monopoly position, not to mention been the root cause of most of the virus headaches I have to deal with, and I should add to their profits? Why? If the settlement had involved MS having to give me a discount on competitor's products, I might've gone for it.
Re:Hopefully patent provision is not overbroad
on
Revising the GPL
·
· Score: 1
That last wouldn't be an issue for software you wrote yourself. The patent-protection clause could only remove any right to use the software granted by the GPL, and your right to use software you wrote yourself doesn't stem from the GPL.
No, the GPL is a copyright license. You don't need to accept the GPL to merely use the software (the GPL even says this explicitly if there's any question about the point). This is in stark contrast to an EULA. But, to make and distribute additional copies of the software you do need to accept the GPL. It's not the GPL that demands that, though, it's copyright law. Under copyright law, only the creator of a work or those he's granted a license to may make and distribute copies of the work. This is why the GPL's a license and not a contract: it's not a bilateral agreement, it's a unilateral grant of rights you normally wouldn't have. It's also not an unconditional and unlimited grant of those rights, but that doesn't make it not a license.
The above, BTW, is also why nobody will ever be sued for violation of the GPL. The suit (and possible criminal charges) will be for copyright infringement instead, since that's what you're doing if you distribute copies of a GPL'd work without accepting and abiding by the GPL.
Before, it was a slam dunk: if I couldn't read the EULA until after I'd bought the software, there wasn't any way the software company could claim I'd agreed to it by buying the software. Now, they can make that argument.
What we need really is a clear-cut decision that, unless I actually sign some other agreement before I fork over my money and walk out of the store with the software package, what occurred was a sale under the terms of the UCC and my rights and responsibilities as a buyer are those laid down by the UCC. That I am the owner free and clear of that copy of the software with the right to use it with no more need for a license than I need a license from the author of a book to read my copy of it, and that that EULA is an additional and after-the-fact contract that I'm free to refuse to agree to without affecting the sale that's already occurred.
There is. Firstly, Unix has been in use in university environments for nigh on a quarter-century now. Cracking systems has been a hobby for college comp-sci majors for as long as computer systems have been available to crack, and the operating-system-design classes in that major are often based around dissecting the actual source code of the very systems they're trying to crack which means they've far more detailed knowledge of Unix systems than of Windows. And yet, despite that, Unix remains relatively secure in that environment. Why should we assume this would change?
Secondly, track record. Apache on Linux is probably the most popular platform for Web servers based on NetCraft and other surveys. Apache on Unix of some sort definitely is not only more popular than any other option, it's more popular than all other options combined. Unix is the dominant OS there (and the traits that make Linux secure are simply the normal traits of any other Unix variant). Yet while we see regular compromises of Web servers, compromises of Apache on Unix are relatively rare. If it's not compromised often in an environment where it is the dominant platform, why would it be compromised often in another environment if it were the dominant platform?
I guess my question would be, why worry about passwords? Today, if I wanted to gain access to someone's account, I wouldn't bother trying to crack their password. I can get in faster through social engineering (get them to just tell me what their current password is) or, if I don't want to risk direct contact, infecting their computer with malware that lets them enter the password and then uses their current credentials. Note that the latter is even more effective in environments that have gone heavily to Active Directory and single-sign-on, since once I get my program running under the logged-in user account the system itself will handle most of the authentication for me by design.
If that were the case, then in 25 years of programming I'd've had a hard time not working on at least one project intended for resale. Instead, I find that all the software I've worked on was bespoke work for internal use. More, when I tally up the resumes I've evaluated over the years, few candidates had any intended-for-resale software projects listed and even for those few it made up the minority of their experience. Either I've had a ridiculously long run of 20s on the random-encounter dice or you haven't worked as a professional software developer and are getting your impressions from what you see at CompUSA.
For a software vendor, there's no advantage in opening the source code. If you aren't a vendor, though, there's several advantages:
For companies writing in-house software, development cost is important and resale value irrelevant. Open source allows you to grab software that does almost what you want and add the features you need, concentrating your development efforts (and costs) only on the bits that aren't already there. This also applies to pure customers, if there's an open-source package that does almost what they want except for one or two features they can hire someone to add just those features, with closed code you either live with the missing bits or go through an expensive switch.
For pure customers, they aren't at the mercy of the vendor for bugfixes. If a bug is critical to one customer but relatively unimportant to the vendor, with open source the customer can hire someone to fix the bug for them. It's the customer's decision which is cheaper: hiring it done or waiting for the vendor's update. With closed code, the customer has no choice but to wait until the vendor decides to fix the bug (which may be never for certain bugs).
For everyone, you're no longer at the mercy of the vendor's interests and product road-map. If what's good for you as a customer diverges from what's in the vendor's interest, with closed code customers have to either live with it or abandon the product entirely (an expensive proposition). With open source if the vendor/owner's idea of where the software should go diverge too far from that of a group of customers, the customers have the option of forking the code and investing (through employees or by contracting the work out) in developing the product along their path instead of the vendor's. This happened with the GCC compiler, nearly happened once with the X Consortium's X11 product and is happening currently with XFree86.
Remember, 95% of software isn't written for resale, so judging benefit purely from the POV of a software vendor misses an awful lot.
Then one of the other major kernel developers will take it over. This has in fact already happened (control being turned over, not Linus getting hit by a bus).
Heck what happens today when large factions of kernel developers disagree with him? ( Kernel debugger )
If a large fraction of the kernel developers have a fundamental disagreement with Linus, then they'll fork the kernel and maintain their own. This in fact happens fairly regularly, as with the -mm kernels in 2.4 and the -ac kernels in 2.2. If the majority of the Linux community finds this new branch of the kernel more useful than Linus' branch, Linus will find his branch becoming marginalized. We've already seen this in GCC when EGCS forked off in response to frustration over lack of support for newer CPUs in GCC itself.
I suspect that this hasn't happened to the kernel because, to take the kernel debugger as an example, while lots of people may disagree with Linus none of them have an argument good enough to conclusively trump his arguments. The kernel debugger is a good one for me because while I tend to agree a kernel debugger would be a really useful thing, I also agree with Linus that it'd make it awful tempting for newer developers or those not intimately familiar with the subsystem they're bug-hunting in to find and fix only the immediate symptom and not do the rooting around in the code which eventually leads to an understanding of the underlying cause of the problem.
Hist first item shows a fundamental problem right off. I've dealt with projects that were driven directly off the business requirements. The problem is that they were driven directly off the business requirements. The next project was for a slightly different set of business requirements, and because they were slightly different none of the work on the first project could readily be transferred over. By contrast in other projects I managed to divorce the business requirements from the actual work, and I could step back and instead of addressing the business requirements create tools and facilities that I could then use to address the business requirements. The next project in that line, with it's slightly different requirements, required only some relatively easy extensions to the existing work and we were in business. It took a fraction of the time. Most of the problems with business-process-driven software design and development, IMHO, is that it's too focused on the end result to be good at front-loading the solving of meta-problems that can speed up later work because solving the meta-problem doesn't provide any immediate advantages for the problem immediately to hand. In mathematical terms, it looks for a local maxima at the expense of an even better global maxima that's on the other side of a minima.
His second item about auditability also aims at the wrong point. When, for example, designing the control software for an ABS system, the goal is to have it work correctly. All else, auditability, certifications and such, are supposed to be means to insure the goal is met. That implies that you judge their usefulness not on their own but on how well they help meet that goal. He's aiming at those things as goals in themselves. ISO 9000 falls into the same trap: it concerns how well you followed a process and not how the final results turned out. This is useful if someone at the top has their eye constantly on the final result and is willing to boot the process out regardless of how thoroughly it complies with ISO 9000 if the end results aren't meeting spec, but all too often the process becomes the goal and a shield against actually being judged on the end results.
I think what's missing is an entire generation of programmers. Those of us who got their start up through about the mid-80s (on the original PC, XT and AT) knew the technical ins and outs of both our own code and the OS. The current generation grew up with development environments and application frameworks divorcing them almost completely from how the system really works. It's not that they don't know what's going on "under the hood", it's more that they don't know there is an "under the hood" in the first place.
Given that, it doesn't suprise me that the current crop is suprised by what I consider standard virus behavior: stealthing, polymorphism, encryption and the like. It still amazes me that people, for example, trust AV software which depends on services from an OS which is known to be controlled by the virus we're trying to detect. Or that a virus trying to disable AV software is considered unusual enough to be worth noting (I assume any virus worth the name is going to do something to try to prevent AV software from seeing it).
Again, you almost get the point but not quite. Before you get anywhere near the idea of image loading and "is this an image or not", you have to allow a remote page to directly reference local content. As soon as you allow that at all, even in the slightest, you open up a nasty security hole. It doesn't matter how many restrictions you slap on after that, you've still got that hole there that people can slip through. The only way to secure it is to imagine every possible bit of malicious code someone could theoretically create and protect against it, and experience shows that we just can't think up all the cases that actually exist. So, if we open that local-access hole even a little bit, we open a channel to bypass all the security mechanisms completely. We don't know what the channel is or where yet, all we know is there's one there we don't know about and the bad guys will find it.
What it boils down to is this: you want behavior out of Mozilla that'll benefit you. Experience, however, is that that behavior exposes end users to a lot of danger and doesn't, in general web browsing, offer a lot of benefit to the users. Your reward offer shows where you aren't quite recognizing the situation: the Mozilla team won't accept behavior unless you can show it's got enough benefits for the general web-surfing population to outweigh the security risks, and if you could you probably wouldn't need to offer a reward because someone else would almost certainly consider it worth doing just so they could have the benefit.
Loading a local image isn't the problem. The problem is that if you allow a hole through the block to load a local image, someone malicious can finagle it so that they can access any local resource in a dangerous way by constructing special "image" references that point to non-image data (eg. constructing an image tag that points to "file:///nasty.vbs"). Ditto if you allow local hrefs in A tags.
As I said, and as is pointed out repeated in the commentary on the bug you referenced, the problem isn't what you're asking, it's all the other worms in the can that you want opened. Once you allow remote pages to refer to local resources directly (a prerequisite for all the things you're asking for), you leave yourself wide open because you simply can't imagine and anticipate every combination of malicious circumstances someone will arrange. IE tried allowing what you want, and no matter how often they patch it someone almost immediately finds Yet Another Zone Escalation Exploit.
I find the situation highly annoying, but I find having my machine invaded by the latest spam-spewing password-stealing trojan software considerably worse.
Slashdot Mirror
Pain from a statistics-collection point of view. I can tell when cookies are completely rejected, I can't tell that they're being forced to session-only.
Exactly. It's a major pain, and frankly I'd prefer complete rejection of cookies (which is at least detectable).
Cookies and timestamps. Basic stuff, really, you should be able to figure out what's going on just from that hint.
Yes, Apple's information is Apple's property and should stay on their campus. However, it's Apple's responsibility to maintain confidentiality. Contrary to what your letter states, Nick Ciarelli hasn't signed any non-disclosure agreement with Apple. He's under no legal obligation to maintain confidentiality of their information if he obtains it lawfully. It's entirely up to them to keep it from reaching him, eg. by enforcing it's own NDAs so that people with the information don't give it to Nick in violation of the NDA. If Apple can't or doesn't do that, that's not Nick's problem. Yes, it'll hurt Apple. Again, that's not Nick's problem. Harsh, but true.
The only opening Apple has is if they can show that a) the information came to Nick from someone under NDA or otherwise obligated to maintain confidentiality, and b) Nick knew when he received the information (he can't be told afterwards, he has to know at the time) that that specific source is obligated to keep confidential that specific information. And being able to assume all Apple employees are under NDA isn't enough, assumption isn't knowledge (I got that hammered into me by Legal regarding the other side of that coin).
IANAL, but IIRC he's only under any obligation not to publish Apple's trade secrets if he obtained them while under some form of agreement with Apple to keep them confidential, or if he obtained them from someone who he at the time was or should have been aware was under such a confidentiality obligation. Note that Apple telling him the information is confidential and secret doesn't constitute his agreeing to keep it confidential, so legally Apple's warnings have only limited effect (basically they oblige him to check carefully if he receives that information from someone he knows has connections to Apple after he received the warnings). Apple's going to have to show that the person who supplied the information to Nick was under a confidentiality agreement (should be trivial) and that Nick knew this at the time he received the information (not so trivial).
That's one of the gotchas to NDAs: people who didn't sign them aren't bound by them.
When you make statements in public with my name attached to them when that name isn't also your own, you are presenting yourself as me. This is especially the case here, where the party mis-using the name knew it belonged to someone else and knew exactly who it belonged to. The two statements I made are very directly related.
He crossed the line when he used another person's name. You using a pseudonym is fine. You using my name as a psuedonym, effectively representing to other people that you are me, stands on the wrong side of the line.
This one should be a slam-dunk for Fitch. Whether the cartoon is protected free speech or not should be irrelevant. The right to free speech doesn't include the right to attribute your speech to someone else without permission.
Won't work. The shuttle doesn't have an emergency vehicle, and unless you pare payload to the absolute minimum it doesn't have enough delta-v to boost up to the orbit of the ISS and rendevous. If they found something wrong, there's four choices: fix it on the spot out of on-board supplies, have a rescue ship sent up, re-enter and pray, or sit there until the air runs out. #2 usually isn't possible, there's nothing that can make the launch window, #3 isn't real attractive and #4 downright sucks.
What we need is a low-orbit supply depot where the shuttle can pick up fuel, O2, scrubber filters and the like if it needs to.
The GPL has been the subject of legal battles. So far, every company that's been faced with copyright violation charges stemming from including GPL'd code in their products while not complying with the terms of the GPL has, after having their lawyers review the GPL, elected to comply with it's terms rather than risk going to court. Even companies like Cisco who certainly have good lawyers and enough money for that not to be an issue. If it were that easy to rip the GPL to shreds, wouldn't someone have decided they had a good enough chance of winning to take on the copyright holder?
You're forgetting RMS's comment: "It's free as in speech, not free as in beer.". You're talking about free-as-in-beer software, which doesn't have to be open-souce at all. Closed-source free software has all the problems you describe. I tend to call it no-payment-required software.
The distinction between free-as-in-speech software and open-source software is, IMHO, an important one, though. Open-source software is satisfied with the source as-in being available. Free software aims to make sure the source stays free. You can see the difference in how the BSD license affects software vs. the GPL. If you write software and release it under the BSD license, I can go and take that software, modify it, build a product around it, rake in the profits from that product and neither pay you a penny for it nor show anyone any of the modifications I've made to it. I can even release it under a non-BSD license that precludes access to the source code and you even as the author of the code can't touch me for it. This would make your code open-source but not free (because I can come along and make it non-open-source). The GPL, OTOH, goes a little further by insuring the code stays open-source. If I want to build my product around someone else's GPL'd code, I've got to keep the GPL'd code under the GPL. Note that it's not saying I have to keep my code under the GPL, but if I can't seperate my code from the original GPL'd code in the final product as delivered (the standard is basically that someone can, in the product as delivered, replace the GPL'd portion without breaking the product (unless the replacement code itself is broken)) then I'm either going to have to comply with the GPL or I'm going to have to go back to you and negotiate a non-GPL license for your code.
Both sorts of license have uses. So does the LGPL, which is a variation suitable for libraries or loadable modules. I think there's a use for all three types of licenses, and which one is best depends on what the author of the code wants done with it.
Exactly. But it depends on the corporations being able to tie that imported labor down to their initial low wages. So we close the loophole, and then make the corporations eat their own paens to "competition" by making them compete for labor. They've told us that if US labor can't offer a better deal than foreign labor then US labor should suffer, they should have no problem with the idea that if they can't offer their foreign labor a better deal than their competitor then they should suffer. :)
Yes, I know they won't go for that. That's why we smile sweetly and repeat their own lines back at them.
I don't care for the H1B program, but I can't come up with a rational reason for denying someone from another country work that doesn't boil down to "I don't want my job at risk.". I don' like that as a reason either. So rather than eliminate the H1B/L1 program, change it so those visas belong to the worker and not the company bringing them in. That way, when an H1B worker gets a better offer from the competition, he can walk under no more restriction than any US worker and take his H1B along with him. That should put a nice upward pressure on H1B wages, while not doing anything the companies that want low-paid H1B workers can complain about (or at least that can't be rebutted by the company's own arguments about competition).
I qualify under the settlement, but it wasn't satisfaction with Microsoft or simple indifference that made me not file for it. It's the settlement itself. What do I get from it? A paltry $5 off Word, for example, or $30 off the complete Office suite. That isn't even enough to offset the sales tax on those products. And I have to buy products from the same company being punished. They've abused their monopoly position, not to mention been the root cause of most of the virus headaches I have to deal with, and I should add to their profits? Why? If the settlement had involved MS having to give me a discount on competitor's products, I might've gone for it.
That last wouldn't be an issue for software you wrote yourself. The patent-protection clause could only remove any right to use the software granted by the GPL, and your right to use software you wrote yourself doesn't stem from the GPL.
No, the GPL is a copyright license. You don't need to accept the GPL to merely use the software (the GPL even says this explicitly if there's any question about the point). This is in stark contrast to an EULA. But, to make and distribute additional copies of the software you do need to accept the GPL. It's not the GPL that demands that, though, it's copyright law. Under copyright law, only the creator of a work or those he's granted a license to may make and distribute copies of the work. This is why the GPL's a license and not a contract: it's not a bilateral agreement, it's a unilateral grant of rights you normally wouldn't have. It's also not an unconditional and unlimited grant of those rights, but that doesn't make it not a license.
The above, BTW, is also why nobody will ever be sued for violation of the GPL. The suit (and possible criminal charges) will be for copyright infringement instead, since that's what you're doing if you distribute copies of a GPL'd work without accepting and abiding by the GPL.
Before, it was a slam dunk: if I couldn't read the EULA until after I'd bought the software, there wasn't any way the software company could claim I'd agreed to it by buying the software. Now, they can make that argument.
What we need really is a clear-cut decision that, unless I actually sign some other agreement before I fork over my money and walk out of the store with the software package, what occurred was a sale under the terms of the UCC and my rights and responsibilities as a buyer are those laid down by the UCC. That I am the owner free and clear of that copy of the software with the right to use it with no more need for a license than I need a license from the author of a book to read my copy of it, and that that EULA is an additional and after-the-fact contract that I'm free to refuse to agree to without affecting the sale that's already occurred.
There is. Firstly, Unix has been in use in university environments for nigh on a quarter-century now. Cracking systems has been a hobby for college comp-sci majors for as long as computer systems have been available to crack, and the operating-system-design classes in that major are often based around dissecting the actual source code of the very systems they're trying to crack which means they've far more detailed knowledge of Unix systems than of Windows. And yet, despite that, Unix remains relatively secure in that environment. Why should we assume this would change?
Secondly, track record. Apache on Linux is probably the most popular platform for Web servers based on NetCraft and other surveys. Apache on Unix of some sort definitely is not only more popular than any other option, it's more popular than all other options combined. Unix is the dominant OS there (and the traits that make Linux secure are simply the normal traits of any other Unix variant). Yet while we see regular compromises of Web servers, compromises of Apache on Unix are relatively rare. If it's not compromised often in an environment where it is the dominant platform, why would it be compromised often in another environment if it were the dominant platform?
I guess my question would be, why worry about passwords? Today, if I wanted to gain access to someone's account, I wouldn't bother trying to crack their password. I can get in faster through social engineering (get them to just tell me what their current password is) or, if I don't want to risk direct contact, infecting their computer with malware that lets them enter the password and then uses their current credentials. Note that the latter is even more effective in environments that have gone heavily to Active Directory and single-sign-on, since once I get my program running under the logged-in user account the system itself will handle most of the authentication for me by design.
If that were the case, then in 25 years of programming I'd've had a hard time not working on at least one project intended for resale. Instead, I find that all the software I've worked on was bespoke work for internal use. More, when I tally up the resumes I've evaluated over the years, few candidates had any intended-for-resale software projects listed and even for those few it made up the minority of their experience. Either I've had a ridiculously long run of 20s on the random-encounter dice or you haven't worked as a professional software developer and are getting your impressions from what you see at CompUSA.
For a software vendor, there's no advantage in opening the source code. If you aren't a vendor, though, there's several advantages:
- For companies writing in-house software, development cost is important and resale value irrelevant. Open source allows you to grab software that does almost what you want and add the features you need, concentrating your development efforts (and costs) only on the bits that aren't already there. This also applies to pure customers, if there's an open-source package that does almost what they want except for one or two features they can hire someone to add just those features, with closed code you either live with the missing bits or go through an expensive switch.
- For pure customers, they aren't at the mercy of the vendor for bugfixes. If a bug is critical to one customer but relatively unimportant to the vendor, with open source the customer can hire someone to fix the bug for them. It's the customer's decision which is cheaper: hiring it done or waiting for the vendor's update. With closed code, the customer has no choice but to wait until the vendor decides to fix the bug (which may be never for certain bugs).
- For everyone, you're no longer at the mercy of the vendor's interests and product road-map. If what's good for you as a customer diverges from what's in the vendor's interest, with closed code customers have to either live with it or abandon the product entirely (an expensive proposition). With open source if the vendor/owner's idea of where the software should go diverge too far from that of a group of customers, the customers have the option of forking the code and investing (through employees or by contracting the work out) in developing the product along their path instead of the vendor's. This happened with the GCC compiler, nearly happened once with the X Consortium's X11 product and is happening currently with XFree86.
Remember, 95% of software isn't written for resale, so judging benefit purely from the POV of a software vendor misses an awful lot.What happens if he gets hit by a bus?
Then one of the other major kernel developers will take it over. This has in fact already happened (control being turned over, not Linus getting hit by a bus).
Heck what happens today when large factions of kernel developers disagree with him? ( Kernel debugger )
If a large fraction of the kernel developers have a fundamental disagreement with Linus, then they'll fork the kernel and maintain their own. This in fact happens fairly regularly, as with the -mm kernels in 2.4 and the -ac kernels in 2.2. If the majority of the Linux community finds this new branch of the kernel more useful than Linus' branch, Linus will find his branch becoming marginalized. We've already seen this in GCC when EGCS forked off in response to frustration over lack of support for newer CPUs in GCC itself.
I suspect that this hasn't happened to the kernel because, to take the kernel debugger as an example, while lots of people may disagree with Linus none of them have an argument good enough to conclusively trump his arguments. The kernel debugger is a good one for me because while I tend to agree a kernel debugger would be a really useful thing, I also agree with Linus that it'd make it awful tempting for newer developers or those not intimately familiar with the subsystem they're bug-hunting in to find and fix only the immediate symptom and not do the rooting around in the code which eventually leads to an understanding of the underlying cause of the problem.
Hist first item shows a fundamental problem right off. I've dealt with projects that were driven directly off the business requirements. The problem is that they were driven directly off the business requirements. The next project was for a slightly different set of business requirements, and because they were slightly different none of the work on the first project could readily be transferred over. By contrast in other projects I managed to divorce the business requirements from the actual work, and I could step back and instead of addressing the business requirements create tools and facilities that I could then use to address the business requirements. The next project in that line, with it's slightly different requirements, required only some relatively easy extensions to the existing work and we were in business. It took a fraction of the time. Most of the problems with business-process-driven software design and development, IMHO, is that it's too focused on the end result to be good at front-loading the solving of meta-problems that can speed up later work because solving the meta-problem doesn't provide any immediate advantages for the problem immediately to hand. In mathematical terms, it looks for a local maxima at the expense of an even better global maxima that's on the other side of a minima.
His second item about auditability also aims at the wrong point. When, for example, designing the control software for an ABS system, the goal is to have it work correctly. All else, auditability, certifications and such, are supposed to be means to insure the goal is met. That implies that you judge their usefulness not on their own but on how well they help meet that goal. He's aiming at those things as goals in themselves. ISO 9000 falls into the same trap: it concerns how well you followed a process and not how the final results turned out. This is useful if someone at the top has their eye constantly on the final result and is willing to boot the process out regardless of how thoroughly it complies with ISO 9000 if the end results aren't meeting spec, but all too often the process becomes the goal and a shield against actually being judged on the end results.
I think what's missing is an entire generation of programmers. Those of us who got their start up through about the mid-80s (on the original PC, XT and AT) knew the technical ins and outs of both our own code and the OS. The current generation grew up with development environments and application frameworks divorcing them almost completely from how the system really works. It's not that they don't know what's going on "under the hood", it's more that they don't know there is an "under the hood" in the first place.
Given that, it doesn't suprise me that the current crop is suprised by what I consider standard virus behavior: stealthing, polymorphism, encryption and the like. It still amazes me that people, for example, trust AV software which depends on services from an OS which is known to be controlled by the virus we're trying to detect. Or that a virus trying to disable AV software is considered unusual enough to be worth noting (I assume any virus worth the name is going to do something to try to prevent AV software from seeing it).
Again, you almost get the point but not quite. Before you get anywhere near the idea of image loading and "is this an image or not", you have to allow a remote page to directly reference local content. As soon as you allow that at all, even in the slightest, you open up a nasty security hole. It doesn't matter how many restrictions you slap on after that, you've still got that hole there that people can slip through. The only way to secure it is to imagine every possible bit of malicious code someone could theoretically create and protect against it, and experience shows that we just can't think up all the cases that actually exist. So, if we open that local-access hole even a little bit, we open a channel to bypass all the security mechanisms completely. We don't know what the channel is or where yet, all we know is there's one there we don't know about and the bad guys will find it.
What it boils down to is this: you want behavior out of Mozilla that'll benefit you. Experience, however, is that that behavior exposes end users to a lot of danger and doesn't, in general web browsing, offer a lot of benefit to the users. Your reward offer shows where you aren't quite recognizing the situation: the Mozilla team won't accept behavior unless you can show it's got enough benefits for the general web-surfing population to outweigh the security risks, and if you could you probably wouldn't need to offer a reward because someone else would almost certainly consider it worth doing just so they could have the benefit.
Loading a local image isn't the problem. The problem is that if you allow a hole through the block to load a local image, someone malicious can finagle it so that they can access any local resource in a dangerous way by constructing special "image" references that point to non-image data (eg. constructing an image tag that points to "file:///nasty.vbs"). Ditto if you allow local hrefs in A tags.
As I said, and as is pointed out repeated in the commentary on the bug you referenced, the problem isn't what you're asking, it's all the other worms in the can that you want opened. Once you allow remote pages to refer to local resources directly (a prerequisite for all the things you're asking for), you leave yourself wide open because you simply can't imagine and anticipate every combination of malicious circumstances someone will arrange. IE tried allowing what you want, and no matter how often they patch it someone almost immediately finds Yet Another Zone Escalation Exploit.
I find the situation highly annoying, but I find having my machine invaded by the latest spam-spewing password-stealing trojan software considerably worse.