The fallacy of your risk assessment is exemplified by this statement: "If I don't see the semi-truck bearing down on me at 90mph, it won't run over me.". You generally won't know you're being exploited until you know the hole exists and go looking for evidence of someone exploiting it.
In the simplest model, segregated code and data with the stack in the data segment, you don't need API or ABI changes at all. You only have two segments, code and data, and whether a pointer is to code or data is always known at point of usage. Since the segment registers are already loaded properly, calls by methods that don't switch tasks don't need any modification and calls that do switch tasks (eg. call via a task gate) only need an implementation change to retrieve the DS value from the calling task, not an API/ABI change. Pointers remain 32 bits, segment overrides are never needed.
I think the fact that we are having to find ways to seperate code from data to avoid code injection via buffer overruns indicates that the idea behind segments, that is to seperate code from data so the two can't be confused, is in fact a good idea and that getting rid of that seperation was a bad idea.
Except that, as of the 286, segment descriptors do allow you to control the executable state of segments, so the MMU's lack of an execute bit on pages doesn't cause a problem. Shared libraries would be dealt with by the loader just as they are now, save that the loader would put code sections into the code segment and data sections into the data segment (just as it did with non-tiny-model programs in DOS).
As for why this won't work with Win32, it will. Back in the 16-bit days this was the standard way to do it. But when 32-bit came out on the x86 some bright soul decided that a flat, non-segmented memory model like the 68K had would be easier for programmers to work with (no more remembering whether your data was in a code segment or data segment), and segment support went away from the compilers and loader.
Is it even possible to do reliable location service on VoIP? It's kind of like cel: unless you have GPS built into the end-point device itself, there's simply no reliable way to determine where the end-point device is currently located. Even if you know it's IP address, there's no mapping between IP and geographic location.
Setting the data and stack segments non-executable does that without needing to watch CS:IP. If someone does muck with the return address on the stack, they're limited to return addresses only within code segments. If all code segments are non-writeable there's no way to inject arbitrary code into them and trying will generate an exception. No additional work needed for all of this, merely switching back to a non-flat model with seperate code, data and stack segments. For extra nasty points make code segments non-readable as well, then it's not possible to even copy the code out of them to look at it.
Note that the segment register in use doesn't matter, it's the setup in the segment descriptor pointed to by the segment register that counts. If you try to stuff a non-executable data segment in CS, you'll get an exception the first instruction you try to execute from it.
You could, if the code segment was marked readable and writable and if the data and stack segments were marked executable. If you marked the data and stack segments themselves non-executable, you could jump into them all you wanted with the segment descriptor loaded into any segment register you wanted and all you'd get is an exception thrown by the hardware.
That protection required a 286 or better, since the 8086 and 8088 used segment addresses directly instead of segment descriptors, but that just means that this has existed since the IBM PC/AT.
This existed in the 8086 and 8088 CPUs. You seperate your program into code, data and stack segments and load the appropriate segment registers. Code segments can't be read or written, data and stack segments can't be executed. But stupid programmers decided that that kept you from playing games with code-as-data and data-as-code, so they created flat addressing mode with all segment registers pointing at a single segment. Feh. Those who don't read history are doomed to repeat it. Badly.
I don't understand why Schmidt is saying that casual conversations are the only way the government gets information, nor why he seems to imply that the government has to coax them into giving up the information. There's another simple solution to the problem:
"If you are considered "critical infrastructure", failure to report security vulnerabilities to the appropriate agencies is a Federal crime punishable by a prison term of no less than 10 years for the managers responsible for the vulnerable systems and all executives who knew of the failure to report and failed to correct it. Interfering with the reporting process is punishable by a similar prison term for all persons responsible for the interference. Failure to correct the vulnerabilities when correction is possible, or to mitigate them to the greatest extent possible if they cannot be corrected, will result in the government immediately rearranging things so that you are no longer part of the "critical infrastructure"."
If we need to protect the critical infrastructure as much as the politicians say we do then I see no reason to treat the corps with kid gloves, and if we can tolerate those vulnerabilities not being fixed then obviously the threat to that infrastructure can't be that great now can it?
There's two problems. The first is practical: one "must give credit" clause doesn't sound too onerous, but what happens when all of the 800 contributors to a package all add "must give credit" clauses to their licenses? Now you have to have 800 individual credit lines somewhere, and you have to update that and reissue documentation every time a new person submits even a small bugfix. This adds up to a big headache very quickly.
The second is philosophical and legal. Much of the software linked to XFree86 libraries is under the GPL. The GPL is quite clear: nobody creating a work derived from a GPL'd work may ever, under any circumstances, add restrictions beyond what the GPL provides for. This is a good thing, it means that once a work is GPL'd nobody else can ever un-GPL it by a license term. It also means, though, that since the GPL doesn't provide for a "must give credit" clause, nobody may add such a clause to a work derived from a GPL'd work. The GPL considers the combination of a GPL'd program linked to a library to be a work derived from the GPL'd program regardless of the linking method, so if the library requires programs linked to it to follow a "must give credit" clause then the GPL rescinds your license to distribute the GPL'd portion of the work because you're trying to add a further restriction in violation of the GPL. The problem here for distributors is obvious.
Why isn't it fair to compare the two on established track record? Even assuming that closed source shipped more software than open source, open source software is used in more high-profile, high-value applications. If you could find or induce a compromise in the Linux kernel (as was attempted), the Debian distribution (as was attempted), the Apache webserver, the BIND DNS software, the sendmail mail server or any number of other packages, you'd have root access on an insanely large number of machines across the entire Internet. Despite that, all of the incidents of malicious binary insertion have occured in proprietary software. If screening for the two were even equal, surely we'd have had at least one successful attempt on open-source packages in the last 25 years or so? Yet we haven't.
Also, I work as a software developer. I know the processes the big companies use for source check-ins. I'm afraid that they're usually in too much of a hurry to get the bugs fixed and the software shipped to do major reviews of code check-ins on a regular basis. Normally those are only done when there's a large number of new bugs popping up, and they're aimed primarily at finding out if there's a fundamental code problem causing the bugs and not at finding malicious code. Mostly they depend on the developers to be professional, and the QA process to find bugs. The exceptions... tend not to be writing software for the mass market.
True, but with open source there's one major difference: that one compromised distribution isn't the only one out there. If one distribution is compromised, once it's detected people just get the same software from a different, uncompromised distributor. There's also the fact that people don't quickly adopt a new distribution, so if it's compromised from the start it'll be a relatively few people affected before word gets out and everyone else starts avoiding the compromised distributor.
I think screening in proprietary software is actually far worse than in open source. If closed source were so strict about screening, how would software companies ship viruses, trojans and back-doors on official copies? And that's happened not just once but repeatedly: I recall Wordperfect, Lotus and Microsoft off-hand all shipping viruses or trojans in shrink-wrapped products, and Borland had a major back-door embedded in a product for over a decade. Can you point to even a single equivalent occurrence in the open-source world?
Jones says a malicious entity could ship a version of an open-source project with malevolent code in it. Well yes, but the same can be said about closed-source software too. There's been a few recent well-publicized attempts to insert malicious code into open-source projects, but so far nobody's actually managed to get that code shipped to end-users as part of an official release. If Jones is correct, then closed-source should do at least as well. Yet, over the years, I recall several major pieces of software that shipped with back-doors or viruses on the official media. These weren't just third parties distributing bad versions, this was malware on the official versions bought directly from the software maker and still in their shrink-wrap with their seals intact. Microsoft themselves in the not too distant past shipped a fairly obnoxious trojan program to their own developers on their own SDK CDs.
Jones' assertion may be technically correct, but as with all of his assertions a simple check of the track record shows that it's closed-source, not open-source, that has the larger problem by far.
IBM won't drop it. Thing is, SCO's specific claims here don't just attack Linux, they attack IBM's use of those same technologies in IBM's mainframe and large-server business. IBM is not going to let an attack on the core of their business go undefended. And unfortunately for SCO, their whole case rests on the idea that the code involved is derived from SCO code by a very odd definition of "derived from". The judge isn't buying their definition, and IBM's one of the world's best when it comes to documenting the exact history of their code.
Far from settling, IBM's going to use this to deliver an example to the world of why you don't mess with Big Blue's legal department.
Except that the code that IBM wrote for AIX isn't SCO's property. Copyright law is clear: IBM wrote it, IBM owns the copyright on it. All SCO got from the contract with IBM was the right to use IBM's code in their Unix and redistribute it in their Unix. Absent the contract explicitly giving SCO ownership or an exclusive license (which it doesn't), IBM remains the owner of the code they wrote and they can license it to anyone else they want under any terms they want. They can't give away SCO's code or the combination of IBM and SCO code (at least without permission from SCO), but they can take what they wrote, with all traces of anyone else's code removed, and do with it as they wish.
What SCO's trying to claim is that, for example, because I loaned you my basketball for a game, I can't loan that basketball to anyone else without your permission. Which is obvious male bovine waste product.
Wouldn't the ISP have broken the contract at that point? Their action (or rather, inaction in failing to remove a spammer from their network) would at that point have caused massive disruption to your business. If you had a janitorial company that, because they didn't keep their trucks maintained and they were now all broke down, couldn't get anyone to your building to clean it, would you say "Well, we can't break our contract with them."? Or would you say "They're failing to perform as contracted and why they aren't isn't our problem, we've got overflowing trash cans we need emptied."?
So preempt the problem. Make it clear to your provider that if you see them getting noticed as a hoster to spammers and not responding to the problem, you'll begin moving your hosting elsewhere before they get listed and you won't look back. Make it clear to them that you consider this self-preservation, and that the only way they can guarantee you won't leave is to tell the spammers "No." up front and terminate any that do set up residence.
It'll still be just as much work to move, but you'll be able to do it in less of a rush. And maybe, just maybe, the hosting companies will start looking at all the customers who're saying the same thing and decide that no, the spammer's money isn't worth what taking it'll cost.
Perhaps, though, they should talk to the source of the problem instead of complaining about the solution. The problem, after all, isn't that SPEWS listed a spam source network, but that NAC.net is hosting spammers alongside it's legitimate customers. Those customers should make it clear to NAC.net that either the spammers go, NOW, or they'll take their hosting elsewhere, also now.
Of course he's talking about the advertisers. You have to understand the relationships here. He's the vendor. The advertisers are the customers. The ad is the means to deliver a product to his customers.
What's the product? The browsing audience, of course. However, I forsee a big problem for this whole idea, the same one that's hurting movies and television ratings: unlike conventional goods this product can walk away on it's own, and tell other bits of product to avoid the customer like the plague.
A blackhole Web server. It runs on a single IP on my LAN and returns a 404 code for any request.
A wildcard zone file for BIND that returns an A record pointing to the blackhole Web server's address for any name in whatever domain uses the file.
When I want to block a domain, I just add an entry to/etc/named.conf saying it's authoritative for that domain and the zonefile is the wildcard zone file. Presto, that domain no longer exists as far as my LAN is concerned. The only glitch I've found is sites like eBay that don't just display advertising, they actually do a redirect through the advertiser's site to get to the actual page. Blocking the advertiser's site blocks the original link.
Yes, this can be bypassed by hard-coding IP addresses in, but if that starts becoming common I'll respond by adding firewall rules that return appropriate ICMP errors for the netblocks involved.
And the neat thing is that, while it takes a techie to set something like this up the first time, copying that setup onto a new LAN is utterly trivial.
Except that with regular ballot machines we can know that the reason the vote didn't register was because the person didn't pull the handle. Here we can't trace back to figure out whether it was voter error or machine failure that caused the non-votes. And it leaves completely up in the air the question of, if the machines did fail to register some votes at all, did they incorrectly register some other votes? With traditional systems with an audit trail we'd just pull the ballots out and recount and resolve the ambiguities. With this system with no audit trail this whole incident is going to bring into focus the fundamental problem: in the event of questions you can't do a meaningful recount.
That condition comes from the licensing of civil engineers, too. You have to be licensed to be a civil engineer, pass some fairly effective exams and all that. You can be held personally and professionally liable for screw-ups in your designs. But there's another aspect: you have control. If you're the civil engineer on a project and you specify that it needs X grade of concrete, that's it. If management tries to say "That's too expensive, build it using a cheaper concrete.", you get to say "No can do." and they can't argue. If they do, you make a phone call and the next day some gentlemen with badges show up to discuss the fines and penalties management is going to pay. If management fires you and uses the cheaper concrete anyway, the discussion will be about criminal charges on top of their liability, not yours, for any damages done because of their illegal substitution.
If licensing of software engineers includes everything that licensing of civil engineers does, including the "those who don't have the license do not get to overrule you on how the job gets done" provisions, it's IMHO a good deal. We ought to press for exactly that in licensing, because while companies would be highly allergic to it it'll play very well with the public. Think about public reaction when a structural failure turns out to have been caused by someone substituting shoddy materials for what was originally specified or otherwise not doing things the way the engineers said to do them.
There are three code pieces that appear to be copied verbatim. The first is forty-two lines of packet handling code. Following the ip_vs_state_table variable is where most of the infringement takes place. Only the state transition handling seems to be original. The second is sixteen lines of VM allocation code. Five lines after CONFIG_DISCONTIGMEM, and eleven lines after VMALLOC_VMADDR. And the last is seven lines after SELFPOWER, USB specific power management code.
There's another possibility. SCO and Linux may both have legitimately copied that code from the original source when that source allowed it. In at least one case (involving memory-allocation code), the code SCO claimed was copied from them actually was legally copied from the original AT&T Unix code. SCO's code was identical because SCO also legally copied that same original code.
I wouldn't mess with an 802.11(a|b|g) router. I'd go with a basic access point and use a Linux or FreeBSD box for the router. You can run DHCP to hand out addresses, one of several Radius servers for authentication and accounting if you want to use individual accounts with passwords, and the rate-throttling features in the Linux/FreeBSD firewall to prevent hogging and lower the boom on the problem protocols (eg. SSH goes full-bore but the Kazaa ports are limited to 1K/sec).
For single-user manual configuration, it is. Now add that support for half a million users on 20+ incoming mailservers. Add per-user configuration files for it. Now add the database system and Web interface needed to allow users to add mailing lists to their personal whitelist. Then add the support systems and personnel to hand-hold users who aren't quite sure what an e-mail address is (because their mail client handles all that for them and just displays names) through the process of extracting the relevant information from raw RFC822 headers (which they've never seen before, because their mail client handles all that for them and just displays names and subject lines), inputting it into the Web form and correcting all the typos the users have introduced during the retyping.
The result isn't just non-trivial, it's a freakin' nightmare that'd send Freddy Kreuger running in terror if he ever had to face it. What works for one person on a Windows box doesn't scale up to ISP sizes.
Slashdot Mirror
The fallacy of your risk assessment is exemplified by this statement: "If I don't see the semi-truck bearing down on me at 90mph, it won't run over me.". You generally won't know you're being exploited until you know the hole exists and go looking for evidence of someone exploiting it.
In the simplest model, segregated code and data with the stack in the data segment, you don't need API or ABI changes at all. You only have two segments, code and data, and whether a pointer is to code or data is always known at point of usage. Since the segment registers are already loaded properly, calls by methods that don't switch tasks don't need any modification and calls that do switch tasks (eg. call via a task gate) only need an implementation change to retrieve the DS value from the calling task, not an API/ABI change. Pointers remain 32 bits, segment overrides are never needed.
I think the fact that we are having to find ways to seperate code from data to avoid code injection via buffer overruns indicates that the idea behind segments, that is to seperate code from data so the two can't be confused, is in fact a good idea and that getting rid of that seperation was a bad idea.
Except that, as of the 286, segment descriptors do allow you to control the executable state of segments, so the MMU's lack of an execute bit on pages doesn't cause a problem. Shared libraries would be dealt with by the loader just as they are now, save that the loader would put code sections into the code segment and data sections into the data segment (just as it did with non-tiny-model programs in DOS).
As for why this won't work with Win32, it will. Back in the 16-bit days this was the standard way to do it. But when 32-bit came out on the x86 some bright soul decided that a flat, non-segmented memory model like the 68K had would be easier for programmers to work with (no more remembering whether your data was in a code segment or data segment), and segment support went away from the compilers and loader.
Is it even possible to do reliable location service on VoIP? It's kind of like cel: unless you have GPS built into the end-point device itself, there's simply no reliable way to determine where the end-point device is currently located. Even if you know it's IP address, there's no mapping between IP and geographic location.
Setting the data and stack segments non-executable does that without needing to watch CS:IP. If someone does muck with the return address on the stack, they're limited to return addresses only within code segments. If all code segments are non-writeable there's no way to inject arbitrary code into them and trying will generate an exception. No additional work needed for all of this, merely switching back to a non-flat model with seperate code, data and stack segments. For extra nasty points make code segments non-readable as well, then it's not possible to even copy the code out of them to look at it.
Note that the segment register in use doesn't matter, it's the setup in the segment descriptor pointed to by the segment register that counts. If you try to stuff a non-executable data segment in CS, you'll get an exception the first instruction you try to execute from it.
You could, if the code segment was marked readable and writable and if the data and stack segments were marked executable. If you marked the data and stack segments themselves non-executable, you could jump into them all you wanted with the segment descriptor loaded into any segment register you wanted and all you'd get is an exception thrown by the hardware.
That protection required a 286 or better, since the 8086 and 8088 used segment addresses directly instead of segment descriptors, but that just means that this has existed since the IBM PC/AT.
This existed in the 8086 and 8088 CPUs. You seperate your program into code, data and stack segments and load the appropriate segment registers. Code segments can't be read or written, data and stack segments can't be executed. But stupid programmers decided that that kept you from playing games with code-as-data and data-as-code, so they created flat addressing mode with all segment registers pointing at a single segment. Feh. Those who don't read history are doomed to repeat it. Badly.
I don't understand why Schmidt is saying that casual conversations are the only way the government gets information, nor why he seems to imply that the government has to coax them into giving up the information. There's another simple solution to the problem:
"If you are considered "critical infrastructure", failure to report security vulnerabilities to the appropriate agencies is a Federal crime punishable by a prison term of no less than 10 years for the managers responsible for the vulnerable systems and all executives who knew of the failure to report and failed to correct it. Interfering with the reporting process is punishable by a similar prison term for all persons responsible for the interference. Failure to correct the vulnerabilities when correction is possible, or to mitigate them to the greatest extent possible if they cannot be corrected, will result in the government immediately rearranging things so that you are no longer part of the "critical infrastructure"."
If we need to protect the critical infrastructure as much as the politicians say we do then I see no reason to treat the corps with kid gloves, and if we can tolerate those vulnerabilities not being fixed then obviously the threat to that infrastructure can't be that great now can it?
There's two problems. The first is practical: one "must give credit" clause doesn't sound too onerous, but what happens when all of the 800 contributors to a package all add "must give credit" clauses to their licenses? Now you have to have 800 individual credit lines somewhere, and you have to update that and reissue documentation every time a new person submits even a small bugfix. This adds up to a big headache very quickly.
The second is philosophical and legal. Much of the software linked to XFree86 libraries is under the GPL. The GPL is quite clear: nobody creating a work derived from a GPL'd work may ever, under any circumstances, add restrictions beyond what the GPL provides for. This is a good thing, it means that once a work is GPL'd nobody else can ever un-GPL it by a license term. It also means, though, that since the GPL doesn't provide for a "must give credit" clause, nobody may add such a clause to a work derived from a GPL'd work. The GPL considers the combination of a GPL'd program linked to a library to be a work derived from the GPL'd program regardless of the linking method, so if the library requires programs linked to it to follow a "must give credit" clause then the GPL rescinds your license to distribute the GPL'd portion of the work because you're trying to add a further restriction in violation of the GPL. The problem here for distributors is obvious.
Why isn't it fair to compare the two on established track record? Even assuming that closed source shipped more software than open source, open source software is used in more high-profile, high-value applications. If you could find or induce a compromise in the Linux kernel (as was attempted), the Debian distribution (as was attempted), the Apache webserver, the BIND DNS software, the sendmail mail server or any number of other packages, you'd have root access on an insanely large number of machines across the entire Internet. Despite that, all of the incidents of malicious binary insertion have occured in proprietary software. If screening for the two were even equal, surely we'd have had at least one successful attempt on open-source packages in the last 25 years or so? Yet we haven't.
Also, I work as a software developer. I know the processes the big companies use for source check-ins. I'm afraid that they're usually in too much of a hurry to get the bugs fixed and the software shipped to do major reviews of code check-ins on a regular basis. Normally those are only done when there's a large number of new bugs popping up, and they're aimed primarily at finding out if there's a fundamental code problem causing the bugs and not at finding malicious code. Mostly they depend on the developers to be professional, and the QA process to find bugs. The exceptions... tend not to be writing software for the mass market.
True, but with open source there's one major difference: that one compromised distribution isn't the only one out there. If one distribution is compromised, once it's detected people just get the same software from a different, uncompromised distributor. There's also the fact that people don't quickly adopt a new distribution, so if it's compromised from the start it'll be a relatively few people affected before word gets out and everyone else starts avoiding the compromised distributor.
I think screening in proprietary software is actually far worse than in open source. If closed source were so strict about screening, how would software companies ship viruses, trojans and back-doors on official copies? And that's happened not just once but repeatedly: I recall Wordperfect, Lotus and Microsoft off-hand all shipping viruses or trojans in shrink-wrapped products, and Borland had a major back-door embedded in a product for over a decade. Can you point to even a single equivalent occurrence in the open-source world?
Jones says a malicious entity could ship a version of an open-source project with malevolent code in it. Well yes, but the same can be said about closed-source software too. There's been a few recent well-publicized attempts to insert malicious code into open-source projects, but so far nobody's actually managed to get that code shipped to end-users as part of an official release. If Jones is correct, then closed-source should do at least as well. Yet, over the years, I recall several major pieces of software that shipped with back-doors or viruses on the official media. These weren't just third parties distributing bad versions, this was malware on the official versions bought directly from the software maker and still in their shrink-wrap with their seals intact. Microsoft themselves in the not too distant past shipped a fairly obnoxious trojan program to their own developers on their own SDK CDs.
Jones' assertion may be technically correct, but as with all of his assertions a simple check of the track record shows that it's closed-source, not open-source, that has the larger problem by far.
IBM won't drop it. Thing is, SCO's specific claims here don't just attack Linux, they attack IBM's use of those same technologies in IBM's mainframe and large-server business. IBM is not going to let an attack on the core of their business go undefended. And unfortunately for SCO, their whole case rests on the idea that the code involved is derived from SCO code by a very odd definition of "derived from". The judge isn't buying their definition, and IBM's one of the world's best when it comes to documenting the exact history of their code.
Far from settling, IBM's going to use this to deliver an example to the world of why you don't mess with Big Blue's legal department.
Except that the code that IBM wrote for AIX isn't SCO's property. Copyright law is clear: IBM wrote it, IBM owns the copyright on it. All SCO got from the contract with IBM was the right to use IBM's code in their Unix and redistribute it in their Unix. Absent the contract explicitly giving SCO ownership or an exclusive license (which it doesn't), IBM remains the owner of the code they wrote and they can license it to anyone else they want under any terms they want. They can't give away SCO's code or the combination of IBM and SCO code (at least without permission from SCO), but they can take what they wrote, with all traces of anyone else's code removed, and do with it as they wish.
What SCO's trying to claim is that, for example, because I loaned you my basketball for a game, I can't loan that basketball to anyone else without your permission. Which is obvious male bovine waste product.
Wouldn't the ISP have broken the contract at that point? Their action (or rather, inaction in failing to remove a spammer from their network) would at that point have caused massive disruption to your business. If you had a janitorial company that, because they didn't keep their trucks maintained and they were now all broke down, couldn't get anyone to your building to clean it, would you say "Well, we can't break our contract with them."? Or would you say "They're failing to perform as contracted and why they aren't isn't our problem, we've got overflowing trash cans we need emptied."?
So preempt the problem. Make it clear to your provider that if you see them getting noticed as a hoster to spammers and not responding to the problem, you'll begin moving your hosting elsewhere before they get listed and you won't look back. Make it clear to them that you consider this self-preservation, and that the only way they can guarantee you won't leave is to tell the spammers "No." up front and terminate any that do set up residence.
It'll still be just as much work to move, but you'll be able to do it in less of a rush. And maybe, just maybe, the hosting companies will start looking at all the customers who're saying the same thing and decide that no, the spammer's money isn't worth what taking it'll cost.
Perhaps, though, they should talk to the source of the problem instead of complaining about the solution. The problem, after all, isn't that SPEWS listed a spam source network, but that NAC.net is hosting spammers alongside it's legitimate customers. Those customers should make it clear to NAC.net that either the spammers go, NOW, or they'll take their hosting elsewhere, also now.
Of course he's talking about the advertisers. You have to understand the relationships here. He's the vendor. The advertisers are the customers. The ad is the means to deliver a product to his customers.
What's the product? The browsing audience, of course. However, I forsee a big problem for this whole idea, the same one that's hurting movies and television ratings: unlike conventional goods this product can walk away on it's own, and tell other bits of product to avoid the customer like the plague.
I already do this. There's two components:
- A blackhole Web server. It runs on a single IP on my LAN and returns a 404 code for any request.
- A wildcard zone file for BIND that returns an A record pointing to the blackhole Web server's address for any name in whatever domain uses the file.
When I want to block a domain, I just add an entry toYes, this can be bypassed by hard-coding IP addresses in, but if that starts becoming common I'll respond by adding firewall rules that return appropriate ICMP errors for the netblocks involved.
And the neat thing is that, while it takes a techie to set something like this up the first time, copying that setup onto a new LAN is utterly trivial.
"But they can't choose us!"
Except that with regular ballot machines we can know that the reason the vote didn't register was because the person didn't pull the handle. Here we can't trace back to figure out whether it was voter error or machine failure that caused the non-votes. And it leaves completely up in the air the question of, if the machines did fail to register some votes at all, did they incorrectly register some other votes? With traditional systems with an audit trail we'd just pull the ballots out and recount and resolve the ambiguities. With this system with no audit trail this whole incident is going to bring into focus the fundamental problem: in the event of questions you can't do a meaningful recount.
That condition comes from the licensing of civil engineers, too. You have to be licensed to be a civil engineer, pass some fairly effective exams and all that. You can be held personally and professionally liable for screw-ups in your designs. But there's another aspect: you have control. If you're the civil engineer on a project and you specify that it needs X grade of concrete, that's it. If management tries to say "That's too expensive, build it using a cheaper concrete.", you get to say "No can do." and they can't argue. If they do, you make a phone call and the next day some gentlemen with badges show up to discuss the fines and penalties management is going to pay. If management fires you and uses the cheaper concrete anyway, the discussion will be about criminal charges on top of their liability, not yours, for any damages done because of their illegal substitution.
If licensing of software engineers includes everything that licensing of civil engineers does, including the "those who don't have the license do not get to overrule you on how the job gets done" provisions, it's IMHO a good deal. We ought to press for exactly that in licensing, because while companies would be highly allergic to it it'll play very well with the public. Think about public reaction when a structural failure turns out to have been caused by someone substituting shoddy materials for what was originally specified or otherwise not doing things the way the engineers said to do them.
There are three code pieces that appear to be copied verbatim. The first is forty-two lines of packet handling code. Following the ip_vs_state_table variable is where most of the infringement takes place. Only the state transition handling seems to be original. The second is sixteen lines of VM allocation code. Five lines after CONFIG_DISCONTIGMEM, and eleven lines after VMALLOC_VMADDR. And the last is seven lines after SELFPOWER, USB specific power management code.
There's another possibility. SCO and Linux may both have legitimately copied that code from the original source when that source allowed it. In at least one case (involving memory-allocation code), the code SCO claimed was copied from them actually was legally copied from the original AT&T Unix code. SCO's code was identical because SCO also legally copied that same original code.
I wouldn't mess with an 802.11(a|b|g) router. I'd go with a basic access point and use a Linux or FreeBSD box for the router. You can run DHCP to hand out addresses, one of several Radius servers for authentication and accounting if you want to use individual accounts with passwords, and the rate-throttling features in the Linux/FreeBSD firewall to prevent hogging and lower the boom on the problem protocols (eg. SSH goes full-bore but the Kazaa ports are limited to 1K/sec).
For single-user manual configuration, it is. Now add that support for half a million users on 20+ incoming mailservers. Add per-user configuration files for it. Now add the database system and Web interface needed to allow users to add mailing lists to their personal whitelist. Then add the support systems and personnel to hand-hold users who aren't quite sure what an e-mail address is (because their mail client handles all that for them and just displays names) through the process of extracting the relevant information from raw RFC822 headers (which they've never seen before, because their mail client handles all that for them and just displays names and subject lines), inputting it into the Web form and correcting all the typos the users have introduced during the retyping.
The result isn't just non-trivial, it's a freakin' nightmare that'd send Freddy Kreuger running in terror if he ever had to face it. What works for one person on a Windows box doesn't scale up to ISP sizes.