Fair enough criticism; my comment was in the context of people designing systems like this, not the context of the actual user interface. Teergrube was a system designed a couple of years ago for trapping spammers and that essay is almost as well known as hashcash among the technical-solutions-to-spam crowd.
For the user interface to your mail clients, you'd have a friendly dialog box for "People who can send you mail for free" and another for "mailing lists I subscribe to". The "Mail from unknown users" dialog probably would give you something like checkboxes for "Make them do a copy-the-number Turing Test once" or "Turing test for every message" and/or "Make them run the 5/10/20 second hashcash page once/every message". The "Suspected Spammers" dialog could include "Drop their mail silently" and "try to trap them" and "trap them longer".
16-20 bytes of random characters for usernames are enough to kill of dictionary searches, and enough that you can give every recipient you care about a different address in your subdomain or tag field, so you can blow away addresses that get abused too much. Fastmail.fm has a nice approach of translating between username+tag@fastmail.fm and tag@username.fastmail.fm, which effectively gives you your own subdomain with lots of usernames in it.
So whitelist mail from IP addresses you trust, and do hashcash on unknowns, and do mild teergrubes on suspected spammers (don't even need to slow them down to zero, just pretty slow), and set your DNS to give open relays the email addresses of other open relays. Most legitimate mailing lists don't have more than a few thousand subscribers, many more like a few hundred, so a few seconds of hashcash won't kill them - but it's a lot more annoying to a spammer who's trying to send 90 million messages, while the hashcash makes this a slow enough process that he's bothered a lot fewer people before his ISP gets enough complaints and blows him away.
The obvious answer to "who gets paid" is "the recipient". Avoids lots of problems, and people who actually sign up to receive emails from lists can whitelist them, so the mailing lists don't have to pay.
If you don't have senders pay the right people, you won't succeed.
Sender Pays Sender's ISP - If only some senders charge, who's going to buy from them? Any mail-sending fees that are high enough to discourage spammers aren't cost-based, so it's easy for other players to undercut them.
Sender Pays Sender's ISP, all senders forced to participate - Not realistic, because you can't control the whole world, and if you try to reinvent the US local/long-distance telephone settlements process (which this basically is), you'll quickly find that non-cost-based charging rapidly leads to bad business decisions, big ugly bureaucracies, and variants on 1-809-number scams.
Sender Pays Recipient - that might work, because the real cost of spam isn't the ISP's cost of carrying it, it's the value of the reader's time, so it's harder to distort the market. You need a protocol that lets the recipient's MTA announce how much it'll cost the sender, and the sender decide whether to pay it before delivery. The recipients can whitelist the people they want to receive mail from (so mailing lists can work; if you don't whitelist the mailing list, you won't receive it), and can set high prices for known spammers.
That still won't solve all the problems - if you're a business, are you willing to enforce sender-pays on email from potential customers? Most businesses provide 1-800 numbers for phone calls, and in spite of rapidly declining phone prices, that still costs money. While accepting email free is cheaper than that, it still doesn't make spam go away for businesses or their employees.
So what do you do to help businesses reduce _their_ incoming spam load if they don't have recipient-pays to depend on? Another approach for discouraging spam is to give different email addresses to every recipient (e.g. 12345@john.doe.example.com for mail to John Doe or customer12345@example.com), and set up your web pages to autogenerate new addresses every time somebody wants one from your web page (e.g. sales-12321321@example.com, and reject any email that doesn't have the right checksum in the name or wasn't entered in the issued-addresses database.) I know at least one person who prints unique email addresses on every business card he hands out; if you're printing your own in small batches, might as well. If you do this right, it makes it much harder for the spammer, increasing by a factor of 1000-1000000 the number of messages the spammer has to send to get one message to an actual recipient. Some of these techniques work for individuals (or at least individuals who run their own sub-domain names), but it's easier to implement them on a business scale.
A large number of US internet users use AOL, which makes it easy to get N different "screen names" and use them for different things. The original intent was mostly to give your kids their own accounts, but people rapidly figured out that they can use different screen names for mail from their friends and relatives than for general public mail, or online shopping, or different IM groups, etc., and burn the ones that get abused too much. It's a good start. Similarly, lots of people use Yahoo/Hotmail/Etc. accounts as disposable addresses, giving those out to most non-close connections, and abandon the ones that get abused.
IMAP's pretty close to what you want, though maybe not exact. And of course NNTP does that too, though posting is normally open to the public; some mailer programs make the interfaces to mail and news look very similar. One problem is that if we moved to that kind of world, spammers would start subscribing to subscriber-only-posting mailing lists, just as they already like to send spam to non-closed mailing lists. It's a bit less efficient - the typical double-opt-in handshake is more work for programs to autorespond to, but there are only a few dozen popular mailing list management bot programs so they'll get scripted for, and spammers will start selling the scripts, and mailbots will start adding Turing tests, but spamware vendors will start using cheap offshore labor because they still get a recipients per list and can sell those subscriptions to spammer-wanabees suckers, and mailing lists will start adding karma for subscribed posters, vaguely like we have on Slashdot, and it may make it easier for you to read those high-volume unmoderated lists, but for small lists it'll suck anyway.
Sure we needed it then, though it was harder to get. Those days were smaller and more polite, but sometimes you wanted to comment on what your company was up to where you had a conflict of interest, or add an anonymous-coward comment to a flame war, or whatever. Eventually the first remailers showed up in places like alt.sexual-abuse.recovery, where people wanted to talk about things without their True Names attached, but before then the usual tools were forging headers or playing Stupid UUCP Tricks.
Oliver Wendell Holmes later said he regretted having used that phrase; it's been used to justify way too much censorship and evil.
However, that's not what spam is like. Spam is like yelling "BIG SALE" in a crowded theater, and if very many people do that, and other people start yelling "SHUT UP, SPAMMER", pretty soon you can't hear your movie.
Getting back to your issue, though, if theaters start responding by checking ID when you come in and when that's not enough, by making you leave your credit card with the ushers to insure your quietness in the theater, the whole business becomes too annoying for users to stick around for.
If you wanted to offer a sender-pays-money mailbox system to potential customers, you could do it today, without any cooperation from other ISPs, because you don't do the collection at the sender's ISP, you do it at the receiver's. You'd obviously need a payment system, whether it's Paypal or E-Gold or Visa or Rivest's new Peppercoin, and if it's not a convenient system then it'll be hard to get subscribers and get people to send them email, but that's just the rough learning curve on a system that (IMHO) people will hate anyway. Cooperation between ISPs becomes useful if you want to offer settlements systems so that ISPs can balance out pay-to-be-received fees and aggregate the transactions they make to the payment systems, and because by increasing the number of users of the same system, you might be able to get over the initial-adoption market hump faster (or at all.) But you don't need it.
Of course, once somebody's got a senders-pay-you-to-read-email system in place, spammers will immediately start advertising it as a Get Rich Quick Scam!
OK, so it _was_ a rant, but 99.44% of the buffer overflow bugs out there are fault of C programs that didn't do good bounds checking or botched up memory management. I'll disagree with you about C++ - it does count, but only if you don't treat it like C.
Don't get me wrong - I really like C. It has a cleanness and beauty to it matched by few languages other than (of course) LISP. But it's time for C to die, because letting you shoot yourself in the foot isn't safe in the kinds of multi-headed-hydra-centipedes that too many important programs have become; they've got too many feet to shoot themselves in, and any time they get shot they go berserk and trash half the net.
Extra shoot-in-foot options: My wife did APL professionally for a while: "Shoot all the bullets at all the feet, then pick out which feet are yours". Somebody's Neural Network: You train the network in how to shoot your foot, after which it generalizes and keeps trying to locate someone named Connor on the net..
If you've got something extra to protect the system, that's great too - I was just ranting about how we've had 15-20 years of experience with mail systems that don't need to be root and no good reasons to run as root. (There's also no good reason for the mail system owner to have a shell to exploit, unless there are buffer overflow bugs in/bin/false.)
When you're talking about SecureOS, are you referring to the stuff from Secure Computing Corporation, who did Sidewinder, or something different, like some of the work that became EROS?
Sendmail Inc. has good people, from Eric and Cat on down, and it's an extremely powerful product that's nowhere near as evil as MS Exchange, but the reason we get mad at it isn't just that it's a creeping horror out of the dark ages before time began (or at least you'd think that from reading the sendmail.cf documentation) but unlike grep and ping and the Unix-mentality set of small clean tools, it's a big monolith that's too big to clean up except by keeping the lessons learned and starting from scratch with a small modular replacement. Now, I'm going to stay out of the QMail-vs-whatever flamewars, and I won't claim that $ANOTHER_MAILER doesn't have holes, but at least it's possible to build things that are small enough to debug.
Look, how long have we known that running a mail system as root is dangerous, stupid, unnecessary, and avoidable? And how many times do we have to see root exploits in Sendmail before we get the hint? System III (predecessor to System V) was running email delivery as non-root, group-mail back in what, 1983? It just works, folks! The "let's make TCP/IP secure by making ports below 1024 root-only" strategy has its good points and its bad points, but if your operating system doesn't let you make exceptions for specific ports in the kernel, you can use a minimal wrapper for TCP services that opens port 25 and sets uid=mail, so it never processes any user input until it's Not Root.
Leave aside the issues of whether it's safe to run a massive program written in C with annually discovered buffer overflow exports, or the usual sendmail-basher fun about the need for Turing-machine-complete config files. If you don't want to get rooted, don't run stuff as root. Bad enough that it's possible to get rooted by non-privileged processes that leave trojans around where root can be tricked into running them, or use non-root processes to read files that maybe they shouldn't be reading (e.g. tricking a group-mail MTA into reading people's mailboxes.)
From an administrative viewpoint, there's not much difference between diskless workstations and X terminals - the main tradeoffs are hardware cost and CPU horsepower (since the diskless workstations can use their CPUs to do real work), plus you need to set up a bootp server or equivalent for the diskless. The important thing is to keep the file systems living on centralized file servers where you can do proper backups and redundancy, and keeping the operating systems all running a controlled common version, as opposed to the diskful-workstation model where everybody's got something slightly different. "Dataless" workstations are a variant where the computer has a disk that it can boot from and use for swap space, and maybe there's a limited amount of operating system kept there, but almost everything is still centralized so you've got version control. (Having said that, I'll also add that you need to pay more attention to LAN design and performance if you're running diskless workstations, because they get really unhappy on a shared Ethernet when somebody's dumping huge backups.)
Of course, all of this goes out the window if your users are mobile - diskless laptops are pretty boring:-) If you're in that environment, the obvious solution is to run Plan 9.
I was once interviewing at a friend's company, and as we were walking to his office, we went by some people who were trying to get their X terminal unconfused. He asked me how I'd address the problem, and it didn't take any think-time to answer "Power Switch". Boot time was one advantage of X terminals back then; diskless workstations took a few minutes to boot.
Kids these days. The misleadingness of the name was _deliberate_. Most of the coding on the early versions of Nethack was done at a highschool, which had typical "you're not supposed to play games on the school computer during class time" rules, and the name was meant to imply "Oh, no, sir, we're not playing games, we're hacking on the network, this isn't the gam3rz process you're looking for!"
Remember that praying too soon after the last time, or praying when your god is not happy with you, will not get your hunger fixed and will often annoy your god further. So keep track of when you pray.
Overture has abuse detectors on this to prevent robots from slamming their advertisers - you can hit them all once, but they do give you cookies, and I think they look at REFERER, so you want to enter those addresses in your browser yourself instead of clicking the link. If you want to hit them a few times, accept the cookies and clear them out in between.
New Jersey used to have barber's licenses, dating from when there were lots of Italian immigrants who'd gone into the business and wanted to cut down on the number of the next wave of immigrants competing with them. But about 15 years ago, those guys were all old, and the state decided not to issue any _new_ barber's licenses. Now if you want to go into the haircutting business, you need to get a cosmetologist's license, which requires a much longer study period for a much larger set of services.
And the black women's hair-braiding fashion requires a cosmetologist's license to practice - they've busted people for practicing without one.
Government licensing programs are an attempt by various groups to get the government to give their members a monopoly and interfere with their competition. Occasionally they're done with good intentions, but they're still offensive to a free society. Certification is a different matter - if I'm hiring someone to do something life-threatening or risky, I'd want a skilled professional to do it, and certifications by professional organizations can help me make that decision.
But governments aren't skilled professionals, they're organizations that threaten to use force on people who disobey them. That may be an appropriate thing to do for stopping rapists and murderers, but it's a highly inappropriate tool for society to use on unlicensed housepainters, or for people who want to operate businesses without paying protection money. Sometimes they're able to hire people who are competent enough to decide who should be licensed, but then sometimes they hire people like the bozos at the Patent Office. The classic argument for why they're necessary is licensing medical professionals - and while they _have_ driven lots of dangerous snake oil peddlers out of business, they've also radically raised the cost of medicine by limiting the supply of approved medical schools, thereby limiting the number of doctors allowed to practice, and by requiring many services to be done by full-scale doctors when a skilled nurse could do most of them just as well, and requiring that people get prescriptions from doctors to buy medicine when they're usually intelligent enough to make their own choices for most normal problems.
In this case, if the government wants to bust these guys for being a scam that's selling bogus services to the public, that would be perfectly reasonable, but instead they're threatening to bust them for not getting a state shingle on their wall.
"Hackers At Berkeley Find Security Hole in the Unix, a computer made by DEC". From the Oakland Tribune or some other Bay Area paper in spring 1979. Not an exact quote, but they did say the Unix was a computer made by DEC.
A long long time ago, on a uucp-net far, far, away, we didn't use terminal emulators, we used real hardware terminals. Most of them didn't run ANSI (I don't remember if the ANSI terminal standards were defined yet, but they looked very much like a DEC VT-100 terminal), but that meant there were lots of types of terminals, all trying to achieve market differentiation by having cool features or small size or large screens or cool plastic cases. Lots of different cool features means lots of vulnerabilities. The hackers in question had REDISCOVERED AN OLD TECHNIQUE - they found ways to hand escape sequences to VT100 terminals that would get the terminal to send arbitrary text back to the computer, which in those good old command-line days meant they could do anything they wanted. All you needed to do was email somebody a message with carefully crafted character strings in it, or use the talk program to write them to their terminal (back when everybody left their ttys writeable so talk would work.) Some of the popular techniques were to abuse programmable function keys (send a sequence to put some string in F1, then another sequence to auto-trigger the F1 key), or automatic whoami-responders (VT100 had one of these), or put the terminal into loopback testing mode (letting you type anything you want.)
The Hewlett-Packard HP2621 and its relatives had two easy things to do, which didn't let you send arbitrary characters but still hosed the user - one did a reboot on the terminal (and thereby dropped the connection), while the other put it into test pattern mode (sending a long string of UUUUUU to the computer.) There may have also been some block-mode things that let you send arbitrary characters to the computer, but these two were the easiest and best-documented. A couple years later, when I was a newbie learning Unix programming and security at Bell Labs, and Robert Morris Senior (father of RTM the Worm Author) was a department head for computer security (before he went to NSA), we'd had a discussion about some techniques I was trying (which he cracked through personally:-), and a few days later, when I'd patched those holes, I was playing rogue in the evening, and one of his people talked the test pattern sequence at me. For a few seconds, I though Umber Hulks were suddenly going to eat my character, but then realized I'd been hacked, and it was one of RTM's people following up on what I'd patched and what I hadn't...
Terminology note on "hacker" as opposed to "cracker" or "vandal" - The folks at Berkeley really were hacking - tinkering with things to find their limits - and while they could potentially use their knowledge for evil, they instead told people about it, which reminded lots of us to check for potential security holes in our systems.
So I should let my bank have eyeprints why? Someone else commented that you've only got one set (though actually you've got two, with most systems), but that once that data's leaked, it's leaked. That means that anybody who has access to the programming in an eyescanner or the backend database has a copy of that information, and you need to know everything they might do with it, legitimate or otherwise, and have some way to trust that that's all they'll do.
Here in the US, I know one thing they'll do with that data - the Feds will find some excuse to take any eyeprints that banks collect, maybe to track drugs or money-laundering or discrimination against the visually challenged or blue-eyed people, and they'll pop it into whatever they've renamed the Total Information Awareness office these days, from whence it will leak out to all sorts of police, bank instpectors, driver's license bureaucrats, etc. Europe pretends to have data protection laws that might help with this, except that most of the laws seem to have clauses about "unless the police need to know %s, of course."
At a very minimum, it's possible to design systems that don't pass a full-detail eyeprint, but do some sort of comparison that works with a much smaller subset of the eye data, with each application program collecting a different small section of the eyeprint for its applications. Even that's abusable, but it's not _as_ risky.
Most DNS queries get handled out of some kind of cache. While it's definitely important to be able to query your favorite root or alternate-root-like server when you really need to, you don't usually need to. If you ask your local vaguely-correctly-configured server for something, then ask it again before the expiration date, the first time it sees it it'l cache it, so the second time it can get it out of cache (unless the cache entry expired or the cache overflowed.) But if the entry's nonexistent, it's not likely to stick around the cache. So there's a need for a standard way to respond to well-known non-existent names, so the cache has something to keep for popular bogus queries. Obviously "localhost" is "127.0.0.1", and "example.com" can be just about anything not in use but might as well be 127.0.0.1, but it'd be nice if there were some other standard value to use. Maybe 127.0.0.0 or 127.255.255.255 (e.g. yell at yourself:-) ?
Yes, definitely, set your DHCP servers to tell clients about your company's DNS servers, and do a good job of maintaining your DNS serves so they work well. But sometimes people want to ask other servers what's going on, especially if they're trying to track down detailed authoritative information about a name from the real name servers for that name - or it they're spam hunting.
The root DNS servers shouldn't be bearing the bulk of the DNS load - the DNS servers at the Tier 1 ISPs (and also smaller ISPs, but especially Tier 1) should, and they should take care of many of the common queries, such as in-addr.arpa for the 192.168.*.*, 172.stuff.*.*, and 10.*.*.* domains, zone-transfer caching "." and ".com" so that those lookups don't need to hit the roots, etc. Also, while the Root Name Servers have a policy against accepting zone transfers from randoms, they really ought to have at least one server that either accepts zone transfers or at least some variant on FTP from registered addresses at the Tier 1 ISPs (The top ~25)and maybe at Tier 2 ISPs.
Also, the name servers get a surprising number of queries FROM RFC1918 addresses (10.x, 192.168.x, etc.), and while it may be more efficient to use root server CPU (on big fast computers) than router CPU to dispose of these queries, ISPs have ENTIRELY no business accepting IP packets FROM these addresses, and they should be killing them at the incoming edges of their networks, not carrying them and passing them on to other people.
Slashdot Mirror
For the user interface to your mail clients, you'd have a friendly dialog box for "People who can send you mail for free" and another for "mailing lists I subscribe to". The "Mail from unknown users" dialog probably would give you something like checkboxes for "Make them do a copy-the-number Turing Test once" or "Turing test for every message" and/or "Make them run the 5/10/20 second hashcash page once/every message". The "Suspected Spammers" dialog could include "Drop their mail silently" and "try to trap them" and "trap them longer".
16-20 bytes of random characters for usernames are enough to kill of dictionary searches, and enough that you can give every recipient you care about a different address in your subdomain or tag field, so you can blow away addresses that get abused too much. Fastmail.fm has a nice approach of translating between username+tag@fastmail.fm and tag@username.fastmail.fm, which effectively gives you your own subdomain with lots of usernames in it.
So whitelist mail from IP addresses you trust, and do hashcash on unknowns, and do mild teergrubes on suspected spammers (don't even need to slow them down to zero, just pretty slow), and set your DNS to give open relays the email addresses of other open relays. Most legitimate mailing lists don't have more than a few thousand subscribers, many more like a few hundred, so a few seconds of hashcash won't kill them - but it's a lot more annoying to a spammer who's trying to send 90 million messages, while the hashcash makes this a slow enough process that he's bothered a lot fewer people before his ISP gets enough complaints and blows him away.
The obvious answer to "who gets paid" is "the recipient". Avoids lots of problems, and people who actually sign up to receive emails from lists can whitelist them, so the mailing lists don't have to pay.
That still won't solve all the problems - if you're a business, are you willing to enforce sender-pays on email from potential customers? Most businesses provide 1-800 numbers for phone calls, and in spite of rapidly declining phone prices, that still costs money. While accepting email free is cheaper than that, it still doesn't make spam go away for businesses or their employees.
So what do you do to help businesses reduce _their_ incoming spam load if they don't have recipient-pays to depend on? Another approach for discouraging spam is to give different email addresses to every recipient (e.g. 12345@john.doe.example.com for mail to John Doe or customer12345@example.com), and set up your web pages to autogenerate new addresses every time somebody wants one from your web page (e.g. sales-12321321@example.com, and reject any email that doesn't have the right checksum in the name or wasn't entered in the issued-addresses database.) I know at least one person who prints unique email addresses on every business card he hands out; if you're printing your own in small batches, might as well. If you do this right, it makes it much harder for the spammer, increasing by a factor of 1000-1000000 the number of messages the spammer has to send to get one message to an actual recipient. Some of these techniques work for individuals (or at least individuals who run their own sub-domain names), but it's easier to implement them on a business scale.
A large number of US internet users use AOL, which makes it easy to get N different "screen names" and use them for different things. The original intent was mostly to give your kids their own accounts, but people rapidly figured out that they can use different screen names for mail from their friends and relatives than for general public mail, or online shopping, or different IM groups, etc., and burn the ones that get abused too much. It's a good start. Similarly, lots of people use Yahoo/Hotmail/Etc. accounts as disposable addresses, giving those out to most non-close connections, and abandon the ones that get abused.
IMAP's pretty close to what you want, though maybe not exact. And of course NNTP does that too, though posting is normally open to the public; some mailer programs make the interfaces to mail and news look very similar. One problem is that if we moved to that kind of world, spammers would start subscribing to subscriber-only-posting mailing lists, just as they already like to send spam to non-closed mailing lists. It's a bit less efficient - the typical double-opt-in handshake is more work for programs to autorespond to, but there are only a few dozen popular mailing list management bot programs so they'll get scripted for, and spammers will start selling the scripts, and mailbots will start adding Turing tests, but spamware vendors will start using cheap offshore labor because they still get a recipients per list and can sell those subscriptions to spammer-wanabees suckers, and mailing lists will start adding karma for subscribed posters, vaguely like we have on Slashdot, and it may make it easier for you to read those high-volume unmoderated lists, but for small lists it'll suck anyway.
Sure we needed it then, though it was harder to get. Those days were smaller and more polite, but sometimes you wanted to comment on what your company was up to where you had a conflict of interest, or add an anonymous-coward comment to a flame war, or whatever. Eventually the first remailers showed up in places like alt.sexual-abuse.recovery, where people wanted to talk about things without their True Names attached, but before then the usual tools were forging headers or playing Stupid UUCP Tricks.
However, that's not what spam is like. Spam is like yelling "BIG SALE" in a crowded theater, and if very many people do that, and other people start yelling "SHUT UP, SPAMMER", pretty soon you can't hear your movie.
Getting back to your issue, though, if theaters start responding by checking ID when you come in and when that's not enough, by making you leave your credit card with the ushers to insure your quietness in the theater, the whole business becomes too annoying for users to stick around for.
Of course, once somebody's got a senders-pay-you-to-read-email system in place, spammers will immediately start advertising it as a Get Rich Quick Scam!
Don't get me wrong - I really like C. It has a cleanness and beauty to it matched by few languages other than (of course) LISP. But it's time for C to die, because letting you shoot yourself in the foot isn't safe in the kinds of multi-headed-hydra-centipedes that too many important programs have become; they've got too many feet to shoot themselves in, and any time they get shot they go berserk and trash half the net.
Extra shoot-in-foot options: My wife did APL professionally for a while: "Shoot all the bullets at all the feet, then pick out which feet are yours". Somebody's Neural Network: You train the network in how to shoot your foot, after which it generalizes and keeps trying to locate someone named Connor on the net..
When you're talking about SecureOS, are you referring to the stuff from Secure Computing Corporation, who did Sidewinder, or something different, like some of the work that became EROS?
Sendmail Inc. has good people, from Eric and Cat on down, and it's an extremely powerful product that's nowhere near as evil as MS Exchange, but the reason we get mad at it isn't just that it's a creeping horror out of the dark ages before time began (or at least you'd think that from reading the sendmail.cf documentation) but unlike grep and ping and the Unix-mentality set of small clean tools, it's a big monolith that's too big to clean up except by keeping the lessons learned and starting from scratch with a small modular replacement. Now, I'm going to stay out of the QMail-vs-whatever flamewars, and I won't claim that $ANOTHER_MAILER doesn't have holes, but at least it's possible to build things that are small enough to debug.
Leave aside the issues of whether it's safe to run a massive program written in C with annually discovered buffer overflow exports, or the usual sendmail-basher fun about the need for Turing-machine-complete config files. If you don't want to get rooted, don't run stuff as root. Bad enough that it's possible to get rooted by non-privileged processes that leave trojans around where root can be tricked into running them, or use non-root processes to read files that maybe they shouldn't be reading (e.g. tricking a group-mail MTA into reading people's mailboxes.)
Of course, all of this goes out the window if your users are mobile - diskless laptops are pretty boring :-) If you're in that environment, the obvious solution is to run Plan 9.
I was once interviewing at a friend's company, and as we were walking to his office, we went by some people who were trying to get their X terminal unconfused. He asked me how I'd address the problem, and it didn't take any think-time to answer "Power Switch". Boot time was one advantage of X terminals back then; diskless workstations took a few minutes to boot.
Kids these days. The misleadingness of the name was _deliberate_. Most of the coding on the early versions of Nethack was done at a highschool, which had typical "you're not supposed to play games on the school computer during class time" rules, and the name was meant to imply "Oh, no, sir, we're not playing games, we're hacking on the network, this isn't the gam3rz process you're looking for!"
Remember that praying too soon after the last time, or praying when your god is not happy with you, will not get your hunger fixed and will often annoy your god further. So keep track of when you pray.
Overture has abuse detectors on this to prevent robots from slamming their advertisers
- you can hit them all once, but they do give you cookies, and I think they look at REFERER, so you want to enter those addresses in your browser yourself instead of clicking the link. If you want to hit them a few times, accept the cookies and clear them out in between.
And the black women's hair-braiding fashion requires a cosmetologist's license to practice - they've busted people for practicing without one.
But governments aren't skilled professionals, they're organizations that threaten to use force on people who disobey them. That may be an appropriate thing to do for stopping rapists and murderers, but it's a highly inappropriate tool for society to use on unlicensed housepainters, or for people who want to operate businesses without paying protection money. Sometimes they're able to hire people who are competent enough to decide who should be licensed, but then sometimes they hire people like the bozos at the Patent Office. The classic argument for why they're necessary is licensing medical professionals - and while they _have_ driven lots of dangerous snake oil peddlers out of business, they've also radically raised the cost of medicine by limiting the supply of approved medical schools, thereby limiting the number of doctors allowed to practice, and by requiring many services to be done by full-scale doctors when a skilled nurse could do most of them just as well, and requiring that people get prescriptions from doctors to buy medicine when they're usually intelligent enough to make their own choices for most normal problems.
In this case, if the government wants to bust these guys for being a scam that's selling bogus services to the public, that would be perfectly reasonable, but instead they're threatening to bust them for not getting a state shingle on their wall.
A long long time ago, on a uucp-net far, far, away, we didn't use terminal emulators, we used real hardware terminals. Most of them didn't run ANSI (I don't remember if the ANSI terminal standards were defined yet, but they looked very much like a DEC VT-100 terminal), but that meant there were lots of types of terminals, all trying to achieve market differentiation by having cool features or small size or large screens or cool plastic cases. Lots of different cool features means lots of vulnerabilities. The hackers in question had REDISCOVERED AN OLD TECHNIQUE - they found ways to hand escape sequences to VT100 terminals that would get the terminal to send arbitrary text back to the computer, which in those good old command-line days meant they could do anything they wanted. All you needed to do was email somebody a message with carefully crafted character strings in it, or use the talk program to write them to their terminal (back when everybody left their ttys writeable so talk would work.) Some of the popular techniques were to abuse programmable function keys (send a sequence to put some string in F1, then another sequence to auto-trigger the F1 key), or automatic whoami-responders (VT100 had one of these), or put the terminal into loopback testing mode (letting you type anything you want.)
The Hewlett-Packard HP2621 and its relatives had two easy things to do, which didn't let you send arbitrary characters but still hosed the user - one did a reboot on the terminal (and thereby dropped the connection), while the other put it into test pattern mode (sending a long string of UUUUUU to the computer.) There may have also been some block-mode things that let you send arbitrary characters to the computer, but these two were the easiest and best-documented. A couple years later, when I was a newbie learning Unix programming and security at Bell Labs, and Robert Morris Senior (father of RTM the Worm Author) was a department head for computer security (before he went to NSA), we'd had a discussion about some techniques I was trying (which he cracked through personally :-), and a few days later, when I'd patched those holes, I was playing rogue in the evening, and one of his people talked the test pattern sequence at me. For a few seconds, I though Umber Hulks were suddenly going to eat my character, but then realized I'd been hacked, and it was one of RTM's people following up on what I'd patched and what I hadn't...
Terminology note on "hacker" as opposed to "cracker" or "vandal" - The folks at Berkeley really were hacking - tinkering with things to find their limits - and while they could potentially use their knowledge for evil, they instead told people about it, which reminded lots of us to check for potential security holes in our systems.
Here in the US, I know one thing they'll do with that data - the Feds will find some excuse to take any eyeprints that banks collect, maybe to track drugs or money-laundering or discrimination against the visually challenged or blue-eyed people, and they'll pop it into whatever they've renamed the Total Information Awareness office these days, from whence it will leak out to all sorts of police, bank instpectors, driver's license bureaucrats, etc. Europe pretends to have data protection laws that might help with this, except that most of the laws seem to have clauses about "unless the police need to know %s, of course."
At a very minimum, it's possible to design systems that don't pass a full-detail eyeprint, but do some sort of comparison that works with a much smaller subset of the eye data, with each application program collecting a different small section of the eyeprint for its applications. Even that's abusable, but it's not _as_ risky.
Most DNS queries get handled out of some kind of cache. While it's definitely important to be able to query your favorite root or alternate-root-like server when you really need to, you don't usually need to. If you ask your local vaguely-correctly-configured server for something, then ask it again before the expiration date, the first time it sees it it'l cache it, so the second time it can get it out of cache (unless the cache entry expired or the cache overflowed.) But if the entry's nonexistent, it's not likely to stick around the cache. So there's a need for a standard way to respond to well-known non-existent names, so the cache has something to keep for popular bogus queries. Obviously "localhost" is "127.0.0.1", and "example.com" can be just about anything not in use but might as well be 127.0.0.1, but it'd be nice if there were some other standard value to use. Maybe 127.0.0.0 or 127.255.255.255 (e.g. yell at yourself :-) ?
Yes, definitely, set your DHCP servers to tell clients about your company's DNS servers, and do a good job of maintaining your DNS serves so they work well. But sometimes people want to ask other servers what's going on, especially if they're trying to track down detailed authoritative information about a name from the real name servers for that name - or it they're spam hunting.
Also, the name servers get a surprising number of queries FROM RFC1918 addresses (10.x, 192.168.x, etc.), and while it may be more efficient to use root server CPU (on big fast computers) than router CPU to dispose of these queries, ISPs have ENTIRELY no business accepting IP packets FROM these addresses, and they should be killing them at the incoming edges of their networks, not carrying them and passing them on to other people.