(usual disclaimer about my total lack of legal training, and the face that this is only my opinion)
This decision appears to be legally shaky and could get reversed on appeal. The judge has ruled that BE cannot crawl eBay because the crawler is using some small percentage of eBay's server resources, and eBay has the right to limit who uses their "personal property" (in this case, their server resources). However, there are some limitations to the application of law regarding protection of personal property.
The property should be private, i.e. not a public resource. While it can be argued that eBay servers are the property of eBay, these servers serve web pages to the public Internet. eBay constantly advertises asking people to come to their site. It could be argued that eBay's website is an open accommodation. This is a somewhat weak legal argument due to the disclaimers that are sure to be somewhere on www.ebay.com, but legal disclaimers will not apply if the appeals court rules that their website is an open accommodation.
To classify an open accommodation as private, the owner of the item should have taken reasonable precautions to inform the infringing party of their trespass. This is why land has "No trespassing" signs on it. I don't see any such signs on eBay, and in any case it can be argued that accessing auction information on eBay is retrieving the information that eBay is designed to serve, and cannot be termed trespass.
If the property is ruled an open accommodation, the owner must show that he has suffered reasonable loss by the trespass. This is why, if I leave my house door open by mistake and you come in and steal my stuff, I still have legal recourse to recover it (assuming I find you). In the case of software which can be copied freely, this law is applied by the copyright holder under the (perhaps dubious) justification that it causes them economic loss. It appears eBay attorneys have claimed protection under this law, saying that their servers are under load from BE's spider. However, if it is ruled that the primary purpose of the accommodation is the only purpose to which the infringing party puts the accommodation to use, this should not be a valid argument. The situation is akin to a bulletin board you put up outside your house. The space in front of the bulletin board is a limited resource (since if you are not standing in front of it, you cannot read the notices). If somebody walks by once every hour, stands in front of the board for five minutes and reads the notices, this isn't trespass until you can show that this person is causing you reasonable loss. If he stood in front of the board all the time, thereby preventing anybody else from reading it, that would be a valid argument.
Exactly why does somebody have to pick a side, and stand with it? This "Linux r00lz, sux" is as bad as "Free software has no future; it has no guiding hand, no support, you cannot sue anybody". Both can be termed as factionalism.
A couple of years ago, I interned at a web development company. We had a specific mantra - don't get involved in the browser battle. We ensured all our websites (even the fancy ones with JavaScript) worked on both Netscape and IE. In those days, that was *hard* to do. But we did it. I applaud ActiveState for attempting to walk the same line, and being browser agnostic. Last I checked, there was nothing in the Mozilla license which said, "Thou shalt not use, support or otherwise condone Microsoft or the use of Microsoft products".
Don't get me wrong. I live a Microsoft-free life, having divested myself of my Windows box at work some time back by the simple expedient of installing Linux on it (not even dual-boot:-). I'd love to see Mozilla succeed as much as the next guy. But I separate "the success of Mozilla" and "the failure of IE/MS" into *two separate events*. While I would not be displeased if both occurred, either one on it's own also makes me happy.
So, you're talking about sporadic message transmission from a client computer, and saying that encryption is not required for this. OK, I agree. But consider:
1) This option is not available on a server, where performance and throughput is essential. I work in a large router company, and we have features in our operating system which allow users to filter packets in order to improve security. Most users turn them off. Why? Performance and cluelessness. The cluelessness issue we can solve, but what about performance? The solution is, do it in hardware (this is the way the industry is moving). I would venture to say the same about servers.
2) As a client, are you willing to slow your downloads of files over a corporate LAN from 50Mb/s down to some kb/s value? Because that's what you are going to get if you want to software-encrypt/decrypt all your LAN traffic.
2) Using encryption for "everything"? Ok, what about real-time video? Streaming MP3s? I suppose you could use the CPU power to do this as well, but IMHO this is a waste of CPU resources (although at the rate CPUs are growing in clock rate and processing power, it's probably a moot point).
3) Expanding motherboard capabilities is really not that expensive, IF it is a commoditized product. I pointed to the example of 3-D cards, but in truth all sorts of stuff is being built onto motherboards these days (ACPI, AMR etc.)
4) There's also a significant marketing issue. Consider the case of the WWW. There's no amazing new technology in the concept of a browser - it was just an idea whose time had come, *and* which caught the public imagination. (For an example of a technology which has all the above attributes except public acceptance, see IPv6). I'd venture to say the same is true about encryption. Shipping on-board ubiquitious encyption *may* spark the people into actually using it.
All these go to show that encrypting "everything" is not realistic without hardware. The original poster appeared to encrypt a *lot* in software and at no cost, but that's only if you count tasks rather than bandwidth. Let's take a look at what he encrypted - - SSH sessions (i.e. telnet) - Email (i.e. ASCII text) - Local stuff What did he not encrypt? - HTTP pages (he did recommend it; see 1) - FTP traffic. - Other downloads (MS SMB, etc) I'd venture to say that the latter class of traffic dwarfs the former in terms of bandwidth.
Although my original statement was probably inaccurate - I'll rephrase it as follows: "Ubiquitous encryption is expensive, and probably requires hardware. A significant amount of encryption on the client side is possible at little or no cost.".
Oh, and about the PCI/USB thing - you're right. Although I would venture to say that it would perhaps be a lot cheaper to just build something into a chipset as opposed to build a card. Making cards has a significant overhead (going up and up these days) as chip integration becomes better and cheaper. There's also the issue of motherboard real estate, I suppose. But I won't belabor this point.
Do you also recommend that all cars be built like tanks, able to withstand a 60 mph crash?
The point is that while it's a worthy goal to encrypt everything for the heck of it, it is not cost effective. Just like it is not cost effective to install two-inch armor plating and internal gel padding on cars, even though it would cut automotive fatality rates by 90%.
As a security expert, you know that encryption is EXPENSIVE. The only way to bring down the cost of custom encryption devices is commoditization. Just like awesome 3-D graphics has fallen within the reach of the masses due to commoditization (anybody remember the $15K+ Elsa & E&H cards that rendered 50K triangles/sec? It wasn't that long back). You basically want a DES (or, more likely, AES) encryption chip on each motherboard.
For this to happen, we need the following:
1) A publicly accepted AES standard. All AES standards require hardware implementations, and I believe all the final proposed candidates have efficient hardware implementations.
2) A cheap chip (or, even better, build it into the mobo chipset).
3) A well-defined API to this device. I assume 2 and 3 will go hand-in-hand.
4) Intel or VIA (through Asus, Abit & others) to buy into this and start building it on their chipset. Alternatively, Once one manufacturer does it, all the others will, too. It's just too big a competitive advantage.
Slashdot Mirror
(usual disclaimer about my total lack of legal training, and the face that this is only my opinion)
This decision appears to be legally shaky and could get reversed on appeal. The judge has ruled that BE cannot crawl eBay because the crawler is using some small percentage of eBay's server resources, and eBay has the right to limit who uses their "personal property" (in this case, their server resources). However, there are some limitations to the application of law regarding protection of personal property.
- The property should be private, i.e. not a public resource. While it can be argued that eBay servers are the property of eBay, these servers serve web pages to the public Internet. eBay constantly advertises asking people to come to their site. It could be argued that eBay's website is an open accommodation. This is a somewhat weak legal argument due to the disclaimers that are sure to be somewhere on www.ebay.com, but legal disclaimers will not apply if the appeals court rules that their website is an open accommodation.
- To classify an open accommodation as private, the owner of the item should have taken reasonable precautions to inform the infringing party of their trespass. This is why land has "No trespassing" signs on it. I don't see any such signs on eBay, and in any case it can be argued that accessing auction information on eBay is retrieving the information that eBay is designed to serve, and cannot be termed trespass.
- If the property is ruled an open accommodation, the owner must show that he has suffered reasonable loss by the trespass. This is why, if I leave my house door open by mistake and you come in and steal my stuff, I still have legal recourse to recover it (assuming I find you). In the case of software which can be copied freely, this law is applied by the copyright holder under the (perhaps dubious) justification that it causes them economic loss. It appears eBay attorneys have claimed protection under this law, saying that their servers are under load from BE's spider. However, if it is ruled that the primary purpose of the accommodation is the only purpose to which the infringing party puts the accommodation to use, this should not be a valid argument. The situation is akin to a bulletin board you put up outside your house. The space in front of the bulletin board is a limited resource (since if you are not standing in front of it, you cannot read the notices). If somebody walks by once every hour, stands in front of the board for five minutes and reads the notices, this isn't trespass until you can show that this person is causing you reasonable loss. If he stood in front of the board all the time, thereby preventing anybody else from reading it, that would be a valid argument.
Just my $0.02Exactly why does somebody have to pick a side, and stand with it? This "Linux r00lz, sux" is as bad as "Free software has no future; it has no guiding hand, no support, you cannot sue anybody". Both can be termed as factionalism.
:-). I'd love to see Mozilla succeed as much as the next guy. But I separate "the success of Mozilla" and "the failure of IE/MS" into *two separate events*. While I would not be displeased if both occurred, either one on it's own also makes me happy.
A couple of years ago, I interned at a web development company. We had a specific mantra - don't get involved in the browser battle. We ensured all our websites (even the fancy ones with JavaScript) worked on both Netscape and IE. In those days, that was *hard* to do. But we did it. I applaud ActiveState for attempting to walk the same line, and being browser agnostic. Last I checked, there was nothing in the Mozilla license which said, "Thou shalt not use, support or otherwise condone Microsoft or the use of Microsoft products".
Don't get me wrong. I live a Microsoft-free life, having divested myself of my Windows box at work some time back by the simple expedient of installing Linux on it (not even dual-boot
So, you're talking about sporadic message transmission from a client computer, and saying that encryption is not required for this. OK, I agree. But consider:
1) This option is not available on a server, where performance and throughput is essential. I work in a large router company, and we have features in our operating system which allow users to filter packets in order to improve security. Most users turn them off. Why? Performance and cluelessness. The cluelessness issue we can solve, but what about performance? The solution is, do it in hardware (this is the way the industry is moving). I would venture to say the same about servers.
2) As a client, are you willing to slow your downloads of files over a corporate LAN from 50Mb/s down to some kb/s value? Because that's what you are going to get if you want to software-encrypt/decrypt all your LAN traffic.
2) Using encryption for "everything"? Ok, what about real-time video? Streaming MP3s? I suppose you could use the CPU power to do this as well, but IMHO this is a waste of CPU resources (although at the rate CPUs are growing in clock rate and processing power, it's probably a moot point).
3) Expanding motherboard capabilities is really not that expensive, IF it is a commoditized product. I pointed to the example of 3-D cards, but in truth all sorts of stuff is being built onto motherboards these days (ACPI, AMR etc.)
4) There's also a significant marketing issue. Consider the case of the WWW. There's no amazing new technology in the concept of a browser - it was just an idea whose time had come, *and* which caught the public imagination. (For an example of a technology which has all the above attributes except public acceptance, see IPv6). I'd venture to say the same is true about encryption. Shipping on-board ubiquitious encyption *may* spark the people into actually using it.
All these go to show that encrypting "everything" is not realistic without hardware. The original poster appeared to encrypt a *lot* in software and at no cost, but that's only if you count tasks rather than bandwidth. Let's take a look at what he encrypted -
- SSH sessions (i.e. telnet)
- Email (i.e. ASCII text)
- Local stuff
What did he not encrypt?
- HTTP pages (he did recommend it; see 1)
- FTP traffic.
- Other downloads (MS SMB, etc)
I'd venture to say that the latter class of traffic dwarfs the former in terms of bandwidth.
Although my original statement was probably inaccurate - I'll rephrase it as follows: "Ubiquitous encryption is expensive, and probably requires hardware. A significant amount of encryption on the client side is possible at little or no cost.".
Oh, and about the PCI/USB thing - you're right. Although I would venture to say that it would perhaps be a lot cheaper to just build something into a chipset as opposed to build a card. Making cards has a significant overhead (going up and up these days) as chip integration becomes better and cheaper. There's also the issue of motherboard real estate, I suppose. But I won't belabor this point.
Do you also recommend that all cars be built like tanks, able to withstand a 60 mph crash?
The point is that while it's a worthy goal to encrypt everything for the heck of it, it is not cost effective. Just like it is not cost effective to install two-inch armor plating and internal gel padding on cars, even though it would cut automotive fatality rates by 90%.
As a security expert, you know that encryption is EXPENSIVE. The only way to bring down the cost of custom encryption devices is commoditization. Just like awesome 3-D graphics has fallen within the reach of the masses due to commoditization (anybody remember the $15K+ Elsa & E&H cards that rendered 50K triangles/sec? It wasn't that long back). You basically want a DES (or, more likely, AES) encryption chip on each motherboard.
For this to happen, we need the following:
1) A publicly accepted AES standard. All AES standards require hardware implementations, and I believe all the final proposed candidates have efficient hardware implementations.
2) A cheap chip (or, even better, build it into the mobo chipset).
3) A well-defined API to this device. I assume 2 and 3 will go hand-in-hand.
4) Intel or VIA (through Asus, Abit & others) to buy into this and start building it on their chipset. Alternatively, Once one manufacturer does it, all the others will, too. It's just too big a competitive advantage.