You're right, SSL isn't a chiper. It's a set of chipers and related algorithms inteaded to provide secure data streams. If we're going to be picky SSL is not a set of tools either. OpenSSL is a set of tools; SSL itself defines what those tools are expected to do.
As for stream vs. block, you're right SSL supports block chipers. And they're even commonly used in things like HTTPS. But they all use CBC (Cipher Block Chaining). So while technically not stream chipers, they have the same limitation I was noting, one that makes them inappopriate for SIP -- you still need to get the entire stream in order to decrpyt them.
And other people agree with my understanding of OpenVPN, and the explaination on their front page -- SSL for auth, ESP for the data stream: Note that OpenVPN doesn't transport its data stream over SSL. They use IPSec ESP over UDP for that, the same as standard IPSec NAT-T does. They just use SSL over UDP for session authentication and management--in other words, as an IKE replacement, as far as I can tell. In that respect, there's really not much to differentiate it from IPSec NAT-T. http://ask.slashdot.org/comments.pl?sid=197811&cid =16209755
You're excused. But SSL still doesn't work for UDP, at least not in any way that's useful for things like SIP.
You can transmit UDP traffic through an SSL-wrapped tunnel, and you can transmit the SSL data using UDP packets, but since SSL is a stream chiper the other end still has to reassemble the enitre stream, in order before it can decrypt anything. And that in-order, no-lost-packets thing is the whole reason you decided against TCP in the first place -- you didn't want to stop the call for 0.5 seconds or more every time you dropped a single packet.
And I'm not sure that OpenVPN uses SSL for UDP traffic anyway. The front page says "OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." Which reads to me like SSL is used to setup the tunnel, but that the tunnel itself uses IPSec.
Sheesh. I'm sorry I upset you by not intuitively understanding a vague reference to a book I haven't read for 10 years.
So here's a hint in kind: when you get out of school, be on the look out for books other than the 4 they've made you read in class. As it turns out, fingers are mentioned, even counted, in many other books, films, and television shows.
I'm not saying there's nothing we can do to reduce the use of bounce messages. Certainly I agree that, when reasonable, mail hosts should reject messages in-session, rather than creating a bounce. But eliminating them altogether means eliminating the store-and-forward methodology, or accepting that mail might not be delivered and you would never know.
For example the ISP case you mention can validate the sender, once you have validated the sender the problem is solved.
No, all you've done if ensure you have someplace valid to deliver bounces, should the message generate any before it leaves you server. But unless you somehow pass that trust forward somehow you haven't done a thing for any mail host other than your own. Remote systems may still need to bounce the message, and they have no way to validate the sender.
He said "Either...or", which is exclusive. You see, in English, "xor" isn't a word, and you have to sometimes read the whole sentence to understand the meaning.
Except DynDNS doesn't have local users, so they can't verify directly that messages will be delivered.
A similar problem occurs when you submit outbound mail to your ISP -- unless it's going to someone else at the same ISP, the local SMTP server can't verify that delivery will succeed. At the ISP level it's still probably reasonable to generate bounce message, at least for local users. That way you don't have to do the final delivery right away, users can still get error messages, and you don't risk sending bounces across the Interwebs.
But it gets tricky for forwarding hosts like DynDNS. The only way to reject during the session would be something like: A) Inbound connection sends message to forwarding server B) Forwarding server leaves connection open after the DATA command C) Forwarding server forms outgoing connections to every domain specified in the envelope addresses D) Forwarding server attempts to deliver the message to all final recipients E) Forwarding server rejects original connection from (A) if any deliveries in (D) fail
And even if you overcame the technical complications of such a system, it completely dis-allows the use of mail hosts that don't have 24/7 availability. Moreover it eliminates the ability to use secondary hosts, because even if they can validate addresses (which is not trivial) they can't guarantee things like available disk space on the destination server.
Rejecting messages in-session is certainly a good idea, but it's ridiculous to think that it's possible to eliminate bounce messages just by validating local addresses before accepting a message.
That doesn't create a DoS for anyone other than your botnet, which effectively *is* you if you're using the botnet to do things on your behalf. And somehow I don't think "DoS with the scope of a single mail host" is the biggest concern of someone who's box has become part of a botnet.
I'm not suggesting you couldn't get some box other than your own desktop blocked, or that blocking by IP would be effective at stopping spam. I was just refuting the original statement that you could use IP-scoped blocking in response to mail message content as an effective DoS attack.
That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.
In order to spoof a remote IP address you'd have to basically have to share a wire someplace between the mail server and your spoofing target, or exploit some secondary flaw on a router/host along that same path. It could be done, but there are easier ways to DoS, and most of those ways are effective beyond the single-host-to-single-mailhost-for-mail-service-on ly scope that is targeted with the attack you describe.
Re: OSI? Do you mean TCP/IP? ;-)
on
Network Warrior
·
· Score: 2, Insightful
It's "relevant" in that TCP/IP is based on the ideas of the OSI model, and has a similar, layered architecture. In practice though, TCP/IP doesn't follow the OSI model very closely.
For example, in TCP/IP, there's only one layer above the transport layer, which makes OSI layers 5, 6, and 7 all the same. I suppose you could argue that layer 6 never really existed anyway, but that's neither here nor there.
Similarly while there's a technical distinction between layers 1 and 2, in common practice they are too interrelated to speak of as separable layers.
During which cable goes out too, since they're getting their feed via satellite just like you. They've got bigger dishes with better amps and better wind ratings, so they can withstand somewhat more severe weather. But if there's a general disruption to satellite communications it will affect cable as well.
Corporate person-hood. I hate when my corporation gets called up for jury duty, but I guess it's worth it for the right to vote. Now if only we could get a corporate-birth abortion ban to protect those startups.
If you wanted to discuss how giving money to politians should or shouldn't be protected speech I'm sure someone could oblige you; there are reasonable arguments to be made for both sides. But it's ridiculous to pretend that the problem is with financial entities and not people -- if we didn't let corporations give money or whatnot directly, couldn't the owners and officers of those corporations give money as individuals? Are you suggesting that by becoming an owner or officer in a corporation one should be required to give up their personal rights?
Corporations aren't people and aren't treated legally as people, except insofar as their owners are people. Various forms of financial entities are granted rights of possession and litigation in line with their purpose as financial entities, but they aren't treated as people in general. The supposed "person-hood" that financial entities have is an extension of the actual, physical person-hood that their owners have -- corporations have rights to free speech because their owners have rights to free speech, and I don't see any pratical way to change that, short of opressing the person-hood of business owners.
You could simply choose not to entrust your local mail client with the authoritive copy of your mail archive.
I agree with your preference for easy-to-parse formats -- I prefer maildir myself, as I find it easier to address individual messages programatically when they have their own files -- I'm just saying that the local storage format is not an issue if you don't put your mail client in charge of your message archive.
I'm with you on the exploding -- if you're caught in space you want to do everything possible to reduce your internal pressure.
But it's not that cold in space. There's not a lot of ambient heat, but there's not a lot of conduction or convection either -- you only lose heat as fast as you radiate. So on the timescale of "holding your breath" the temperature of space is not a significant factor. Likewise the radiation you'd absorb over 60 seconds is likely not a large factor, unless you're particularly close to the source (I don't recall the episode, so I can't comment on their depiction of distance from the star(s)).
I'm all for encryption, but it's not clear to me what an encrypted root file system would buy me. They wouldn't be able to tell what packages I had installed? I already mount root RO, so I'm sure there's nothing being written there in general operation, and I just don't see what appreciable security I'd gain by hiding the contents of that file system.
That and it sure would be handy if I could log in remotely to a mostly-booted system (using a special-purpose account) and enter the passphrase. Without that there's no way to reboot the system remotely, which is a problem at least for me.
Technically they are the only possible options, at least with more than one person involved in the organization. The only other choise is a truely independent reporter who publishes his own work, which doesn't seem terribly scalable.
And apparently you're not aware that both PBS and NPR take money from the government and other corporations, just like other media organizations. Sure they're organized as non-profits, but they still need funding for payroll and other operations, and they're just as likely to choose to give up some control of their content for the sake of keeping the organiztion afloat.
Information cannot be patented. What do your patents cover? Because mine cover the design of devices and systems, and that design is, in and of itself, nothing more than information.
Film dimensions are not patentable, as they are merely a statement of fact (information). The schematics of any device are merely statements of fact. The use of any device is merely an exercise in applied physics. None of that has any impact on what is or should be patentable.
And you wouldn't patent the actual dimensions of the film -- even bad patent examiners would catch that -- you'd patent the mechanisms needed to produce film that fit into your camera, or the mechanism needed to get film from its container into the camera's film track. And why shouldn't you be able to? What if you invented a unique way to advance film through a camera, by pre-treating the film in some special way? Shouldn't you be able to patent that useful. non-obvious, unique invention?
Yes. You shouldn't be able to patent that the device stamps the logo after the paint job is applied. You should be able to patent the design of the stamper.
Isn't "the stamper" the same physical object as "the device [that] stamps the logo after the paint job is applied"? I'm really not sure what you're trying to exemplify here.
The point I was trying to make is that In the hardware world, though, process patents are the rare exception.
That's a misconception. In the hardware world. processes are what is patented, just like software or business processes. Every patent in the world starts with "a method or device to..." because the patent is designed to protect not just the object that embodies the design, but the design itself.
Software engineers like to pretend that algorithms -- ordered sets of actions used to achieve some defined outcome -- didn't exist before computers, but mechanical engineers have been using physical algorithms for hundreds of years. There is a discrete mechanical processed involved in the compression of fluids in a scroll compressor; a series of actions has to occur in a particular order to compress the fluid. The patent on the scroll compressor covers that mechanical process. The patent does not cover the use of an identical scroll-shaped piece of metal as a way to channel uncompressed fluids.
There are certainly problems with the patent system. Patents are granted in obvious ideas and on overly-broad claims, litigation is on-sided, and prior art is not adequately examined. But none of those problems are unique to software.
There's no process there. It is a single act, give or take, which results in cooling.
So a specific action or sequence of actions designed to manipulate the properties of some object/data to produce a specific result. That sounds a lot like a process to me. With respect to a patent it's tied to an application for the process, but it's still a protection on way you do things, and not necessarily the result of those actions.
There are other ways to cool a surface. You could put ice on the surface. You could use a Peltier junction. And so on.
And those would be non-infringing ways to cool, because they aren't the same process as using a compressor/evaporator pair. But they each have unique properties (cost, efficiency, compatibility with other components, etc.) that may make them more or less useful for a particular application.
Likewise there are ways to compress audio without using the MP3 algorithm. You could use AAC. Or zip an AIFF file. They are both non-infringing and both produce compressed audio, but they may be more or less useful for a particular application.
It should have to be a patent on the process as applied to some new extension of one of the fundamental building blocks.
This is a rule for software and hardware patents alike. They only cover a particular application. A patent to compress refrigerant would not cover the same physical mechanism being used to compress air (though any good patent attorney would write "device and method for the compression of fluids").
I can see why you think patents are a bad idea in general. I don't fully agree, but I can see how you get there. I only object to the idea that software patents are somehow special and the system works fine so long as there's some bit of matter involved -- the same problems you see with software patents have occurred in the hardware world since long before the word software even existed.
Its the difference between an idea and a realization. For example, take automatic harvesters - when John Deere patented his automatic harvester, others were still free to create other automatic harvesters that worked differently. In software, though, a patent covers an algorithm, rather than the particular implementation.
In hardware patents also cover the process, not the particular implementation. You said so yourself: "others were still free to create other automatic harvesters that worked differently". If they had created automatic harvesters that looked different but worked the same way they'd be in violation of the patent, because it covers the process used by the harvester, not the specific implemenation.
Hardware patents aren't supposed to cover processes. That's a relatively recent abomination.
I'm not talking about business process patents. I'm talking about good, old-fashioned hardware patents, like the one on your air conditioner compressor.
The patent does not cover the specific implementation of that particular compressor. It covers the process (or some part thereof) by which the refrigerant is compressed in that device; any device that uses the same process to compress the refrigerant, even if the device is physically different, would be in violation.
And your three rules for patents would essentially eliminate all practical uses for patents -- essentially you'd be making patents into copyrights, and they are not intended to serve the same purpose, either for the holder or the public. Copyright covers copies of a specific implementation, but allow re-implemenation so long as care is taken to avoid copying. Patents cover a particular process, regardless of implementation, but would not necessarily protect a specific implementation from being used for another purpose. And neither of those is a recent change.
Simple. In hardware, compatibility with other hardware/software is not a requirement.
Right. Because desinging film that fits into Kodak's camera or tires that fit on to GM's car are not relevent in the hardware world. And no one would want to make a processor that 100% compatible with the instruction set of another processor.
Software changes much more rapidly than hardware because of the lack of physical form.
That's possibly true, though I think you underestimate both the amount of time it takes to complete large software projects and the speed with which new hardware can be fabricated. At best though, this is an argument for creating a different duration for software patents, not eliminating them.
Algorithms are either mathematical in nature, in which case they should not be patentable because math is considered to be factual and unpatentable, or they are so trivial that a description of the result to a programmer will get you a similar (if not identical) piece of code.
Again, you can say the same thing about hardware, and it's just as true. "Mechanical processes are physical in nature, and should not be patentable because physics is considered to be factual and unpatentable. Or they are so trivial that a description of the result to an engineer will get you a similar (if not identical) piece of hardware."
That brings us to the last point: prior to the recent allowance of software patents, nothing was eligible for both patent and copyright protection.
On that point I agree wholeheartedly. You should have to choose copyright or patent protection, just like you have to choose patent or trade secret protection. Though it's worth noting that copyright only protects actual copies of the specific implementation, not the process or algorithm -- IBM's BIOS was protected by copyright, but was legally reproduced though a clean-room process. Even if the re-implementation were 100% identical it would not have been a copyright infringment.
There are certainly problems with the system -- obvious patents, terms that don't reflect the amount of work that went in to a patent, one-sided litigation, etc. -- but those are all problems faced by hardware and software patents alike.
Even after you explaination, the only problem I see that's unique to software is the patent + copyright issue, and I have a hard time buying that the only solution (or even the best solution) to that issue is to ban software patents. I think a better solution is to make copyright and patent terms fall in-line with each other. That way when the patent expires the copyright will also expire, and the required-to-be-public-by-the-nature-of-patents implementation would then be available to everyone.
Slashdot Mirror
You're right, SSL isn't a chiper. It's a set of chipers and related algorithms inteaded to provide secure data streams. If we're going to be picky SSL is not a set of tools either. OpenSSL is a set of tools; SSL itself defines what those tools are expected to do.
d =16209755
As for stream vs. block, you're right SSL supports block chipers. And they're even commonly used in things like HTTPS. But they all use CBC (Cipher Block Chaining). So while technically not stream chipers, they have the same limitation I was noting, one that makes them inappopriate for SIP -- you still need to get the entire stream in order to decrpyt them.
And other people agree with my understanding of OpenVPN, and the explaination on their front page -- SSL for auth, ESP for the data stream:
Note that OpenVPN doesn't transport its data stream over SSL. They use IPSec ESP over UDP for that, the same as standard IPSec NAT-T does. They just use SSL over UDP for session authentication and management--in other words, as an IKE replacement, as far as I can tell. In that respect, there's really not much to differentiate it from IPSec NAT-T.
http://ask.slashdot.org/comments.pl?sid=197811&ci
You're excused. But SSL still doesn't work for UDP, at least not in any way that's useful for things like SIP.
You can transmit UDP traffic through an SSL-wrapped tunnel, and you can transmit the SSL data using UDP packets, but since SSL is a stream chiper the other end still has to reassemble the enitre stream, in order before it can decrypt anything. And that in-order, no-lost-packets thing is the whole reason you decided against TCP in the first place -- you didn't want to stop the call for 0.5 seconds or more every time you dropped a single packet.
And I'm not sure that OpenVPN uses SSL for UDP traffic anyway. The front page says "OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." Which reads to me like SSL is used to setup the tunnel, but that the tunnel itself uses IPSec.
http://slashdot.org/comments.pl?sid=276249&cid=203 70399
Sheesh. I'm sorry I upset you by not intuitively understanding a vague reference to a book I haven't read for 10 years.
So here's a hint in kind: when you get out of school, be on the look out for books other than the 4 they've made you read in class. As it turns out, fingers are mentioned, even counted, in many other books, films, and television shows.
I'm not saying there's nothing we can do to reduce the use of bounce messages. Certainly I agree that, when reasonable, mail hosts should reject messages in-session, rather than creating a bounce. But eliminating them altogether means eliminating the store-and-forward methodology, or accepting that mail might not be delivered and you would never know.
For example the ISP case you mention can validate the sender, once you have validated the sender the problem is solved.
No, all you've done if ensure you have someplace valid to deliver bounces, should the message generate any before it leaves you server. But unless you somehow pass that trust forward somehow you haven't done a thing for any mail host other than your own. Remote systems may still need to bounce the message, and they have no way to validate the sender.
He said "Either...or", which is exclusive. You see, in English, "xor" isn't a word, and you have to sometimes read the whole sentence to understand the meaning.
I might, if I had any idea what you were talking about.
Except DynDNS doesn't have local users, so they can't verify directly that messages will be delivered.
A similar problem occurs when you submit outbound mail to your ISP -- unless it's going to someone else at the same ISP, the local SMTP server can't verify that delivery will succeed. At the ISP level it's still probably reasonable to generate bounce message, at least for local users. That way you don't have to do the final delivery right away, users can still get error messages, and you don't risk sending bounces across the Interwebs.
But it gets tricky for forwarding hosts like DynDNS. The only way to reject during the session would be something like:
A) Inbound connection sends message to forwarding server
B) Forwarding server leaves connection open after the DATA command
C) Forwarding server forms outgoing connections to every domain specified in the envelope addresses
D) Forwarding server attempts to deliver the message to all final recipients
E) Forwarding server rejects original connection from (A) if any deliveries in (D) fail
And even if you overcame the technical complications of such a system, it completely dis-allows the use of mail hosts that don't have 24/7 availability. Moreover it eliminates the ability to use secondary hosts, because even if they can validate addresses (which is not trivial) they can't guarantee things like available disk space on the destination server.
Rejecting messages in-session is certainly a good idea, but it's ridiculous to think that it's possible to eliminate bounce messages just by validating local addresses before accepting a message.
That doesn't create a DoS for anyone other than your botnet, which effectively *is* you if you're using the botnet to do things on your behalf. And somehow I don't think "DoS with the scope of a single mail host" is the biggest concern of someone who's box has become part of a botnet.
I'm not suggesting you couldn't get some box other than your own desktop blocked, or that blocking by IP would be effective at stopping spam. I was just refuting the original statement that you could use IP-scoped blocking in response to mail message content as an effective DoS attack.
And we all know you can never make money selling expensive toys or status symbols to the rich.
That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.
n ly scope that is targeted with the attack you describe.
In order to spoof a remote IP address you'd have to basically have to share a wire someplace between the mail server and your spoofing target, or exploit some secondary flaw on a router/host along that same path. It could be done, but there are easier ways to DoS, and most of those ways are effective beyond the single-host-to-single-mailhost-for-mail-service-o
It's "relevant" in that TCP/IP is based on the ideas of the OSI model, and has a similar, layered architecture. In practice though, TCP/IP doesn't follow the OSI model very closely.
For example, in TCP/IP, there's only one layer above the transport layer, which makes OSI layers 5, 6, and 7 all the same. I suppose you could argue that layer 6 never really existed anyway, but that's neither here nor there.
Similarly while there's a technical distinction between layers 1 and 2, in common practice they are too interrelated to speak of as separable layers.
Either the reporter is an idiot, or Microsoft is full of shit.
I suspect those aren't mutually exclusive options.
During which cable goes out too, since they're getting their feed via satellite just like you. They've got bigger dishes with better amps and better wind ratings, so they can withstand somewhat more severe weather. But if there's a general disruption to satellite communications it will affect cable as well.
Corporate person-hood. I hate when my corporation gets called up for jury duty, but I guess it's worth it for the right to vote. Now if only we could get a corporate-birth abortion ban to protect those startups.
If you wanted to discuss how giving money to politians should or shouldn't be protected speech I'm sure someone could oblige you; there are reasonable arguments to be made for both sides. But it's ridiculous to pretend that the problem is with financial entities and not people -- if we didn't let corporations give money or whatnot directly, couldn't the owners and officers of those corporations give money as individuals? Are you suggesting that by becoming an owner or officer in a corporation one should be required to give up their personal rights?
Corporations aren't people and aren't treated legally as people, except insofar as their owners are people. Various forms of financial entities are granted rights of possession and litigation in line with their purpose as financial entities, but they aren't treated as people in general. The supposed "person-hood" that financial entities have is an extension of the actual, physical person-hood that their owners have -- corporations have rights to free speech because their owners have rights to free speech, and I don't see any pratical way to change that, short of opressing the person-hood of business owners.
You could simply choose not to entrust your local mail client with the authoritive copy of your mail archive.
I agree with your preference for easy-to-parse formats -- I prefer maildir myself, as I find it easier to address individual messages programatically when they have their own files -- I'm just saying that the local storage format is not an issue if you don't put your mail client in charge of your message archive.
I'm with you on the exploding -- if you're caught in space you want to do everything possible to reduce your internal pressure.
But it's not that cold in space. There's not a lot of ambient heat, but there's not a lot of conduction or convection either -- you only lose heat as fast as you radiate. So on the timescale of "holding your breath" the temperature of space is not a significant factor. Likewise the radiation you'd absorb over 60 seconds is likely not a large factor, unless you're particularly close to the source (I don't recall the episode, so I can't comment on their depiction of distance from the star(s)).
It's harder to tell when you are, say, judging others.
Here's a hint: you're doing it right now.
I'm all for encryption, but it's not clear to me what an encrypted root file system would buy me. They wouldn't be able to tell what packages I had installed? I already mount root RO, so I'm sure there's nothing being written there in general operation, and I just don't see what appreciable security I'd gain by hiding the contents of that file system.
That and it sure would be handy if I could log in remotely to a mostly-booted system (using a special-purpose account) and enter the passphrase. Without that there's no way to reboot the system remotely, which is a problem at least for me.
Technically they are the only possible options, at least with more than one person involved in the organization. The only other choise is a truely independent reporter who publishes his own work, which doesn't seem terribly scalable.
And apparently you're not aware that both PBS and NPR take money from the government and other corporations, just like other media organizations. Sure they're organized as non-profits, but they still need funding for payroll and other operations, and they're just as likely to choose to give up some control of their content for the sake of keeping the organiztion afloat.
Information cannot be patented.
What do your patents cover? Because mine cover the design of devices and systems, and that design is, in and of itself, nothing more than information.
Film dimensions are not patentable, as they are merely a statement of fact (information).
The schematics of any device are merely statements of fact. The use of any device is merely an exercise in applied physics. None of that has any impact on what is or should be patentable.
And you wouldn't patent the actual dimensions of the film -- even bad patent examiners would catch that -- you'd patent the mechanisms needed to produce film that fit into your camera, or the mechanism needed to get film from its container into the camera's film track. And why shouldn't you be able to? What if you invented a unique way to advance film through a camera, by pre-treating the film in some special way? Shouldn't you be able to patent that useful. non-obvious, unique invention?
Yes. You shouldn't be able to patent that the device stamps the logo after the paint job is applied. You should be able to patent the design of the stamper.
Isn't "the stamper" the same physical object as "the device [that] stamps the logo after the paint job is applied"? I'm really not sure what you're trying to exemplify here.
The point I was trying to make is that In the hardware world, though, process patents are the rare exception.
That's a misconception. In the hardware world. processes are what is patented, just like software or business processes. Every patent in the world starts with "a method or device to..." because the patent is designed to protect not just the object that embodies the design, but the design itself.
Software engineers like to pretend that algorithms -- ordered sets of actions used to achieve some defined outcome -- didn't exist before computers, but mechanical engineers have been using physical algorithms for hundreds of years. There is a discrete mechanical processed involved in the compression of fluids in a scroll compressor; a series of actions has to occur in a particular order to compress the fluid. The patent on the scroll compressor covers that mechanical process. The patent does not cover the use of an identical scroll-shaped piece of metal as a way to channel uncompressed fluids.
There are certainly problems with the patent system. Patents are granted in obvious ideas and on overly-broad claims, litigation is on-sided, and prior art is not adequately examined. But none of those problems are unique to software.
There's no process there. It is a single act, give or take, which results in cooling.
So a specific action or sequence of actions designed to manipulate the properties of some object/data to produce a specific result. That sounds a lot like a process to me. With respect to a patent it's tied to an application for the process, but it's still a protection on way you do things, and not necessarily the result of those actions.
There are other ways to cool a surface. You could put ice on the surface. You could use a Peltier junction. And so on.
And those would be non-infringing ways to cool, because they aren't the same process as using a compressor/evaporator pair. But they each have unique properties (cost, efficiency, compatibility with other components, etc.) that may make them more or less useful for a particular application.
Likewise there are ways to compress audio without using the MP3 algorithm. You could use AAC. Or zip an AIFF file. They are both non-infringing and both produce compressed audio, but they may be more or less useful for a particular application.
It should have to be a patent on the process as applied to some new extension of one of the fundamental building blocks.
This is a rule for software and hardware patents alike. They only cover a particular application. A patent to compress refrigerant would not cover the same physical mechanism being used to compress air (though any good patent attorney would write "device and method for the compression of fluids").
I can see why you think patents are a bad idea in general. I don't fully agree, but I can see how you get there. I only object to the idea that software patents are somehow special and the system works fine so long as there's some bit of matter involved -- the same problems you see with software patents have occurred in the hardware world since long before the word software even existed.
Its the difference between an idea and a realization. For example, take automatic harvesters - when John Deere patented his automatic harvester, others were still free to create other automatic harvesters that worked differently. In software, though, a patent covers an algorithm, rather than the particular implementation.
In hardware patents also cover the process, not the particular implementation. You said so yourself: "others were still free to create other automatic harvesters that worked differently". If they had created automatic harvesters that looked different but worked the same way they'd be in violation of the patent, because it covers the process used by the harvester, not the specific implemenation.
Hardware patents aren't supposed to cover processes. That's a relatively recent abomination.
I'm not talking about business process patents. I'm talking about good, old-fashioned hardware patents, like the one on your air conditioner compressor.
The patent does not cover the specific implementation of that particular compressor. It covers the process (or some part thereof) by which the refrigerant is compressed in that device; any device that uses the same process to compress the refrigerant, even if the device is physically different, would be in violation.
And your three rules for patents would essentially eliminate all practical uses for patents -- essentially you'd be making patents into copyrights, and they are not intended to serve the same purpose, either for the holder or the public. Copyright covers copies of a specific implementation, but allow re-implemenation so long as care is taken to avoid copying. Patents cover a particular process, regardless of implementation, but would not necessarily protect a specific implementation from being used for another purpose. And neither of those is a recent change.
Simple. In hardware, compatibility with other hardware/software is not a requirement.
Right. Because desinging film that fits into Kodak's camera or tires that fit on to GM's car are not relevent in the hardware world. And no one would want to make a processor that 100% compatible with the instruction set of another processor.
Software changes much more rapidly than hardware because of the lack of physical form.
That's possibly true, though I think you underestimate both the amount of time it takes to complete large software projects and the speed with which new hardware can be fabricated. At best though, this is an argument for creating a different duration for software patents, not eliminating them.
Algorithms are either mathematical in nature, in which case they should not be patentable because math is considered to be factual and unpatentable, or they are so trivial that a description of the result to a programmer will get you a similar (if not identical) piece of code.
Again, you can say the same thing about hardware, and it's just as true. "Mechanical processes are physical in nature, and should not be patentable because physics is considered to be factual and unpatentable. Or they are so trivial that a description of the result to an engineer will get you a similar (if not identical) piece of hardware."
That brings us to the last point: prior to the recent allowance of software patents, nothing was eligible for both patent and copyright protection.
On that point I agree wholeheartedly. You should have to choose copyright or patent protection, just like you have to choose patent or trade secret protection. Though it's worth noting that copyright only protects actual copies of the specific implementation, not the process or algorithm -- IBM's BIOS was protected by copyright, but was legally reproduced though a clean-room process. Even if the re-implementation were 100% identical it would not have been a copyright infringment.
There are certainly problems with the system -- obvious patents, terms that don't reflect the amount of work that went in to a patent, one-sided litigation, etc. -- but those are all problems faced by hardware and software patents alike.
Even after you explaination, the only problem I see that's unique to software is the patent + copyright issue, and I have a hard time buying that the only solution (or even the best solution) to that issue is to ban software patents. I think a better solution is to make copyright and patent terms fall in-line with each other. That way when the patent expires the copyright will also expire, and the required-to-be-public-by-the-nature-of-patents implementation would then be available to everyone.