For instance, you can't use a carrot to hammer in a nail.
Hm, maybe if I freeze it, or plastinate it. That sounds like a good slashdot story in the making...
The point is that the farmer does not impose additional draconian legal restriction on what I can do with the product once I've bought it, whereas software companies do.
"...and if I'm not smart enough or otherwise unable to do so, tough luck, loser. Find another profession."
Well I'm sorry, but that is the way free markets work. I didn't make it up.
When that commoditization comes, will we be asking ourselves "What have we done?"
Commoditization will come, whether you want it or not. Open source is almost orthogonal. Microsoft have been happily turning PCs, servers, operating systems into commodities barely a trace of openness. And not merely commodities, but a non-competitive commoditized wasteground. A glut of Indian and Chinese programmers will have a similar effect.
Given open commodities or monopolistic commodities I would choose the former, both as a consumer and as a services producer.
They granted me a licence to use and redistribute the code. The licence may only be terminated on certain specific conditions. The licensor cannot terminate the licence at will. Therefore, I continue to have a licence. I don't know where you get this "withdrawing" idea from.
Prior to Ford's mass production, cars were expensive works by experts in their trade. Now they're commodities. That's great for the consumer but perhaps not so great for the practicioners.
You need to bear in mind that the practitioners of programming are consumers of vehicles, and vice versa. I can buy a car now which is far cheaper and better than those of a hundred years ago. That is a good thing.
Are you seriously saying that it was mean or destructive for Ford to make cheaper cars? It worked out OK for him. Did you seriously expect him to stop, just because it might give some competitors some trouble?
Are you that anxious for your skills to become a cheap commodity?
I am anxious to keep developing skills that are not commoditized.
In any case, it is futile to try to prevent things being commoditized. "There is no security, only opportunity."
Look at SCO: once they could sell PC Unix for hundreds of dollars and it was a good deal, but they kept selling the same old crap for over a decade. One day they woke up, and all their customers had discovered they could download something better for free. Now they're whining about it, but soon they will be dead.
Although there are probably not many human welders producing cars anymore there are plenty of skilled workers doing design, testing, marketing, etc. It's not like mass production has caused the car industry to die off, or to employ zero people. I'd be pretty sure there are more people working in it than when Ford started.
I won't pretend capitalist destructive innovation is always for the best, but it is almost inevitable.
They could just withdraw their code, and while anyone with a copy could then sue them for monetary damages, they still wouldn't be able to legally use the code.
What are you smoking? They can take down their own FTP server, but they can't stop other people redistributing it.
It reads more to me like "Stop pissing in your own water dish." He does have a valid concern; once the core of an application is developed for free, said application and its components can be used by less skilled programmers to put together business solutions.
By this logic, you should always obfuscate your code as much as you possibly can, so that there is no chance of less skilled programmers taking over...
Manufacturing Suzukis devalues the practice of making Mercedes. Therefore, Suzuki should stop making cars. Why are they being so mean to Mercedes? Don't you think Mercedes are fine cars?
The whole point of free markets is that things become cheaper as production becomes more efficient.
The farmer doesn't tell you how to prepare the food just like a software company doesn't tell you to only use their accounting software for certain businesses.
Have a look at a software licence some time, hey? You will note that a whole lot of uses of the software are prohibited. For example
- you may use it on only one machine
- you may not use it for commercial purposes
- you may not resell it
- you may only use it on a machine with less than 2 CPUs
- you must register it
- you must use it with a licenced copy of Windows
- you must let us audit your usage
- you may not disassemble or modify it
Carrots are a much more free market, at least in this regard. You buy the carrot, and then you can do what you want: eat it, sell it, mince it, throw it, plant it, ram it up your yoda doll's ass...
if I could "copy" a carrot a million times.
Just imagine if you could put a carrot in the ground and grow more carrots... what a bizarre fantasy. It'll never happen.
If we extend your argument to lets say farming, a farmer that charges for the food he produces is violating the rights of anyone who doesn't want to pay him for his labour. It cost him time and money to produce that food and he likely has a family to support. Why shouldn't he be able to charge a resonable price for his product.
Of course he can charge as much as he likes. And I can charge you money for open source software.
Where we start to get a problem is when the farmer makes his customers agree that they can't on-sell the products to somebody else, or that they can't plant the apple seeds and grow their own apple tree. Indeed, the farmer wants laws to allow him to raid people's homes to search for illegal apple trees, and to make it illegal to describe how to raise a tree.
Now prohibiting those things would probably make apple farmers richer, but that does not mean allowing them is violating his rights.
One way to do this would be for more systems to use the Distributed Management Task Force Common Information Model to report their status and do configuration. It wouldn't be necessary to change the native configuration file of programs that already have one well-established; you could just add it as a second mechanism.
It's a bit complex but I think it is sufficiently powerful to allow different clients to control all of a system without needing to know the details of how particular services work.
Keeping tight control to prevent Microsoft forks... I'm sure that was Sun's thinking, but it's pretty stupid.
It is nothing for Microsoft to assign 50 people to write a JVM and compiler. Even if the source were open, they might do it in a cleanroom just to be safe in the future. Having source to the JVM is irrelevant to their ability to extend and embrace it.
Keeping the source closed hurts everyone else and has zero effect on Microsoft.
Netscape and Ximian managed to get acquired by large companies, making some amount of money for their owners and continuing jobs for their employees. It's not exactly a triumph, but it's better than a poke in the eye.
Most businesses fail. Failure is the default outcome for technology companies. Sun might do this and still fail, but it probably improves their chances.
If they don't do it,.NET and open source will clobber them from opposite directions in about two-five years. You cannot beat Microsoft at locking developers in to a proprietary platform, so the only way to compete is to have an open platform.
I think I give Sun about 40% chance of being smart enough to do it.
Better yet, use GPG signatures. MD5sums won't help much if the intruder gets onto the main download site. GPG requires them to get onto the developer's workstation, which is probably harder.
Why does anyone bother using MD5 when GPG is so easy?
I can speak from personal experience on this, because we were looking into this in depth just last week. I reckon it will be a long time before anyone adopts the kid called "Shithead".
Fair enough. The main criticism against ASN.1 is really complexity, rather than tight-arsedness. The same goes for DCE-RPC. Barely any programs need a dozen different variations of arrays: a simple lispish list ought to be enough.
I'm not sure there is any perfect or universal solution. If I found a problem and I thought it was not otherwise known, I would probably give the vendor a week or so to fix it. I would like somebody to do the same if they found a problem in my code. Your priorities may differ.
If the vendor gets reports from 600 people and still does not get a patch out in the next 24 hours... sheesh.
I think the difference may be whether you trust the vendor to respond expeditiously or not. Most open source projects, most of the time, will get a patch out within a couple of days. Some commercial vendors are like that too. In that case, I think it may be worth telling them, and trusting that they have the information on whether it's already known or exploitable.
If you think the vendor are going to sit on the patch for six months, it's probably better to just announce it. This is hardly the first time Microsoft have done this.
If it's been around for years, then leaving it around but secret for say two more days is a relatively small cost. The additional risk of having a little-known vuln around is pretty small.
On the other hand, if you do release the details immediately, you can nearly guarantee that there will be widespread attacks straight away.
How do you know this vulnerability is not being exploited?
No, you can't know for sure. However, attacks against unknown vulnerabilities are sometimes discovered by network intrusion detection, or forensics on cracked machines. If we haven't seen any of those, there is some chance that either no one else knows it, or it is at least confined to a small number of crackers. If its known to blackhats but not to many of them then the odds of any particular machine being hit in the window are pretty small.
Disclosing a vulnerability ONLY to the vendor only makes sense when there is absolutely no way that software could be shut down and/or replaced.
I don't think that is quite the only case. Disclosures often do lead to attack tools, or at least more widespread use of them.
If the vuln is not being exploited then giving the vendor a few days or a week to make a release is probably OK. When you do make the announcement, people can apply the patch without needing to panic. The overall damage is probably less.
Beyond say 10 days there is no reason to imagine that it's still secret, and so it's safer to let people know.
Actually, feel free to tell me AND my locksmith (he installed the lock so he could already get in anyway)
You let your locksmith keep a copy of your keys? With good security, knowing what was installed doesn't let you get in.
but you could please not tell the whole city?
If the affected population is "Windows users" then there is barely any difference between telling affected users and telling everyone, now is there? Oooh, I guess those phearsome Macintosh hackers won't know about the vulnerability so now we're safe.
(Not that I completely agree with the grandparent.)
Beats it for what? Latency, which is the main factor in good interactive feel? Possibly, but that is exactly what I was not saying, I was talking about bandwidth.
One of the good parts of Eric Rayrnond's new book The Art of Unix Programming is the discussion of protocol design, and in particular the foolishness of trying to squeeze out every single bit.
In particular, he points out that it's often better to just use a simple encoding, and then run a compressor like LZO or GZIP over the whole thing. This lets you design a simple protocol, and you get the benefit of compression over the whole thing rather than just the metadata. Complexity, of course, is the enemy of security. It is both simpler and gives better compression; and people with more network than CPU can turn compression off or down.
Keith Packard has some similar papers looking at X11, where he concludes that clever tricks like Low Bandwidth X really don't help all that much compared to just using SSH compression.
Latency is a different and harder problem, but one that's often better solved in the high-level design than by bit-banging.
Slashdot Mirror
For instance, you can't use a carrot to hammer in a nail.
Hm, maybe if I freeze it, or plastinate it. That sounds like a good slashdot story in the making...
The point is that the farmer does not impose additional draconian legal restriction on what I can do with the product once I've bought it, whereas software companies do.
"...and if I'm not smart enough or otherwise unable to do so, tough luck, loser. Find another profession."
Well I'm sorry, but that is the way free markets work. I didn't make it up.
When that commoditization comes, will we be asking ourselves "What have we done?"
Commoditization will come, whether you want it or not. Open source is almost orthogonal. Microsoft have been happily turning PCs, servers, operating systems into commodities barely a trace of openness. And not merely commodities, but a non-competitive commoditized wasteground. A glut of Indian and Chinese programmers will have a similar effect.
Given open commodities or monopolistic commodities I would choose the former, both as a consumer and as a services producer.
They could withdraw their code
They granted me a licence to use and redistribute the code. The licence may only be terminated on certain specific conditions. The licensor cannot terminate the licence at will. Therefore, I continue to have a licence. I don't know where you get this "withdrawing" idea from.
Prior to Ford's mass production, cars were expensive works by experts in their trade. Now they're commodities. That's great for the consumer but perhaps not so great for the practicioners.
You need to bear in mind that the practitioners of programming are consumers of vehicles, and vice versa. I can buy a car now which is far cheaper and better than those of a hundred years ago. That is a good thing.
Are you seriously saying that it was mean or destructive for Ford to make cheaper cars? It worked out OK for him. Did you seriously expect him to stop, just because it might give some competitors some trouble?
Are you that anxious for your skills to become a cheap commodity?
I am anxious to keep developing skills that are not commoditized.
In any case, it is futile to try to prevent things being commoditized. "There is no security, only opportunity."
Look at SCO: once they could sell PC Unix for hundreds of dollars and it was a good deal, but they kept selling the same old crap for over a decade. One day they woke up, and all their customers had discovered they could download something better for free. Now they're whining about it, but soon they will be dead.
Although there are probably not many human welders producing cars anymore there are plenty of skilled workers doing design, testing, marketing, etc. It's not like mass production has caused the car industry to die off, or to employ zero people. I'd be pretty sure there are more people working in it than when Ford started.
I won't pretend capitalist destructive innovation is always for the best, but it is almost inevitable.
They could just withdraw their code, and while anyone with a copy could then sue them for monetary damages, they still wouldn't be able to legally use the code.
What are you smoking? They can take down their own FTP server, but they can't stop other people redistributing it.
It reads more to me like "Stop pissing in your own water dish." He does have a valid concern; once the core of an application is developed for free, said application and its components can be used by less skilled programmers to put together business solutions.
By this logic, you should always obfuscate your code as much as you possibly can, so that there is no chance of less skilled programmers taking over...
Ha ha.
Manufacturing Suzukis devalues the practice of making Mercedes. Therefore, Suzuki should stop making cars. Why are they being so mean to Mercedes? Don't you think Mercedes are fine cars?
The whole point of free markets is that things become cheaper as production becomes more efficient.
The farmer doesn't tell you how to prepare the food just like a software company doesn't tell you to only use their accounting software for certain businesses.
Have a look at a software licence some time, hey? You will note that a whole lot of uses of the software are prohibited. For example
- you may use it on only one machine
- you may not use it for commercial purposes
- you may not resell it
- you may only use it on a machine with less than 2 CPUs
- you must register it
- you must use it with a licenced copy of Windows
- you must let us audit your usage
- you may not disassemble or modify it
Carrots are a much more free market, at least in this regard. You buy the carrot, and then you can do what you want: eat it, sell it, mince it, throw it, plant it, ram it up your yoda doll's ass...
if I could "copy" a carrot a million times.
Just imagine if you could put a carrot in the ground and grow more carrots... what a bizarre fantasy. It'll never happen.
If we extend your argument to lets say farming, a farmer that charges for the food he produces is violating the rights of anyone who doesn't want to pay him for his labour. It cost him time and money to produce that food and he likely has a family to support. Why shouldn't he be able to charge a resonable price for his product.
Of course he can charge as much as he likes. And I can charge you money for open source software.
Where we start to get a problem is when the farmer makes his customers agree that they can't on-sell the products to somebody else, or that they can't plant the apple seeds and grow their own apple tree. Indeed, the farmer wants laws to allow him to raid people's homes to search for illegal apple trees, and to make it illegal to describe how to raise a tree.
Now prohibiting those things would probably make apple farmers richer, but that does not mean allowing them is violating his rights.
One way to do this would be for more systems to use the Distributed Management Task Force Common Information Model to report their status and do configuration. It wouldn't be necessary to change the native configuration file of programs that already have one well-established; you could just add it as a second mechanism.
It's a bit complex but I think it is sufficiently powerful to allow different clients to control all of a system without needing to know the details of how particular services work.
..or should I call you monkey boy?
Keeping tight control to prevent Microsoft forks... I'm sure that was Sun's thinking, but it's pretty stupid.
It is nothing for Microsoft to assign 50 people to write a JVM and compiler. Even if the source were open, they might do it in a cleanroom just to be safe in the future. Having source to the JVM is irrelevant to their ability to extend and embrace it.
Keeping the source closed hurts everyone else and has zero effect on Microsoft.
Netscape and Ximian managed to get acquired by large companies, making some amount of money for their owners and continuing jobs for their employees. It's not exactly a triumph, but it's better than a poke in the eye.
.NET and open source will clobber them from opposite directions in about two-five years. You cannot beat Microsoft at locking developers in to a proprietary platform, so the only way to compete is to have an open platform.
Most businesses fail. Failure is the default outcome for technology companies. Sun might do this and still fail, but it probably improves their chances.
If they don't do it,
I think I give Sun about 40% chance of being smart enough to do it.
Better yet, use GPG signatures. MD5sums won't help much if the intruder gets onto the main download site. GPG requires them to get onto the developer's workstation, which is probably harder.
Why does anyone bother using MD5 when GPG is so easy?
I can speak from personal experience on this, because we were looking into this in depth just last week. I reckon it will be a long time before anyone adopts the kid called "Shithead".
Fair enough. The main criticism against ASN.1 is really complexity, rather than tight-arsedness. The same goes for DCE-RPC. Barely any programs need a dozen different variations of arrays: a simple lispish list ought to be enough.
On further thought...
I'm not sure there is any perfect or universal solution. If I found a problem and I thought it was not otherwise known, I would probably give the vendor a week or so to fix it. I would like somebody to do the same if they found a problem in my code. Your priorities may differ.
If the vendor gets reports from 600 people and still does not get a patch out in the next 24 hours... sheesh.
I think the difference may be whether you trust the vendor to respond expeditiously or not. Most open source projects, most of the time, will get a patch out within a couple of days. Some commercial vendors are like that too. In that case, I think it may be worth telling them, and trusting that they have the information on whether it's already known or exploitable.
If you think the vendor are going to sit on the patch for six months, it's probably better to just announce it. This is hardly the first time Microsoft have done this.
If it's been around for years, then leaving it around but secret for say two more days is a relatively small cost. The additional risk of having a little-known vuln around is pretty small.
On the other hand, if you do release the details immediately, you can nearly guarantee that there will be widespread attacks straight away.
How do you know this vulnerability is not being exploited?
No, you can't know for sure. However, attacks against unknown vulnerabilities are sometimes discovered by network intrusion detection, or forensics on cracked machines. If we haven't seen any of those, there is some chance that either no one else knows it, or it is at least confined to a small number of crackers. If its known to blackhats but not to many of them then the odds of any particular machine being hit in the window are pretty small.
Disclosing a vulnerability ONLY to the vendor only makes sense when there is absolutely no way that software could be shut down and/or replaced.
I don't think that is quite the only case. Disclosures often do lead to attack tools, or at least more widespread use of them.
If the vuln is not being exploited then giving the vendor a few days or a week to make a release is probably OK. When you do make the announcement, people can apply the patch without needing to panic. The overall damage is probably less.
Beyond say 10 days there is no reason to imagine that it's still secret, and so it's safer to let people know.
Actually, feel free to tell me AND my locksmith (he installed the lock so he could already get in anyway)
You let your locksmith keep a copy of your keys? With good security, knowing what was installed doesn't let you get in.
but you could please not tell the whole city?
If the affected population is "Windows users" then there is barely any difference between telling affected users and telling everyone, now is there? Oooh, I guess those phearsome Macintosh hackers won't know about the vulnerability so now we're safe.
(Not that I completely agree with the grandparent.)
Saeed al-Sahaf (665390) wrote:
By the way, recall that Linus himself predicted the corporate desktop is still 10 years off.
And what did Saeed al-Sahaf predict?
I think the paper I was talking about was looking at LBX, which is a different program.
Beats it for what? Latency, which is the main factor in good interactive feel? Possibly, but that is exactly what I was not saying, I was talking about bandwidth.
Anyhow, I suggest you read the fine papers.
(Wow, great post.)
One of the good parts of Eric Rayrnond's new book The Art of Unix Programming is the discussion of protocol design, and in particular the foolishness of trying to squeeze out every single bit.
In particular, he points out that it's often better to just use a simple encoding, and then run a compressor like LZO or GZIP over the whole thing. This lets you design a simple protocol, and you get the benefit of compression over the whole thing rather than just the metadata. Complexity, of course, is the enemy of security. It is both simpler and gives better compression; and people with more network than CPU can turn compression off or down.
Keith Packard has some similar papers looking at X11, where he concludes that clever tricks like Low Bandwidth X really don't help all that much compared to just using SSH compression.
Latency is a different and harder problem, but one that's often better solved in the high-level design than by bit-banging.