GPL is a license to give away Free Stuff in ways that make it stay Free. GPL isn't a license to give away things that aren't free that you don't own.
The BSD license says, roughly, that you can do lots of things with this code as long as you leave the University of California's copyright on it. Making a trivial change to it does not remove that license. The GPL says, roughly, that you can do anything you want with the code as long as you leave the GPL attached to it and let anybody get the source somewhere for free. That would mean that you _could_ remove the UoC's copyrights from the code, and you're not allowed to do that.
You can distribute your patches to BSD FooBariFizer under the GPL. You could bundle the Original BSD FooBariFizer code with your changes and add a GPL-like license that requires anybody who distributes binaries of the bundle to also distribute the source for free - but that doesn't stop them from hunting down an original copy of BSD FooBar and distributing it without your patches, and unless you're a very careful license-hacker, or make your license enough different from GPL, it also doesn't stop somebody from preparing their own derivative work (your bundle minus the BSD stuff) and distributing that with or without the original BSD FooBariFizer source.
If a customer's Port 80 web application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and the customer's application sends an HTTP:80 request to Sitefinder, and Sitefinder responds with a web search page, it's greedy and not correct, but mostly harmless and sometimes helpful.
If a customer's Port 443 Secure Web application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and the customer's application sends Sitefinder a request, it's potentially a serious security breach (though not usually, because usually the connection fails before anything important gets sent.)
If a customer's email application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and Sitefinder's email application rejects the connection, it's broken in ways that are mildly to seriously annoying.
And if some other application (even HTTP on port!=80) that Sitefinder doesn't support sends Verisign a DNS request, and Verisign responds with a pointer to Sitefinder, that's badly broken.
If Verisign can't tell the difference between the applications which it helps and the applications it breaks, which they can't, they'd better not go breaking things, and if they break them they should be fired.
I worked with AT&T's Multi-Level-Secure System V/MLS systems in the late 80s. Some details have changed since then (:-), but the basics are mostly the same. Most of the changes were in file and device access permissions and logging. The permissions features don't slow anything down significantly (except of course by stopping unapproved accesses altogether), and at the time, the logging functions were implemented very cleanly and rapidly, typically burning under 5% of horsepower (mostly disk access to save the very compact log entries.)
Some services are harder to set up, because the permission issues get in the way, especially if they expect to have an all-powerful root doing the work for them, or if the application does lots of work to secure themselves (chroot jails, etc.), but most applications aren't affected much. Anything that does much with Setuid() can expect a radically different environment underneath.
The big security win is that you can define different security compartments, including one or more for the operating system itself, and applications can only read from lower-security-level compartments, not write to them. This means that even if somebody finds an egregious buffer overflow bug in your email client, and uses it to mail your precious files to kgbvax.dhs.gov, they still can't use that to r00t your machine, and it's very hard for them to accomplish much by leaving Trojan Horse files around in your home directory because root usually isn't allowed to read them without you explicitly authorizing them.
Greenspan jacking up interest rates rapidly in early 2000, trashing any interest-rate-sensitive businesses. I find it hard to believe that this wasn't politically motivated. After the election he jacked it back down, but the damage was done.
The Microsoft Anti-Trust Suit - OK, you can blame the Clintonistas for this one. While it's popular in geekdom to dislike Microsoft, one of the most popular business models during the boom was "1. Start making something cool 2. Sell out to Cisco if it's hardware or Microsoft if it's software/services. 3. PROFIT", which provides an incentive for VCs to invest money in your company. When the anti-trust suit threatened to split Microsoft into pieces as well as gouging them for lots of money, that meant that selling out to Microsoft was nearly impossible for a couple of years, and the VCs got out of town.
OK, so DogFoodOnLine.com wasn't really the best business model:-) There was a lot of natural shakeout, partly because the market accumulated enough experience to understand what web advertising was worth (since selling eyeballs to advertiser was the core of too many business plans, but nobody really knew what they were worth at the beginning.)
Meanwhile, the current Republican-dominated Congress has entirely no sense of responsibility on spending. They're worse than the Reagan-era Democrats, who were doing classic Keynesian inflation, and they're keeping all the Clinton pork barrel and adding new military-industrial pork barrel. Clinton was able to get the Fed to cut interest rates early in his administration, so he covered his budgets by refinancing the Reagan/Bush national debt at low interest. Bush can't do that, and if he tries inflating it away like the Reagan Democrat Congresses did, we'll get absolutely killed in the global market.
SETI@HOME isn't on the Top500 list, because it's not running Linpack, but according to its stats page, it's been running at about 63 TeraFLOPS today, which is comfortably #1 on the list. So this should be fun...
The energy budget for shipping large numbers of people to Mars isn't realistic, even with beanstalks; colonizing it would be cool for lots of reasons, but it's not a solution for overpopulation. You could do better by taking that energy budget and using it to provide sufficient food and birth control for N people instead of evicting one person.
On the other hand, if we decide we're running out of dirt after we've filled up Siberia and the Sahara, colonizing the surface of the ocean is probably much more efficient than doing Antarctica. Among other things, you can do it in warm-climate areas, and you can do some of it in places that have enough energy and nutrient sources to grow food supplies; Antarctica's a tough place to do much hydroponic farming, and the Linux geeks won't let you eat all the penguins. It does require technology, since there are problems like riding out hurricanes and not getting your rafts broken up.
One reason that doctors cost so much in the US is the limited capacity of medical schools, which restricts the supply of doctors, and the immigration laws and medical licensing laws which make it somewhat hard for doctors to move here from other countries (though there are a lot that do). It does keep the quality high, but the supply is low, which means that doctors can and do charge more.
Nurses are a different market - schooling is widely available, and even though society is much less sexist than 30 years ago and women have more job choices besides nursing and teaching, there are still lots of nurses and their pay is quite low. That doesn't mean that hospitals and HMOs don't try to minimize the number of them they use, of course, but they aren't a big part of the cost base.
It's just machinery - learn!
on
Hack Your Car
·
· Score: 4, Interesting
You younger kids may not remember the days when "hacker" was a new term for the public (mostly used by news people to describe scary teenage computer vandals), but my analogy at the time was that computer hackers are really no different from the teenage kids who always used to hack on cars. Some are good kids trying to make their mom's old car keep running, and some are annoying punks who want to go fast, make lots of noise, drag-race on residential streets, and drive across your lawn.
You really can hack real stuff! Get your hands dirty, try things out, don't just spend all your time in front of a screen. Go to Burning Man, meet babes, do woodwork and risky art projects, try gardening, cook with ingredients you've never used before, make beer, spend time in the real world!
There are things you shouldn't do to cars unless you know what you're doing, and maybe that means taking an evening class in auto mechanics at some nearby high school. Brakes, for instance, are things that you should be really really sure about before doing anything other than looking at them or refilling fluids, and steering's kind of that way. If a car won't stop, that's bad, but if it won't go anywhere, that's not good, but at most it's usually just money and hassle. So don't be afraid of working on the engine. Of course, that was better advice back when I was in college, when cars had real parts like carbs and distributors instead of just computer controls, and the cars I could afford mostly needed to have their real parts tinkered with a lot to keep them happy. I never got really deeply into it, because I wasn't that good at it (:-), but it's still worth playing with a bit, just to know what's going on.
Reverse Engineered Without Documentation? So?
on
Hack Your Car
·
· Score: 1
OK, so the haX0red car codes are usually reverse engineered without documentation, but Real Programmers don't read anything but the machine code anyway....
Perhaps you can find the tables in the code, and tweak the various values in them, just like a previous generation of car hackers would tweak all the little knobs and screws on mechanical fuel and air systems, but without the benefit of the testing and experimentation and such that the OEM did, you're pretty much working in the dark as far as guessing the actual constraints. How far can you push it before it burns out, or goes to fast-black-smoke mode? How many scratch engines are you going to burn up to find out?
Car Recall was just a Firmware Upgrade
on
Hack Your Car
·
· Score: 1
Chrysler's hacking their own cars here... I've got a Chrysler PT Cruiser, one of the original models, and a year or so ago it was recalled. The main thing they did was a firmware upgrade - it has quite a bit more acceleration now, and doesn't seem to have bothered the gas mileage.
Saying they're "under the gun" implies that they were dragged their by a hostile FCC. This is largely Pulver trying to get the territory nailed down in a relatively friendly centralized manner, largely to block the kinds of problems that are happening in some states where the Public Utilities Commission has discovered that someone is doing something useful and profitable without their regulatory "help".
Yes, Google is a friendly robot and politely doesn't look at things that robots.txt ask it not to. Google has a strongly believed in corporate policy against being evil. Evil robots like KGBbot, Qaedabot, CIAbot, and 43000 spammer harvesters aren't friendly, and belong to Evil Empires, Evil peoples' associations, and greedy impolite people, so robots.txt doesn't work there. Spammers mostly ignore robots.txt, but people on your Enemies List can run their own crawlers that specifically look for things on *your* servers, and can target the locations listed in robots.txt (because they can get the rest of your site from Google, and probably do so to avoid having you notice them.)
So as N other people have said, if you put the information somewhere that your http server will hand it to anyone who asks for it, then you're handing it to anyone who asks for it, whether you were paying attention or not, so don't be stupid. Crypto is your friend, but don't think that it's enough - http://secretplans.army.mil/norobots,please/invasi ons/Cuba/October-2004.pgp is still leaking information even though nobody can read it.
Norobots.txt is a good place to put disinformation for harvesters, though - sugarplums for spam harvesters and intrusion detectors are the main uses for it. While norobots was partly motivated by the concern about information privacy, the other big motivation was slow web servers getting stomped all over by fast search engines. You really don't want Altavista and Google and Yahoo and 43000 spammers downloading your Linux ISO distributions to see if there are popular keywords or spammable email addresses in them. The big search engines were also polite enough to spread their load around rather than doing too much depth-first-search; some spammers also do that, usually to avoid getting detected.
On the other hand, using passwords, SSL, and client certs gives you some level of protection, but even then, the people who download your stuff may be careless about where they leave it, and Google's real security threat is finding stuff like that.
Sure, too many Americans are uptight about it, and half the rest are complaining that their Tivos couldn't zoom in far enough. But what channel was it on? If it's the BBC, they might get some uptight bureaucrat complaining to the person who said it that they had to answer 80 complaint letters, but nobody's going to lose their license over it or lose their advertising revenue.
It's also a change in the US, where since the recent unpleasantness, we've had a Government that pretends to be in favor of morality (at least with some amazingly twisted definition of morality that doesn't mind lying or killing people.) By contrast, ten years ago, the TV networks were forced to teach their newscasters to keep a straight face while saying "oral sex" on the prime-time news broadcasts....
Yes. This isn't the third DIFFERENT bug in ASN.1 discovered recently - this is the third set of applications using the SAME REFERENCE IMPLEMENTATION of ASN.1 that was discovered to be vulnerable once it was discovered that the reference implementation was buggy. SNMP and SSL got hit, then just recently H.323 got hit, and I don't know what Microsoft parts just got hit (but it wouldn't surprise me if it's Netmeeting and maybe IE.)
Why? Because ASN.1 is the Mos Eisley of bit-twiddly protocols, and "you'll never find a more wretched hive of scum and villainy." AFAIK, there's nothing insecure about the protocol itself, but it's so ugly that everybody tends to reuse the reference implementation rather than rewriting their own. While that has some good aspects to it, some of the original reference implementation code wasn't always careful about checking bounds, etc., and eventually the University of Oulu folks did a proper study and found the holes.
ASN.1 is one of these broad-scope protocols that tries to be everything to everybody, so it not only implements in a broad messy manner some things that were done much more simply and cleanly and debuggably in XDR, it also does some other things that are useful in a top-down hierarchical world controlled by all-knowing standards committees, and got itself included at the appropriate layers in other standards such as X.509 and H.323 (which are also big and ugly), and in SNMP (which is otherwise simple and clean and should have known better), and X.509 got itself embedded into SSL. (H.323 is the older VOIP standard, used by almost everybody even though they talk about using SIP Real Soon Now, and Microsoft Netmeeting is the popular free implementation.) One bad side of this is that very many security-critical applications have this buggy code at the bottom of them, though this is somewhat balanced by the good fact that it's so deeply buried that it's often hard to pass malicious data that far down the stack, though of course there's the ugly side which is that it's so ugly that it's hard for an interface module to verify that an ASN.1 object is malformed except by actually passing it to the vulnerable ASN.1 interpreter.
Bit-twiddly space-saving data formats are almost always a Bad Idea. As they say, people who play with the bits deserve to be bitten. ASN.1 problems make many applications hard to write and harder to debug, but in the Open Source world, PGP has gone through several iterations of security-critical bugs because they were trying to steal bits, plus backwards compatibility issues make stealth versions difficult. The theory is that it's somehow more "efficient" to save a few bits of data storage or data transmission time by using variable-length formats, trading off the space for more CPU time and program space. This isn't totally off the wall, given 20 years of Moore's Law (which seems to have improved CPU and RAM price/performance by 10**5 - 10**6, disk by about 10**5, but smaller bandwidths by only 10**3-10**4), but the cost in programmer time, debugging time, and bug impact has been immense.
If you want to have fun annoying spammers, one of the popular methods is to leave attractive-nuisance email addresses around on your web pages (or use CGI scripts that generate lots of these things.) If those addresses are at bogus domains, the spammers or the proxies or zombies they're abusing will do DNS queries, and if Verisign is giving them Sitefinder's IP address, they'll set up SMTP connections to Sitefinder's email-stub server instead of just dropping the connection. This makes it harder for the spamware to detect the trap and annoys Sitefinder.
A DDOSer who wanted to annoy Sitefinder could do random downloads from their site, and unless they've improved on the original Sitefinder, those downloads are 17KB of singing dancing Javascript instead of ~1KB of simple clean html text. If this has a big enough impact on Sitefinder's bandwidth cost, it will encourage them to provide simple clean html instead of their current potentially-dangerous dreck.
Here's how DNS and applications are supposed to interact for nonexistent sites:
If your web browser queries the DNS for nonexistent.com and DNS tells you that it doesn't exist, having the web browser do something friendly like try looking it up in a search engine is *technically clean*, and whether you view this as friendly hand-holding or a saccharine overdose is a matter of UI taste, and the fact that they default to using their own search engine is sensible if greedy (besides, you can change it.)
If your telnet/ssh/voip client queries DNS to find nonexistent.com, DNS tells your client it doesn't exist, and the client gives you some appropriate error message.
If your outbound SMTP server queries DNS for nonexxistent.com, DNS tells you it doesn't exist, and it sends an appropriate bouncegram to your mailbox saying the site doesn't exist, you realize you mistyped the address and resend.
If your inbound SMTP server gets a message claiming to be from nonexistent.com, and your server's spam-detection function checks DNS and DNS says it doesn't exist, your SMTP server can reject the mail saying "Go Away, Spammer".
That's not what Verisign is doing at all - if a domain name doesn't exist, they're sending you the IP address of a machine that has a web server and stub email server. That has different effects on different protocols, and all of Verisign's PR fluff about "Customers like it" addresses the friendly fuzzy web user interface, not the atrocious misbehaviour for email and other protocols:
Web browser sends DNS a query, DNS replies with Sitefinder's IP, Web browser sends HTTP to Sitefinder, Sitefinder sends 17KB of friendly dancing Javascript with several suggestions about which domain name you might have meant. It's not perfect (you looked for http://www.nonexistent.com/foo/bar/stuff.html, and Sitefinder is probably just pointing you to www.nonexistence.com and www.non-existent.com or something), not the full path), and it's Verisign's greed rather than Microsoft's or Google's, but it's sometimes better than nothing. GREEDY, ONLY PARTIALLY BROKEN
SSH client sends DNS a query, DNS replies with Sitefinder's IP, client tries to connect to Sitefinder Port 22, Sitefinder gives your client a login prompt, you don't know the password and don't realize you're not talking to h4rd2tyypeK0rr3xtly.com, Sitefinder gives your attempted IP address, timestamp, login and password to the Homeland Security Anti-Hacker Terrorism Police, you get hauled down to Gitmo Bay, they confiscate your PC, and if your lawyer ever gets you back home, your PC has been disassembled into little pieces. STILL EVIL AND BROKEN.
OtherApp client sends DNS a query, DNS replies with Sitefinder's IP, OtherApp client tries to connect to Sitefinder TCP Port 12345, Sitefinder sends a reject but thankfully doesn't call the police, and if OtherApp client has a user interface, it tells the user a message about having trouble connecting, rather than a correct message about the destination not existing. STILL EVIL AND BROKEN.
Outbound SMTP server sends DNS a request, DNS replies with Sitefinder's IP, SMTP connects with Sitefinder:25, Sitefinder SMTP says "We don't do SMTP here, go away" (or maybe some different failure message), and your SMTP server either sends your SMTP client a somewhat puzzling bouncegram, (and maybe you figure out it was just Sitefinder) or in the original implementation, your SMTP server figures it was a just a network glitch and keeps trying for a week, keeps giving you progress bouncegrams, eventually gives you a failure bouncegram.) LESS EVIL, BUT STILL BROKEN.
Inbound SMTP server receives a message purporting to be from nonexistent.com, first-spam-detector function queries DNS, DNS replies with Sitefinder's address, first-spam-detector decides it's ok to let inside the firewall, second-spam-detector burns CPU but doesn't recognize the random buzzwords as spam, recipient gets yet another spam or Outlook virus. STILL EVIL, STILL BROKEN, CAUSED MOST OF THE FLAMAGE.
Yes, the video quality and special effects improved. But they retitled ROTJ, and Jabba the Hutt, who in the original "Star Wars" was a fat guy, was replaced in "Episode 4: A New Hope" with the big worm from "Revenge of the Jedi".
OK, if the site can really pump a full 1 Gbps, that's ~600 simulateous feeds to people with T1 lines, but you'll still get almost as good performance cranking out Bittorrent feeds, and if you've got lots of excess capacity after that, ADSL users can still leach off of you. Additionally, it avoids the problem of interrupted downloads.
I'm not sure what torrent you're using, but I copied the http://debian.christian-leber.de/Knoppix34-ct.iso. torrent to my disk and fired it up, and it's been downloading just fine. Things were doggy at the beginning, but are by late evening it suddenly sped up and finished, and it's now seeing about 19 seeds.
I'm using the fancy experimental client that lets me regulate upload speeds and counts, so I've got it limited to 90% of my upload to avoid trashing other performance. Once it catches up and I've contributed my fair share of uploads, I'll probably switch over to the new Mandrake beta2 or something.
For a company/university/personal firewall, yes, it should usually be blocking any inbound traffic that's not understood. ISPs have a much different type of user base - they should be allowing the end-to-end Internet to work, staying open to any protocols that they don't have a very good reason to block. Temporarily blocking 3127 or 1434 or whatever is often necessary if there's a big outbreak, and there are some ISPs that restrict Port 25 because they're trying to prevent their users from spamming - but as a home Linux user, I find that rude and wouldn't use such an ISP for normal activities.
This isn't the kind of job you want to do virally - you can do it just as effectively with a standalone scanner and a separate payload that blocks the ports but doesn't go doing its own scanning. That way, sysadmins and ISPs who want to run it can run it, but it won't clog up their networks with exponentially exploding quantities of probes, and people can block 3127 at their firewalls and run the scanner inside, which is a much safer network load. Depending on how heavily infected your network is, scanning and blocking a few thousand machines doesn't take very long.
This scales particularly well for this application, because the big source of infections was Outlook, which is used in corporate email environments, so corporate firewalls are the right boundary. There's probably some amount of Outlook Express infection, which is a problem for consumer-oriented ISPs, but it's mostly a corporate problem. Also, running the thing as a sysadmin-controlled port scanner means that you can tailor the payload to pop up a dialog box saying "Hey, Stupid, You clicked on the MyDoom Virus and got yourself infected, call the Help Desk at 1-555-555-31337 to get your machine cleaned up"
Early articles had some speculation that it must have been written by the original author of Doomjuice. On the other hand, there are now two parasitic viruses out there (Doomjuice and Deadhat) taking over MyDoom-infected boxen, so it's probably easier than that security expert thought. And Deadhat (aka Vesser) kills off any anti-virus and firewall software it can find, leaving a properly encrypted backdoor for its own 0wner to use.
Unlike MyDoom, which is exploiting Microsoft weaknesses, the interesting thing about Doomjuice and Deadhat (aka Vesser) is that they're scanning for the back doors left by MyDoom.A and MyDoom.B and using them to take over. The good news is that they're only attacking infected machines (and in a way that's easy to block), but the bad news is that parasites like these can add nasty payloads to viruses that were fast but not particularly nasty themselves. (That doesn't mean that these parasites have done that, but they can.) According to the article on F-Secure, Vesser / Deadhat turns off many kinds of anti-virus and firewall software, leaving the machine more vulnerable, and adding a backdoor of its own (but protecting it with crypto, which is the proper thing for an evil virus to do:-)
We don't know what the simplest explanation _is_. God knows, since He built the place, so if he felt like starting simple and working his way up, fine.
But since we showed up after the heavy lifting got done, what we're stuck with is building the simplest explanation that looks like it'll work trying it out for a while, and finding out that, no, it doesn't do the job either, and adding more complexity or precision to one of the edges of the model, or developing new tools that help with problems we didn't know how to solve earlier. The Greeks were starting pretty much from scratch, building ugly kluges like Epicycles to account for the times their simple theories failed. Kepler and Copernicus eventually straightened that stuff out to the point that Newton could start over with gravity and Newtonian physics, which gave you some simple ways to solve the problems for medium-sized objects. That turned out not to do a good enough job for bigger objects (like stars' gravity bending light) or really small objects (anything where quantum effects matter), but it was enough of a start for people like Einstein and all the 20th century cosmologists to kick out from.
The Universe still seems to be a really messy complicated place, full of division by zero (black holes), round-off errors (much of quantum effects), and more parts missing than the socks that vanished in the dryer. If you want to see farther than your companions, you're going to either have to find some giants' shoulders to stand on, or go sneak around under the feet of dwarves and steal a glance at the real plans.
Slashdot Mirror
The BSD license says, roughly, that you can do lots of things with this code as long as you leave the University of California's copyright on it. Making a trivial change to it does not remove that license. The GPL says, roughly, that you can do anything you want with the code as long as you leave the GPL attached to it and let anybody get the source somewhere for free. That would mean that you _could_ remove the UoC's copyrights from the code, and you're not allowed to do that.
You can distribute your patches to BSD FooBariFizer under the GPL. You could bundle the Original BSD FooBariFizer code with your changes and add a GPL-like license that requires anybody who distributes binaries of the bundle to also distribute the source for free - but that doesn't stop them from hunting down an original copy of BSD FooBar and distributing it without your patches, and unless you're a very careful license-hacker, or make your license enough different from GPL, it also doesn't stop somebody from preparing their own derivative work (your bundle minus the BSD stuff) and distributing that with or without the original BSD FooBariFizer source.
- If a customer's Port 80 web application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and the customer's application sends an HTTP:80 request to Sitefinder, and Sitefinder responds with a web search page, it's greedy and not correct, but mostly harmless and sometimes helpful.
- If a customer's Port 443 Secure Web application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and the customer's application sends Sitefinder a request, it's potentially a serious security breach (though not usually, because usually the connection fails before anything important gets sent.)
- If a customer's email application sends Verisign a DNS request for a missing site, and Verisign responds with a pointer to Sitefinder, and Sitefinder's email application rejects the connection, it's broken in ways that are mildly to seriously annoying.
- And if some other application (even HTTP on port!=80) that Sitefinder doesn't support sends Verisign a DNS request, and Verisign responds with a pointer to Sitefinder, that's badly broken.
If Verisign can't tell the difference between the applications which it helps and the applications it breaks, which they can't, they'd better not go breaking things, and if they break them they should be fired.Some services are harder to set up, because the permission issues get in the way, especially if they expect to have an all-powerful root doing the work for them, or if the application does lots of work to secure themselves (chroot jails, etc.), but most applications aren't affected much. Anything that does much with Setuid() can expect a radically different environment underneath.
The big security win is that you can define different security compartments, including one or more for the operating system itself, and applications can only read from lower-security-level compartments, not write to them. This means that even if somebody finds an egregious buffer overflow bug in your email client, and uses it to mail your precious files to kgbvax.dhs.gov, they still can't use that to r00t your machine, and it's very hard for them to accomplish much by leaving Trojan Horse files around in your home directory because root usually isn't allowed to read them without you explicitly authorizing them.
Meanwhile, the current Republican-dominated Congress has entirely no sense of responsibility on spending. They're worse than the Reagan-era Democrats, who were doing classic Keynesian inflation, and they're keeping all the Clinton pork barrel and adding new military-industrial pork barrel. Clinton was able to get the Fed to cut interest rates early in his administration, so he covered his budgets by refinancing the Reagan/Bush national debt at low interest. Bush can't do that, and if he tries inflating it away like the Reagan Democrat Congresses did, we'll get absolutely killed in the global market.
SETI@HOME isn't on the Top500 list, because it's not running Linpack, but according to its stats page, it's been running at about 63 TeraFLOPS today, which is comfortably #1 on the list. So this should be fun...
On the other hand, if we decide we're running out of dirt after we've filled up Siberia and the Sahara, colonizing the surface of the ocean is probably much more efficient than doing Antarctica. Among other things, you can do it in warm-climate areas, and you can do some of it in places that have enough energy and nutrient sources to grow food supplies; Antarctica's a tough place to do much hydroponic farming, and the Linux geeks won't let you eat all the penguins. It does require technology, since there are problems like riding out hurricanes and not getting your rafts broken up.
Still, pretty scary stuff, if you live nearby.
Nurses are a different market - schooling is widely available, and even though society is much less sexist than 30 years ago and women have more job choices besides nursing and teaching, there are still lots of nurses and their pay is quite low. That doesn't mean that hospitals and HMOs don't try to minimize the number of them they use, of course, but they aren't a big part of the cost base.
You really can hack real stuff! Get your hands dirty, try things out, don't just spend all your time in front of a screen. Go to Burning Man, meet babes, do woodwork and risky art projects, try gardening, cook with ingredients you've never used before, make beer, spend time in the real world!
There are things you shouldn't do to cars unless you know what you're doing, and maybe that means taking an evening class in auto mechanics at some nearby high school. Brakes, for instance, are things that you should be really really sure about before doing anything other than looking at them or refilling fluids, and steering's kind of that way. If a car won't stop, that's bad, but if it won't go anywhere, that's not good, but at most it's usually just money and hassle. So don't be afraid of working on the engine. Of course, that was better advice back when I was in college, when cars had real parts like carbs and distributors instead of just computer controls, and the cars I could afford mostly needed to have their real parts tinkered with a lot to keep them happy. I never got really deeply into it, because I wasn't that good at it (:-), but it's still worth playing with a bit, just to know what's going on.
Perhaps you can find the tables in the code, and tweak the various values in them, just like a previous generation of car hackers would tweak all the little knobs and screws on mechanical fuel and air systems, but without the benefit of the testing and experimentation and such that the OEM did, you're pretty much working in the dark as far as guessing the actual constraints. How far can you push it before it burns out, or goes to fast-black-smoke mode? How many scratch engines are you going to burn up to find out?
Chrysler's hacking their own cars here... I've got a Chrysler PT Cruiser, one of the original models, and a year or so ago it was recalled. The main thing they did was a firmware upgrade - it has quite a bit more acceleration now, and doesn't seem to have bothered the gas mileage.
Saying they're "under the gun" implies that they were dragged their by a hostile FCC. This is largely Pulver trying to get the territory nailed down in a relatively friendly centralized manner, largely to block the kinds of problems that are happening in some states where the Public Utilities Commission has discovered that someone is doing something useful and profitable without their regulatory "help".
So as N other people have said, if you put the information somewhere that your http server will hand it to anyone who asks for it, then you're handing it to anyone who asks for it, whether you were paying attention or not, so don't be stupid. Crypto is your friend, but don't think that it's enough - http://secretplans.army.mil/norobots,please/invasi ons/Cuba/October-2004.pgp is still leaking information even though nobody can read it.
Norobots.txt is a good place to put disinformation for harvesters, though - sugarplums for spam harvesters and intrusion detectors are the main uses for it. While norobots was partly motivated by the concern about information privacy, the other big motivation was slow web servers getting stomped all over by fast search engines. You really don't want Altavista and Google and Yahoo and 43000 spammers downloading your Linux ISO distributions to see if there are popular keywords or spammable email addresses in them. The big search engines were also polite enough to spread their load around rather than doing too much depth-first-search; some spammers also do that, usually to avoid getting detected.
On the other hand, using passwords, SSL, and client certs gives you some level of protection, but even then, the people who download your stuff may be careless about where they leave it, and Google's real security threat is finding stuff like that.
It's also a change in the US, where since the recent unpleasantness, we've had a Government that pretends to be in favor of morality (at least with some amazingly twisted definition of morality that doesn't mind lying or killing people.) By contrast, ten years ago, the TV networks were forced to teach their newscasters to keep a straight face while saying "oral sex" on the prime-time news broadcasts....
Why? Because ASN.1 is the Mos Eisley of bit-twiddly protocols, and "you'll never find a more wretched hive of scum and villainy." AFAIK, there's nothing insecure about the protocol itself, but it's so ugly that everybody tends to reuse the reference implementation rather than rewriting their own. While that has some good aspects to it, some of the original reference implementation code wasn't always careful about checking bounds, etc., and eventually the University of Oulu folks did a proper study and found the holes.
ASN.1 is one of these broad-scope protocols that tries to be everything to everybody, so it not only implements in a broad messy manner some things that were done much more simply and cleanly and debuggably in XDR, it also does some other things that are useful in a top-down hierarchical world controlled by all-knowing standards committees, and got itself included at the appropriate layers in other standards such as X.509 and H.323 (which are also big and ugly), and in SNMP (which is otherwise simple and clean and should have known better), and X.509 got itself embedded into SSL. (H.323 is the older VOIP standard, used by almost everybody even though they talk about using SIP Real Soon Now, and Microsoft Netmeeting is the popular free implementation.) One bad side of this is that very many security-critical applications have this buggy code at the bottom of them, though this is somewhat balanced by the good fact that it's so deeply buried that it's often hard to pass malicious data that far down the stack, though of course there's the ugly side which is that it's so ugly that it's hard for an interface module to verify that an ASN.1 object is malformed except by actually passing it to the vulnerable ASN.1 interpreter.
Bit-twiddly space-saving data formats are almost always a Bad Idea. As they say, people who play with the bits deserve to be bitten. ASN.1 problems make many applications hard to write and harder to debug, but in the Open Source world, PGP has gone through several iterations of security-critical bugs because they were trying to steal bits, plus backwards compatibility issues make stealth versions difficult. The theory is that it's somehow more "efficient" to save a few bits of data storage or data transmission time by using variable-length formats, trading off the space for more CPU time and program space. This isn't totally off the wall, given 20 years of Moore's Law (which seems to have improved CPU and RAM price/performance by 10**5 - 10**6, disk by about 10**5, but smaller bandwidths by only 10**3-10**4), but the cost in programmer time, debugging time, and bug impact has been immense.
A DDOSer who wanted to annoy Sitefinder could do random downloads from their site, and unless they've improved on the original Sitefinder, those downloads are 17KB of singing dancing Javascript instead of ~1KB of simple clean html text. If this has a big enough impact on Sitefinder's bandwidth cost, it will encourage them to provide simple clean html instead of their current potentially-dangerous dreck.
That's not what Verisign is doing at all - if a domain name doesn't exist, they're sending you the IP address of a machine that has a web server and stub email server. That has different effects on different protocols, and all of Verisign's PR fluff about "Customers like it" addresses the friendly fuzzy web user interface, not the atrocious misbehaviour for email and other protocols:
Yes, the video quality and special effects improved. But they retitled ROTJ, and Jabba the Hutt, who in the original "Star Wars" was a fat guy, was replaced in "Episode 4: A New Hope" with the big worm from "Revenge of the Jedi".
OK, if the site can really pump a full 1 Gbps, that's ~600 simulateous feeds to people with T1 lines, but you'll still get almost as good performance cranking out Bittorrent feeds, and if you've got lots of excess capacity after that, ADSL users can still leach off of you. Additionally, it avoids the problem of interrupted downloads.
I'm using the fancy experimental client that lets me regulate upload speeds and counts, so I've got it limited to 90% of my upload to avoid trashing other performance. Once it catches up and I've contributed my fair share of uploads, I'll probably switch over to the new Mandrake beta2 or something.
For a company/university/personal firewall, yes, it should usually be blocking any inbound traffic that's not understood. ISPs have a much different type of user base - they should be allowing the end-to-end Internet to work, staying open to any protocols that they don't have a very good reason to block. Temporarily blocking 3127 or 1434 or whatever is often necessary if there's a big outbreak, and there are some ISPs that restrict Port 25 because they're trying to prevent their users from spamming - but as a home Linux user, I find that rude and wouldn't use such an ISP for normal activities.
This scales particularly well for this application, because the big source of infections was Outlook, which is used in corporate email environments, so corporate firewalls are the right boundary. There's probably some amount of Outlook Express infection, which is a problem for consumer-oriented ISPs, but it's mostly a corporate problem.
Also, running the thing as a sysadmin-controlled port scanner means that you can tailor the payload to pop up a dialog box saying "Hey, Stupid, You clicked on the MyDoom Virus and got yourself infected, call the Help Desk at 1-555-555-31337 to get your machine cleaned up"
Early articles had some speculation that it must have been written by the original author of Doomjuice. On the other hand, there are now two parasitic viruses out there (Doomjuice and Deadhat) taking over MyDoom-infected boxen, so it's probably easier than that security expert thought. And Deadhat (aka Vesser) kills off any anti-virus and firewall software it can find, leaving a properly encrypted backdoor for its own 0wner to use.
Unlike MyDoom, which is exploiting Microsoft weaknesses, the interesting thing about Doomjuice and Deadhat (aka Vesser) is that they're scanning for the back doors left by MyDoom.A and MyDoom.B and using them to take over. The good news is that they're only attacking infected machines (and in a way that's easy to block), but the bad news is that parasites like these can add nasty payloads to viruses that were fast but not particularly nasty themselves. (That doesn't mean that these parasites have done that, but they can.) According to the article on F-Secure, Vesser / Deadhat turns off many kinds of anti-virus and firewall software, leaving the machine more vulnerable, and adding a backdoor of its own (but protecting it with crypto, which is the proper thing for an evil virus to do :-)
But since we showed up after the heavy lifting got done, what we're stuck with is building the simplest explanation that looks like it'll work trying it out for a while, and finding out that, no, it doesn't do the job either, and adding more complexity or precision to one of the edges of the model, or developing new tools that help with problems we didn't know how to solve earlier. The Greeks were starting pretty much from scratch, building ugly kluges like Epicycles to account for the times their simple theories failed. Kepler and Copernicus eventually straightened that stuff out to the point that Newton could start over with gravity and Newtonian physics, which gave you some simple ways to solve the problems for medium-sized objects. That turned out not to do a good enough job for bigger objects (like stars' gravity bending light) or really small objects (anything where quantum effects matter), but it was enough of a start for people like Einstein and all the 20th century cosmologists to kick out from.
The Universe still seems to be a really messy complicated place, full of division by zero (black holes), round-off errors (much of quantum effects), and more parts missing than the socks that vanished in the dryer. If you want to see farther than your companions, you're going to either have to find some giants' shoulders to stand on, or go sneak around under the feet of dwarves and steal a glance at the real plans.