1. Historically, Wind River's success in the embedded market was based on the strength of its tool chain rather than the strength of its embedded OS. I suspect that the company's decision to broad the number of OS's that it is supporting is a reflection that the management team has figured this out.
2. As networking becoming more and more important, the requirement for a hard real-time operating systems decreases. You can't get deterministic performance out of a TCP/IP, which means that you can't get it out of a networked application. As a result, a number of designs are going in a different direction, combining a hard real-time hardware component coupled with an embedded Linux control/management plane...
I don't see how poker bots present any kind of a unique problem.
Online casino's exist in order to rake money off the table. They don't care if this comes from bots or humans. Lets assume that the bots get so good that every single human gets replaced by a poker bot.
What does it really matter? The online casino's will still generate money, only they'll be funded by bad bot writer's rather than bad poker players.
Think of it as a more intellectual version of battlebots...
I spent a glorious month backpacking through Thailand back in January. The country is quite wired, so I had the chance to check in from a number of cyber-cafes.
I'll use this opportunity to put in a plug for Thailand. Wonderful country. Can't recommend it highly enough.
My only regret is that I wasn't able to purchase any teak furniture while I was up North. If you are willing to ship and entire container (~$5000 or so), you can get incredible bargains. Large dining room table and 6 chairs, beautiful construction for about $600.
If anyone is considering a visit, cut a deal with friends beforehand and bring schematics...
>Next step (barring gaping holes) is to get a >standards effort going - and most of the needed >standards already exist
You do, of course, realize that IBM has already patented this same idea. They define this as an interrupt cost, but the basic principles are pretty much identical...
Check out http://www.findarticles.com/p/articles/mi_m0ISJ/is _4_41/ai_94668338
I am a firm believer in "end-to-end" security models based on IPSec. With this said and done, there are a lot reason's why datalink layer security is desirable. Most notably, if I am relying solely on network layer or application layer security then by definition, I need to grant datalink layer access to my network before I can use the network layer to authenticate. Many folks consider this problematic.
Equally significant, suppose that I do exacly as you say and only encrypt application layer data while expose TCP and IP headers. This would allow individual to determine the specific protocols being used to exchange data and in turn, to use known plaintext attacks. I KNOW that a telnet session is going to start with some "IAC DO" and "IAC WILL's". I can make some guesses regarding what a file downloaded over HTTP is going to look like.
Here's my perspective based on far too much time working as a Product Manager:
I strongly prefer development models that are based on incremental releases that ship at regular intervals. Ideally, I prefer systems in which a new version of the product ships one every 4 monthes. Those features/functions that are "ready" get included in a release. Features that aren't ready will be slipped until the next version.
This development process requires MUCH more work to set up. Code needs to be modular enough that features can be added/subtracted from a candidate without destablizing the entire system. Furthermore, there isn't much down time for release engineering. As soon as one release has shipped out the door, the next one is almost ready for testing.
With this said and done: From my perspective, companies that focus on a small number of "Hail Mary" releases produce crappy products. If you only shipping one release every 18 -24 months then EVERYTHING gets shipped with that release, regardless of the quality of the code. Equally significant, your release engineering process inevitably gets very sloppy since the individuals running this never get sufficient practice. Finally, you are inevitably forced to push out large numbers of patches to fix all the crap that contaminated your original version. These patch releases re-introduce most of the same problems that crop up with a "regular" release model, but without the right infrastructure to support this model.
Far better to bite the bullet and design for success from the beginning...
Bullshit. IPS was a Gartner attempt to generate publicity that even they have disowned.
Think about this logically: According to gartner, the critical flaw with Intrusion Detection Systems was false positives. The sheer number of false positives generated by IDS system was overwhleming the ability of network admistrators to react.
Gartner's "solution"??? Intrusion Prevention Systems that would automatically act to block inappropriate behaviour.
In what way, shape, or form does automatically locking down Network Resources solve the problem of false positives???
I agree completely that improved filtering is a good thing, however, this is orthogonal to the whole IDS/IPS debate.
Does anyone else find it interesting that Google is announcing new features for searching large filesystems at the same time that they are also providing customers with Terabytes of free storage?
You don't provide folks with a terabyte of storage in order to hold emails. This has to be an outsourced storage play...
The attack in question is a method to reset a TCP connection. The TCP reset is launched against one of the two end nodes participating in the TCP connection. The router has NOTHING to do with this. In theory, if an intermediate system like a router goes down, IP will simply find a new path arround the outtage.
The reason that routers feature prominently in this discussion is that Border Gateway Protocol uses very long lives TCP connections. In turn, this means that routers are very vulnerable to this attack. However, the vulnerability effects routers in their roles as an end nodes (sending or recieving data) rather than their role as an intermediate system (forwarding traffic)
It is notoriously difficult to transfer technologies from in-house research institutes to in-house commercial applications. Case in point Xerox PARC developed any number of ground-breaking innovations. Xerox was able to capture significant value from precisely one of those breakthroughs. [Xerox printers use Ethernet as a bus architecture which is still ahead of its time].
The problem is not that PARC did not create value, but rather that Xerox did not seem to have any particular advantage in embracing the innovations that were spun out.
I don't find it particularly surprising that Microsoft is running into some of the same problems.
From my perspective, something like "this" could provide a great deal of value to consumers. Personally, I'd very much like to be able to consolidate a wide variety of physical access devices into a single token.
Case in point, right now I am carrying:
Car keys Keys to my house An ID badge for work 2 credit cards drivers license
I would strong prefer to replace these with a single charm. More over, a secure physical token makes key distribution much easier. With this said and done, there look to be some clear problems the SONY / NTT DoCoMo implementation.
First: I don't think that they have the form factor right. Its too easy to lose a cell phone. They are bulky and annoying. I understand why SONY wants to promote a model in which people need to carry a cell phone 24 hours a day, but its just not my cup of tea. I would much rather be able to embed this functionality within a class ring, and ear right, or even an implantable microchip.
Second: I worry about the security implications. Today, the prevailing wisdom is that a layer authorization model is required to prove identity. Authorization is based on
(a) Who you are (b) Something you know (c) Something you have
The SONY phone is OK as a physical token, however, I didn't see much about the other two dimensions to the problem.
I am surprised that no-one has yet noted that opportunistic encryption is a very simple "solution" to this issue, along with a host of other related problems.
Many people, myself included, object to "smart network" architectures. I dislike networks in which intermediate devices such as routers and switches provide a host of value added services like Quality of Service, tracking Napster users, or taxing VoIP traffic. I prefer network designs in which "smart" end nodes are linked together by "Big Dumb Pipes".
The best way to preserve this type of architecture is to start deploying point-to-point encryption on a massive scale. The network can only provide value added services if it is capable of understanding the traffic that you are sending.
#1. Odds are the reason that the development work got outsourced was simple comparative advantage. I'd rather have an undergrad or grad student working on something original and interesting rather than grunt level coding. As many people have noted, low-level jobs are being outsourced rather rapidly. I consider it a very GOOD thing the MIT isn't wasting its student's time with what would appear to be a dead end skill set.
#2. If you want to bitch about MIT and ties to Microsoft there are much better areas to criticize. For example, the business school is a lock-down Microsoft shop. If you don't have a Microsoft OS, you can't get a digital certificate. If you can't get a digital certificate, you can't get access to anything from your home PC. I've heard a wide number of speculations about why this is so [the rest of the University has a much more liberal policies]. I've heard lots of talk that Sloan needs to maintain its own IT department to roll out like 802.11b quicker than the rest of the University. Of course those who like conspiracy theories do note that the Dean made a fair amount of money as a hired witness for MS during the anti-trust trials.
1. Eliminating the header checksum makes it substantially easier to develop forwarding ASIC.
2. It was generally believed that the IPv6 header checksum doesn't provide all that much value. Suppose, for a moment, that the IP header became corrupted in some way. What's the worst thing that could happen? Eliminating the header checksum removes intelligence from the core and relocates it to end nodes [In this case, Intermediate systems no longer need to perform error detection. Instead, developers who require reliability can make use of existing fucntions build into the transport layer]
One of the principle design goals of IPv6 was to simplify the workload for routers. IPv6 achieves this in a number of ways:
1. Part of the reason that IP addresses are so long is that part of the address space is being used for an improved addressing hierarchy. In turn, this will allow routers to maintain much shorter routing tables. 2. IPv6 routers not longer fragment IP datagrams 3. IP Header checksums are been removed
As many people have noted, the IPv6 addressing structure supports a much larger number of IP addresses. Experts are predicting that the number of IP addresses required are going to increase enormously in a relatively short amount of time. Most people are familiar with cell phone adoption rates and the impact on IP address assignment. Potentially a more interesting example is the impact of new PC bus architectures on networking models. Intel has announced a new bus architecture titled PC-Express. What makes PC Expressing interesting is that it applies a data networking model to the PC bus. [Thinking addresses, flow control, retransmissions, etc] Where this gets interesting is that PC Express can be scaled from the level of a PC bus up to an enterprise class switching fabric. Once this gets widely deployed, there is no reason why the processor on one system could not control the video card on another. We are rapidly migrating to a model in which all sorts of peripherals - processors, sound cards, hard drives - will need to be configured with their own IP addresses.
IPv6 provides much better support for autoconfiguration. This is critically important for the consumer electronics manufacturers in the Asia/Pacific.
IPv6 requires IPSec, so we might finally get pervasive network layer security. I'll be very happy to get rid of abominations like "SSL VPNs".
There is a LOT of good stuff coming down the pike.
I found it extremely amusing that Verisign selected the CTO of Brightmail as part of the group doing the technical evaluation. Brightmail is an anti-SPAM vendor that is very heavily invested in signature based anti-SPAM systems.
While Site Finder broke a wide number of different systems on the Internet, crippling DNS based anti-SPAM probably had the greatest direct impact on the lives of end users.
From my perspective, I can't help but think that there might have been some kind of conflict of interest here.
It's interesting to notice the difference in focus between Craig Barrett's statements and the Slashdot's focus.
Barrett is an executive at Intel. His primary concern is whether the Chinese or the Indians will succeed with localizing microprocessor design. Needless to say, he is predisposed to believe that these efforts should not be undertaken.
Here on Slashdot, the primary focus is the various attempts taking place in Asia to standardize around Linux. From my own perspective, I don't think that this effort is logically equivalent to the Barrett's hardware example. I don't see the effort at promoting Linux as an attempt to fork the code base, but rather an effort to unify the development community around a single standard. With luck, this effort will result in better contributions to the core Linux code base.
This suggestion is badly flawed at multiple levels.
First and foremost, Russ Cooper's is suggesting that ISP's should be fined if they fail to block attacks that propagate across their networks. This proposal violates the basic end-to-end architectural principles on which the Internet was founded. Intelligence should be localized at the end node, supported by a "stupid" network infrastructure whose function is restricted to routing packets from point to point. "Smart" networks don't scale and they cost enormous amounts of money. Most individuals who are pushing these models are more concerned with supporting a business model rather than a viable technology. Consider what is necessary for Cooper's suggestion to work: Each ISP needs to preserve state on all the TCP connections emanating from a host to ensure that the host is not starting some kind of attack.
It might be possible to create a similar model assigning all liability to the computer owner: Joe Smith's decision to run an insecure system presents a potential threat to some class of computer users. Hence, this action could be considered to be actionable. Here once again, we have a logical fallacy: Suppose that Joe's computer is vulnerable to the XYZ worm. Joe's computer is compromised and used to launch the XYZ worm at other PCs on the Internet. However, the major group of people that are put at risk by Joe's vulnerability is the set of users who share this same vulnerability. In short, the class action lawsuit would be directed against the plaintiffs.
It is certainly possible to argue that compromised systems can be used to inconvenience Internet users in other ways. Case 1: A PC could be used as a Zombie in a distributed denial of service attack. Case 2: A PC could be used as a part of a SPAM generation network. Here, the "cost" of the attack is proportional to the amount of traffic being generated by the host. In theory, if you want to establish a linkage between fines and the cost of a system being compromised, the fine should be proportional to the amount of traffic being generated. I would argue that this would be better accomplished through a tarriffing system in which monthy access charges were proportional to traffic volume.
Ultimately, Cooper's proposal would require some kind of licensing system for operating systems. This is an incredibly ugly thought.
There are some MAJOR issues with this suggestion. Most notably, the Longhorn Operating System is DRM enabled. This means that the OS/hardware is designed to block programmers from making a wide variety of direct calls to the hardware. Supposedly, this is intended to make is much more difficult to copy "Content", however, it also makes it much more difficult to write a small/efficient AV engine.
Microsoft will probably bundle an AV engine with Longhorn (supposedly, this is the main reason for Microsoft's GeCAD acquisition). It might be possible to develop an Open Source content distribution system to produce definition files for the engine, however, Microsoft might very well decide to block the interface to the engine. It will be interesting to see what happens.
I think that you fundamentally misunderstand why people dislike the "razor + razor blades" model. Razor + razor blades is an example of a modular design. This is normally considered to be a good thing.
Where the model is typically abused is the desire to apply cross subsidies between different modules. HP applies dramatic discounts to printers and attempts to make this money back by charging premiums on toner cartridges.
This inevitably triggers ugly battles with consumers. Vendors attempt to use proprietary interfaces to protect their revenue streams. Consumers look to third party suppliers.
For what its worth, I did some research on thsi subject last semester. From what I was able to determine, cross subsidies were a net loss for companies. Any financial gains that the companies hoped to generate were consumed by additional R+D/legal expenses to protect the interface. More critically, the desire to protect a cash cow significantly hurt the flexibility of the company. Polaroid became completely trapped by the need to protect the revenue stream from its film business that it was unable to adapt to digital photography.
As other people have pointed out, there are a number of different components to a comprehensive AV solution. The AV engine is certainly one important component, but "content" in the form of definition files and the speed/security with which this content is made available are equally important.
Ideally, companies should charge separately for both components.
I've started to wonder whether there might not be an inverse relationship between the rate at which a worm spreads and the type of payload that it carries.
If I have a worm that propagates relatively slowly, this may limit my ability to deploy a nasty payload. I need infected hosts up and running in order to infect other systems.
Contrast this with a "flash worm" which propagates at an enormously high rate of speed. After 15 minutes, almost all vulnerable hosts will be infected. No reason not to frag the system.
Many of the discussions taking place on this mailing list seem to be focusing on one part of this argument while ignoring a number other significant issues.
Case in point: Let us consider a production process in which output is a function of two factors of production. K = Capital and L = Labor. Globalization is creating new opportunities to outsource labor, which, in turn is causing the price of labor to fall. Simply put, wages are falling while returns to capital owners are increasing. In turn, everyone on Slashdot is obsessing where it is good or bad that jobs are being outsourced.
What is being neglected is that the government can (and some would argue) should intervene in the economy to smooth out the dislocations. The higher returns that are being generated by the capital owners can be taxed and used to provide income supplements and educational training to displaced workers. If the outsources is "pareto improving" income to capital owners can be increased without decreasing returns to labor, then go ahead and outsource away. If, however, outsourcing results in a net drain on the economy, things get a bit more dicey.
Where the current systems in the US are breaking down is the combination of massive outsourcing with increasingly regressive social policies. We are increasing the share allocated to capital at the same time that we are slashing taxes. In turn, this is dramatically skewing income distributions. Not a good combination.
Slashdot Mirror
Couple points here that I think need to be made:
1. Historically, Wind River's success in the embedded market was based on the strength of its tool chain rather than the strength of its embedded OS. I suspect that the company's decision to broad the number of OS's that it is supporting is a reflection that the management team has figured this out.
2. As networking becoming more and more important, the requirement for a hard real-time operating systems decreases. You can't get deterministic performance out of a TCP/IP, which means that you can't get it out of a networked application. As a result, a number of designs are going in a different direction, combining a hard real-time hardware component coupled with an embedded Linux control/management plane...
I don't see how poker bots present any kind of a unique problem.
Online casino's exist in order to rake money off the table. They don't care if this comes from bots or humans. Lets assume that the bots get so good that every single human gets replaced by a poker bot.
What does it really matter? The online casino's will still generate money, only they'll be funded by bad bot writer's rather than bad poker players.
Think of it as a more intellectual version of battlebots...
I spent a glorious month backpacking through Thailand back in January. The country is quite wired, so I had the chance to check in from a number of cyber-cafes.
I'll use this opportunity to put in a plug for Thailand. Wonderful country. Can't recommend it highly enough.
My only regret is that I wasn't able to purchase any teak furniture while I was up North. If you are willing to ship and entire container (~$5000 or so), you can get incredible bargains. Large dining room table and 6 chairs, beautiful construction for about $600.
If anyone is considering a visit, cut a deal with friends beforehand and bring schematics...
>Next step (barring gaping holes) is to get a
s _4_41/ai_94668338
>standards effort going - and most of the needed
>standards already exist
You do, of course, realize that IBM has already patented this same idea.
They define this as an interrupt cost, but the basic principles are pretty much identical...
Check out http://www.findarticles.com/p/articles/mi_m0ISJ/i
I am a firm believer in "end-to-end" security models based on IPSec. With this said and done, there are a lot reason's why datalink layer security is desirable. Most notably, if I am relying solely on network layer or application layer security then by definition, I need to grant datalink layer access to my network before I can use the network layer to authenticate. Many folks consider this problematic.
Equally significant, suppose that I do exacly as you say and only encrypt application layer data while expose TCP and IP headers. This would allow individual to determine the specific protocols being used to exchange data and in turn, to use known plaintext attacks. I KNOW that a telnet session is going to start with some "IAC DO" and "IAC WILL's". I can make some guesses regarding what a file downloaded over HTTP is going to look like.
Here's my perspective based on far too much time working as a Product Manager:
I strongly prefer development models that are based on incremental releases that ship at regular intervals. Ideally, I prefer systems in which a new version of the product ships one every 4 monthes. Those features/functions that are "ready" get included in a release. Features that aren't ready will be slipped until the next version.
This development process requires MUCH more work to set up. Code needs to be modular enough that features can be added/subtracted from a candidate without destablizing the entire system. Furthermore, there isn't much down time for release engineering. As soon as one release has shipped out the door, the next one is almost ready for testing.
With this said and done: From my perspective, companies that focus on a small number of "Hail Mary" releases produce crappy products. If you only shipping one release every 18 -24 months then EVERYTHING gets shipped with that release, regardless of the quality of the code. Equally significant, your release engineering process inevitably gets very sloppy since the individuals running this never get sufficient practice. Finally, you are inevitably forced to push out large numbers of patches to fix all the crap that contaminated your original version. These patch releases re-introduce most of the same problems that crop up with a "regular" release model, but without the right infrastructure to support this model.
Far better to bite the bullet and design for success from the beginning...
From my perspective, it would be best to focus on the example that Microsoft themselves chose:
...
My PC includes components manufacturered by a large number of different companies.
I have an Intel Processor, and nVidia video card, a Phonenix BIOS, a couple different operating systems,
Bullshit. IPS was a Gartner attempt to generate publicity that even they have disowned.
Think about this logically: According to gartner, the critical flaw with Intrusion Detection Systems was false positives. The sheer number of false positives generated by IDS system was overwhleming the ability of network admistrators to react.
Gartner's "solution"??? Intrusion Prevention Systems that would automatically act to block inappropriate behaviour.
In what way, shape, or form does automatically locking down Network Resources solve the problem of false positives???
I agree completely that improved filtering is a good thing, however, this is orthogonal to the whole IDS/IPS debate.
Does anyone else find it interesting that Google is announcing new features for searching large filesystems at the same time that they are also providing customers with Terabytes of free storage?
You don't provide folks with a terabyte of storage in order to hold emails. This has to be an outsourced storage play...
What dinkleberries modded this up to a 5???
Let's make a few things clear:
The attack in question is a method to reset a TCP connection. The TCP reset is launched against one of the two end nodes participating in the TCP connection. The router has NOTHING to do with this. In theory, if an intermediate system like a router goes down, IP will simply find a new path arround the outtage.
The reason that routers feature prominently in this discussion is that Border Gateway Protocol uses very long lives TCP connections. In turn, this means that routers are very vulnerable to this attack. However, the vulnerability effects routers in their roles as an end nodes (sending or recieving data) rather than their role as an intermediate system (forwarding traffic)
It is notoriously difficult to transfer technologies from in-house research institutes to in-house commercial applications. Case in point Xerox PARC developed any number of ground-breaking innovations. Xerox was able to capture significant value from precisely one of those breakthroughs. [Xerox printers use Ethernet as a bus architecture which is still ahead of its time].
The problem is not that PARC did not create value, but rather that Xerox did not seem to have any particular advantage in embracing the innovations that were spun out.
I don't find it particularly surprising that Microsoft is running into some of the same problems.
From my perspective, something like "this" could provide a great deal of value to consumers. Personally, I'd very much like to be able to consolidate a wide variety of physical access devices into a single token.
Case in point, right now I am carrying:
Car keys
Keys to my house
An ID badge for work
2 credit cards
drivers license
I would strong prefer to replace these with a single charm. More over, a secure physical token makes key distribution much easier. With this said and done, there look to be some clear problems the SONY / NTT DoCoMo implementation.
First: I don't think that they have the form factor right. Its too easy to lose a cell phone. They are bulky and annoying. I understand why SONY wants to promote a model in which people need to carry a cell phone 24 hours a day, but its just not my cup of tea. I would much rather be able to embed this functionality within a class ring, and ear right, or even an implantable microchip.
Second: I worry about the security implications. Today, the prevailing wisdom is that a layer authorization model is required to prove identity. Authorization is based on
(a) Who you are
(b) Something you know
(c) Something you have
The SONY phone is OK as a physical token, however, I didn't see much about the other two dimensions to the problem.
I am surprised that no-one has yet noted that opportunistic encryption is a very simple "solution" to this issue, along with a host of other related problems.
Many people, myself included, object to "smart network" architectures. I dislike networks in which intermediate devices such as routers and switches provide a host of value added services like Quality of Service, tracking Napster users, or taxing VoIP traffic. I prefer network designs in which "smart" end nodes are linked together by "Big Dumb Pipes".
The best way to preserve this type of architecture is to start deploying point-to-point encryption on a massive scale. The network can only provide value added services if it is capable of understanding the traffic that you are sending.
... I have a couple observations:
#1. Odds are the reason that the development work got outsourced was simple comparative advantage. I'd rather have an undergrad or grad student working on something original and interesting rather than grunt level coding. As many people have noted, low-level jobs are being outsourced rather rapidly. I consider it a very GOOD thing the MIT isn't wasting its student's time with what would appear to be a dead end skill set.
#2. If you want to bitch about MIT and ties to Microsoft there are much better areas to criticize. For example, the business school is a lock-down Microsoft shop. If you don't have a Microsoft OS, you can't get a digital certificate. If you can't get a digital certificate, you can't get access to anything from your home PC. I've heard a wide number of speculations about why this is so [the rest of the University has a much more liberal policies]. I've heard lots of talk that Sloan needs to maintain its own IT department to roll out like 802.11b quicker than the rest of the University. Of course those who like conspiracy theories do note that the Dean made a fair amount of money as a hired witness for MS during the anti-trust trials.
The pebble reactors achieve the same effect using a different design principle.
Each pebble is a sphere.
A large number of spheres are arranged in a pile.
The density of the uranium is a function of the radius of the spheres.
Like most things, the pebbles expand as they get hot.
In turn, this creates a negative feedback loop which should prevent a catostrophic failure.
1. Eliminating the header checksum makes it substantially easier to develop forwarding ASIC.
2. It was generally believed that the IPv6 header checksum doesn't provide all that much value. Suppose, for a moment, that the IP header became corrupted in some way. What's the worst thing that could happen? Eliminating the header checksum removes intelligence from the core and relocates it to end nodes [In this case, Intermediate systems no longer need to perform error detection. Instead, developers who require reliability can make use of existing fucntions build into the transport layer]
IPv6 improves upon IPv4 in a number of ways:
One of the principle design goals of IPv6 was to simplify the workload for routers. IPv6 achieves this in a number of ways:
1. Part of the reason that IP addresses are so long is that part of the address space is being used for an improved addressing hierarchy. In turn, this will allow routers to maintain much shorter routing tables.
2. IPv6 routers not longer fragment IP datagrams
3. IP Header checksums are been removed
As many people have noted, the IPv6 addressing structure supports a much larger number of IP addresses. Experts are predicting that the number of IP addresses required are going to increase enormously in a relatively short amount of time. Most people are familiar with cell phone adoption rates and the impact on IP address assignment. Potentially a more interesting example is the impact of new PC bus architectures on networking models. Intel has announced a new bus architecture titled PC-Express. What makes PC Expressing interesting is that it applies a data networking model to the PC bus. [Thinking addresses, flow control, retransmissions, etc] Where this gets interesting is that PC Express can be scaled from the level of a PC bus up to an enterprise class switching fabric. Once this gets widely deployed, there is no reason why the processor on one system could not control the video card on another. We are rapidly migrating to a model in which all sorts of peripherals - processors, sound cards, hard drives - will need to be configured with their own IP addresses.
IPv6 provides much better support for autoconfiguration. This is critically important for the consumer electronics manufacturers in the Asia/Pacific.
IPv6 requires IPSec, so we might finally get pervasive network layer security. I'll be very happy to get rid of abominations like "SSL VPNs".
There is a LOT of good stuff coming down the pike.
I found it extremely amusing that Verisign selected the CTO of Brightmail as part of the group doing the technical evaluation. Brightmail is an anti-SPAM vendor that is very heavily invested in signature based anti-SPAM systems.
While Site Finder broke a wide number of different systems on the Internet, crippling DNS based anti-SPAM probably had the greatest direct impact on the lives of end users.
From my perspective, I can't help but think that there might have been some kind of conflict of interest here.
It's interesting to notice the difference in focus between Craig Barrett's statements and the Slashdot's focus.
Barrett is an executive at Intel. His primary concern is whether the Chinese or the Indians will succeed with localizing microprocessor design. Needless to say, he is predisposed to believe that these efforts should not be undertaken.
Here on Slashdot, the primary focus is the various attempts taking place in Asia to standardize around Linux. From my own perspective, I don't think that this effort is logically equivalent to the Barrett's hardware example. I don't see the effort at promoting Linux as an attempt to fork the code base, but rather an effort to unify the development community around a single standard. With luck, this effort will result in better contributions to the core Linux code base.
This suggestion is badly flawed at multiple levels.
First and foremost, Russ Cooper's is suggesting that ISP's should be fined if they fail to block attacks that propagate across their networks. This proposal violates the basic end-to-end architectural principles on which the Internet was founded. Intelligence should be localized at the end node, supported by a "stupid" network infrastructure whose function is restricted to routing packets from point to point. "Smart" networks don't scale and they cost enormous amounts of money. Most individuals who are pushing these models are more concerned with supporting a business model rather than a viable technology. Consider what is necessary for Cooper's suggestion to work: Each ISP needs to preserve state on all the TCP connections emanating from a host to ensure that the host is not starting some kind of attack.
It might be possible to create a similar model assigning all liability to the computer owner: Joe Smith's decision to run an insecure system presents a potential threat to some class of computer users. Hence, this action could be considered to be actionable. Here once again, we have a logical fallacy: Suppose that Joe's computer is vulnerable to the XYZ worm. Joe's computer is compromised and used to launch the XYZ worm at other PCs on the Internet. However, the major group of people that are put at risk by Joe's vulnerability is the set of users who share this same vulnerability. In short, the class action lawsuit would be directed against the plaintiffs.
It is certainly possible to argue that compromised systems can be used to inconvenience Internet users in other ways. Case 1: A PC could be used as a Zombie in a distributed denial of service attack. Case 2: A PC could be used as a part of a SPAM generation network. Here, the "cost" of the attack is proportional to the amount of traffic being generated by the host. In theory, if you want to establish a linkage between fines and the cost of a system being compromised, the fine should be proportional to the amount of traffic being generated. I would argue that this would be better accomplished through a tarriffing system in which monthy access charges were proportional to traffic volume.
Ultimately, Cooper's proposal would require some kind of licensing system for operating systems. This is an incredibly ugly thought.
that was the beauty of the initial post
Droll way to tell someone to drop dead
"Spirited" discussion, indeed
There are some MAJOR issues with this suggestion. Most notably, the Longhorn Operating System is DRM enabled. This means that the OS/hardware is designed to block programmers from making a wide variety of direct calls to the hardware. Supposedly, this is intended to make is much more difficult to copy "Content", however, it also makes it much more difficult to write a small/efficient AV engine.
Microsoft will probably bundle an AV engine with Longhorn (supposedly, this is the main reason for Microsoft's GeCAD acquisition). It might be possible to develop an Open Source content distribution system to produce definition files for the engine, however, Microsoft might very well decide to block the interface to the engine. It will be interesting to see what happens.
I think that you fundamentally misunderstand why people dislike the "razor + razor blades" model. Razor + razor blades is an example of a modular design. This is normally considered to be a good thing.
Where the model is typically abused is the desire to apply cross subsidies between different modules. HP applies dramatic discounts to printers and attempts to make this money back by charging premiums on toner cartridges.
This inevitably triggers ugly battles with consumers. Vendors attempt to use proprietary interfaces to protect their revenue streams. Consumers look to third party suppliers.
For what its worth, I did some research on thsi subject last semester. From what I was able to determine, cross subsidies were a net loss for companies. Any financial gains that the companies hoped to generate were consumed by additional R+D/legal expenses to protect the interface. More critically, the desire to protect a cash cow significantly hurt the flexibility of the company. Polaroid became completely trapped by the need to protect the revenue stream from its film business that it was unable to adapt to digital photography.
As other people have pointed out, there are a number of different components to a comprehensive AV solution. The AV engine is certainly one important component, but "content" in the form of definition files and the speed/security with which this content is made available are equally important.
Ideally, companies should charge separately for both components.
I've started to wonder whether there might not be an inverse relationship between the rate at which a worm spreads and the type of payload that it carries.
If I have a worm that propagates relatively slowly, this may limit my ability to deploy a nasty payload. I need infected hosts up and running in order to infect other systems.
Contrast this with a "flash worm" which propagates at an enormously high rate of speed. After 15 minutes, almost all vulnerable hosts will be infected. No reason not to frag the system.
Many of the discussions taking place on this mailing list seem to be focusing on one part of this argument while ignoring a number other significant issues.
Case in point: Let us consider a production process in which output is a function of two factors of production. K = Capital and L = Labor. Globalization is creating new opportunities to outsource labor, which, in turn is causing the price of labor to fall. Simply put, wages are falling while returns to capital owners are increasing. In turn, everyone on Slashdot is obsessing where it is good or bad that jobs are being outsourced.
What is being neglected is that the government can (and some would argue) should intervene in the economy to smooth out the dislocations. The higher returns that are being generated by the capital owners can be taxed and used to provide income supplements and educational training to displaced workers. If the outsources is "pareto improving" income to capital owners can be increased without decreasing returns to labor, then go ahead and outsource away. If, however, outsourcing results in a net drain on the economy, things get a bit more dicey.
Where the current systems in the US are breaking down is the combination of massive outsourcing with increasingly regressive social policies. We are increasing the share allocated to capital at the same time that we are slashing taxes. In turn, this is dramatically skewing income distributions. Not a good combination.