... which I suppose doesn't stop your recommendation from being appropriate.... or you could ask Martha instead.
(Most of us Stewarts are descended from Walter Fitzalan, third high Steward of Scotland, and/or from peasants on the land of various Stewart landlords (since Scots traditionally used somebody-son-of-somebody naming rather than inherited last names) or slaves of people named Stewart. I'm not aware of any close relationship between my family and Martha or Potter, but I do know bad decorating when I see it.)
My dad bought a Mac in ~86, upgraded it a few times, bought a new one in ~92 but they kept the old one around because some software never did port from System 6 to System 7. Dad died in ~98, and my mom's Mac repair guy retired a couple of years ago but occasionally helps out. They had to add some more memory (so the new printer would work consistently) and replace a graphics board and monitor, but otherwise it's still fine. The last time she moved the movers lost the external hard drive for the old Mac, but it was getting harder to find printer ribbons for its printer anyway.
My mother-in-law has AOL on a Windows box, and every couple of years we need to wipe the disk and reinstall from scratch because there's just too much crap to clean up. It's a bit safer running XP now (expletive deleted couldn't get the Win98 or WinME disks to read...) and it's an ugly mess, but she likes AOL for the content and for chatting with her friends. She saves all her stuff on AOL, and doesn't use the disk much, so the reinstall approach really is pretty clean. But it's much much more trouble.
That may have been true a long time ago, but even if it were true today it's not relevant. This system is powering an airship, so what matters is how much power you can get for a given weight limited by the available surface area of the airship and the weight of batteries you need for nighttime use.
Comparing the price and energy output of a solar cell on the ground to a coal-burner plant on the ground is one thing - comparing the amount of available lift you'd waste by storing coal on the airship and the amount of energy and money you'd expend carrying coal refills up to the airshift gives you a much different equation:-) There probably are better fuels for this application than coal, such as hydrogen or methane, but anything that requires refills is a loser, and you're not going to hang a 20-km garden hose out the bottom to do continuous refills either.
About once a year, Slashdot has a story about Yet Another Proposed Blimp/Aerostat/Etc. Communications Platform that some company is announcing they'll be deploying Real Soon Now and a different set of target altitude and bandwidth plans. And everybody says it'd be really cool to have that (because it really _would_), and then the thing fades into obscurity like last year's dot-com fad and is never heard from again. Too bad, especially for people like you out in Satellite-land, because geosynch latency is just too long.
This one might stick around, because the military often has radically different ideas of "useful" and "financially viable" and "other people's money" than the commercial world. However, I don't know how much of the difficulty with previous efforts has been the development cost of the aircraft (which is easier if the Feds force the taxpayers to subsidize it), versus the cost of deploying and operating it and the amount of revenue you can get from however many customers are within Line-of-Sight. It's easier to get enough customers with some of the proposals that fly at 50-70km instead of 20km, and of course it's easier to get enough customer density to be profitable if you're located over a big city where, ummm, everybody can get DSL and cable modems than over flyover farmland where they really want this.
On the other hand, the military has different failure scenarios to worry about. Battlefield applications have to worry about how long you can use them before they get shot down, so unmanned and high-altitude are good. But if they're really intending these things for ballistic missile defense, like the articles claim, as opposed to militarizing the Wars On Politically Incorrect Drugs or Mexican immigrants or augmenting Echelon or other illicit martial law activities, they've got to realize that any country that's technically sophisticated enough to launch an ICBM attack on the US can smuggle a few dozen SAMs into the country and blow these things out of the sky before launching The Big One. And the payload these platforms carry isn't big enough to add much counter-missile capability. It doesn't add up.
It's possible to do things with salt or cryptography that at least mean that each recipient of the list of hashes gets a different list, and that hashes take a little while to calculate, though Moore's Law makes that a short-term advantage only (like Unix password hashes.) But sure, you can run the names of a Million Usual Suspects through any standard hashing program pretty fast, and one name through extremely fast. If it takes a second per hash, then running those million names through it is two weeks of background load, and if the hash isn't artificially slowed down, it's more like 20 minutes for your Million Usual Suspects and under a week for All Living Americans.
And then there's the problem of extra data hidden in the hashes - some of the signature algorithms, for instance, can carry a bunch of hidden "subliminal" bits, like the one that says you're a Jew or black or Dues-Paying Republican or a Federal Agent or a Known Troublemaker.
Spelling is a real problem. I have enough trouble because my ancestors or their relatives were either illiterate or at least using names like "Stewart" "Stuart" "Steward" and "Steuart" before English spelling became relatively standardized. But Americans munging the names of people who use other alphabets, like Arabs, or who don't use alphabets at all, like Chinese, can't just use simple hashes, because any misspelling can either let somebody whose name is the same as a Real Suspect not get flagged, or let some non-suspect whose name is close to a Real Suspect get flagged, and any terrorist smarter than the Shoe-Bomber knows to use an alternative spelling of his name or get some fake ID. You probably know Chinese people who use different names in English and Chinese, either as immigrants or kids of immigrants; I knew a Hakka Chinese family from Vietnam who also had Vietnamese names, and in at least one of their languages, they had an alternate set of names for use within the family (approximately "Number One Son" etc.) And then there's the problem of exactly which name parts to use if you've got more than three, and nicknames, etc.
And then there's the problem of people whose names are the same as Real Suspects' names, and people who ever had their wallet stolen. Just spend a day in traffic court listening to DMV-screwed-up-and-I-got-arrested-by-mistake cases some time if you weren't already worried, or read any news article about identity theft.
Great. While there are definite positive privacy things they _could_ accomplish with this, it's also open to lots of possible problems like "The computer said you matched a terrorist's name, no we don't know why, or where the list came from, we just have to cancel your account and call the police on you" which are as hard to defend against as being on the "No-Fly List" of Americans whose rights to travel are arbitrarily and unconstitutionally limited, or the "Strip-Search-Before-Flying" list, or the "Hollywood Suspected Commies Blacklist".
Discovery, ESPN, etc. aren't *media* - they're *content*. Nothing about the content insists on being stuck in a copper wire. The medium here is Digital TV, and these guys are just buying airtime and content and selling advertising slots to pay for it, like any old-fashioned analog TV broadcaster does, or any infomercial vendor soaking up late-night UHF or cable TV timeslots.
The difference that digital TV makes is spectrum efficiency - the US HDTV standards can fit a digital HDTV signal in the same space as an analog TV channel, or they can use the same bitstream-over-radio to carry about four lower-resolution TV channels, using protocols that are uglier than you'd expect to multiplex them on the bitstream. The ugliness of the protocols reflects the ugliness of political process that led to the design, with the FCC, the existing broadcast TV license-holders, the big networks, the cable TV companies, and several competing hardware folks in on the deal. They sold it to the public as High Definition TV, but of course there's not too much content where HDTV matters (mostly sports and movies, but not most sitcoms or dramas or news or talk shows), so by the time the standards were mandatory, the broadcast license owners got to convert their analog stations to "Digital TV", which can use the bits for HDTV or lower resolution content, giving them multiple low-res channels instead of the one they used to have, which they can essentialy sublet out to other people if they don't want to package their own content for it.
The US FCC essentially nationalized the public's airwaves back in the 30s, along with the rest of the New Deal power grabs, and rents it back to big media companies or occasionally small well-behaved media companies in return for the ability to bully them around about content. Occasional gaps in the coverage have slipped by, allowing things like WiFi, but most of the spectrum is subject to political control, and that means of course that everybody lobbies the FCC.
There are two problems with BT on cable modems. One of them is that burning 100% of your upstream on P2P uploads kills TCP ACK performance and slows down everything, as well as hogging bandwidth you might have used for other applications - and most of the alternative BT clients let you limit the bandwidth to reduce this problem.
The other is more fundamental, which is that swarming protocols work because every peer is pumping out traffic, rather than only the central server, so on the average, you can only download at about the same as your upload rate unless there are generous users who are uploading for longer periods of time after they've finished their own downloads to make up for leeches like you who want to download 20 times as fast as their upstream bandwidth (or 3-10 times as fast, for us DSL users.) You can make that work a bit better by building BT clients that automate the process of handling multiple uploads of files you're finished downloading, but it's still fundamentally awkward. Asymmetry is basically lame stuff, more useful for couch potatoes than full peers, but it's what we've got at home.
Or you can cheat, like I sometimes do - use the 1 Mbps SDSL in the lab at work to download your Linux distros fast, and then FTP from there or burn them onto CDs in the morning:-) After all, that spare Pentium-133 wasn't doing anything else useful when you're not there to use it as a traffic generator for real projects, and it's also nice to the (pick-your-favorite-distro) community to leave it there seeding the recent distros overnight.
The Internet 2 project provides gimongous amounts of bandwidth between Major Research Universities in the US and Canada. If you've got a gigabit outbound connection and decent file sharing, you quickly run out of stuff to pirate:-) After all, Hollywood and Bollywood together don't put out more than a few movies per day, and they take about 5 minutes per DVD at those speeds - IF there's an application that can use the bandwidth effectively. Add in a hundred new audio CDs per day, and you're still done with piracy by 1am. The Internet2 front page currently references the Bittorrent article...
Bram worked for Mojo Nation (aka Evil Geniuses for a Better Tomorrow) during their brief cool existence burning up angel money, and BT grew out of some of the work he did there. One reason it's successful is that it's trying to solve one part of the problem well, rather than trying to solve All The Problems Of The World. Another spinoff is MNET, Zooko's project, which addresses different parts of the distributed file sharing space.
But now that some pieces have been done, putting them back together might make sense.
Unlike many of the P2P systems, BitTorrent isn't inherently good for piracy - it doesn't hide the publisher of the file or the participants in the distribution process. That doesn't mean it isn't usable for piracy, of course, but it doesn't do the obfuscation for you.
However, it's fairly good for letting universities and other fast-internal limited-external environments limit the amount of material they need to download from outside - and it's even better at letting them distribute software to the outside without burning infinite amounts of bandwidth, and serve files to internal users somewhat less server capacity, so it's a tool that makes sense for them to encourage.
There's still Research to be done in how to maximize clustering and localization of clients, so that most of the uploading and downloading stays within the fast LANs compared to the amount that uses the wide area network. BitTorrent has a certain amount of tuning in this direction that's driven by overall performance characteristics (obviously it makes sense to use fast links when you have them, but to do some balancing so that slow and isolated users get some content also and so rarer file segments get found if they're available), but most of the design work went into maximizing performance for the cloud as a whole and for end-users (more for non-leaching end-users) rather than for intermediate groupings of users.
Napster, while it was alive, did some work on this to avoid (ok, delay:-) getting thrown out of universities. Since it had centralized databases handling the indexing function, it was able to take identified groups of users and let them do most of their downloading within the group instead of outside. This was a Good Thing, particularly because Napster's client software (and therefore users) mainly knew peer performance by interface bandwidth, and sometimes by ping time, so they were more likely to grab a song from somebody on a 100 Mbps LAN, not knowing that there was an overloaded T1 in between until their ping times got ugly.
Sure, it's cute that it has a handle, and it's actually useful that you can plug in various flavors of compact flash etc (assuming that that feature works well and has a clueful user interface.)
But it didn't say whether paying 20000 yen let you avoid replacing ink cartridges every not-very-many pages, or whether the high price just means you can print more pages before you've spent more on overpriced ink than you spent on the printer, or even brag about how you can replace the cartridge without breaking a fingernail.
And it doesn't say whether plugging the USB interface into your PC Just Works or requires installing drivers that don't get along with your version of Windows and have badly-translated instructions (We get signal! Somebody set up us the printer! It's you! How are you, lady! All your ink are belong to us!)
Bah - the Laserjet II was for wimps! Give me an old Imagen printer with the liquid toner that they used before the new dry toners came out! It was based on a mid-80s Canon copier mechanism, and the toner looked like used motor oil, but was really more like kerosene with carbon black dissolved in it. If the gauge shows that you're a quart low, you fill it up, after first making sure it wasn't just gunked up and lying about how full it was (the stuff's really nasty to clean up if it overflows.) Then you get to clean your hands like a Real Mechanic if you dripped any. And you get aromatic 240-dpi fuzzy pictures out of it, after having fun negotiating with the protocols.
Greetings. Meesa am Jojo Binkasa, Nephew of late engineer JarJar Binks. Meesa Unkle hadsa 65,000,000 credits in the Jedi bank of Tatooine whensa badsa things happendsa, and meesa needsa to find off-planet correspondent to transfer the money to the alliance. Plleeesa Helpsa meesa! Yousa are Meesa's Only Hope! May the Forsa be with yousa!
OK, it's easier to fit one of those VIA EPIA boards in a jar, or PC104, but you can pick up a used Sparcstation at Weird Stuff or HalTed for under $100, so why not build yourself an attractive server?
The problem with the "Open Secret" approach isn't passive eavesdroppers cracking encryption - it's active Man-In-The-Middle attacks that trick one or both parties into setting up a "secure" connection to the attacker instead of their real destination, and then relaying data back and forth. DNS hacks and Stupid Router Tricks are typical ways to implement this.
SSH is vulnerable to it also, but it takes the approach of recording a key the first time it connects to a destination and then complaining loudly if the key changes. You could adapt that to the "Open Secret" model if you wanted, though IPSEC doesn't usually have a user interface that you can use to get the user's attention.
If you want decent security, you not only have to encrypt your interesting conversations, you have to encrypt your boring ones whenever possible, because otherwise the fact that you're having consistent encrypted conversations with a small number of people sticks out like pizza deliveries at the Pentagon.
Opportunistic Encryption does it mostly correctly, but not in a way that's very practical, because most people don't have control of their reverse DNS space and will therefore never deploy it. Also virtual hosting means that a given IP address can have lots of domain names behind it, and therefore potentially lots of different keys.
One alternative, "Open Secret", is to use a default preshared key that everybody knows, e.g. "Open Secret", so if you don't have anything better to use, you can still encrypt your conversations even though you're susceptible to Man-In-The-Middle attacks. The FreeSWAN crowd viewed that as too risky to bother adopting, even though it would have led to much better security for most users.
One of the interesting things at this year's RSA trade show was an RFID Blocker Tag that RSA Labs designed. It was recently discussed on Slashdot. You can read the above paper, but the summary is that it impersonates all 2**64 possible serial numbers, confusing the readers. (It basically answers "yes" when asked if the next bit is a 0 or if it's a 1. Mu!) So carry one in your wallet, and stick one in your luggage as well.
The paper describes fancier options, such as only impersonating numbers in some given range so that it only blocks reading some kinds of items, like the serial numbers on 100 Euro banknotes.
While I'm sure the TV/Disney/Newsmonger conglomerates would like to think that "content" is something that they provide for us and we consume like good little couch potatoes, the really cool thing about the Internet is that anybody in the world can talk to anybody else, express themselves to the public, and provide valuable or entertaining information to the world. So the sad result of the study is that half the users don't seem to get it yet... How can we drag them in?
Of course, that doesn't invalidate Donaldson's Commentary ("Sturgeon was an optimist"), and there's lots of content that's not very interesting, but at least we need to get kids in the habit of providing things that are interesting to their friends and thinking of what they can do for society as a whole.
Anon Coward has it just right (and also, it happens if you send mail to somebody@missspelled-domain.com). DNS doesn't know the application's ports or protocols, and doesn't have a way to for you to tell it. That means there's no way for a DNS server to do some things for some protocols and other things for other protocols, so it doesn't know when to tell you Sitefinder's address and when to tell you NO SUCH DOMAIN.
On the other hand, Sitefinder does know ports, so if Verisign DNS tells you Sitefinder's IP address, your application will try to talk to Sitefinder. It does something moderately correct if you send it an http request on port 80, and does something moderately broken if you send it an smtp request on port 25, and AFAIK it doesn't connect to any other port. (They could do an SSL-based search page on 443 if they wanted, and could also put their regular web server on popular alternative ports like 8000 and 8080 and their stubby email rejector on the alternative SMTP/SASL/SUBMIT ports.) (And I suppose I could nmap them to find out:-)
But they really ought to be "taken out and shot", because Verisign's activities break every Internet protocol except Port-80 HTTP, which clearly violates what ICANN should have hired them to do. (After all, DNS queries don't know what the application is that wants to know the IP address, or the TCP or UDP port or other protocol number that will be using it, much less understanding different database analysis hacks that might be reading DNS TLD info.)
Of course, ICANN is much more concerned with "Intellectual Property" than with that other boring definition of IP that those boring computer networking people use, so perhaps they haven't noticed.
MS is hardly the mother of all evil megacorps. Sure, they're aggressive purveyors of mostly unaesthetic software, but they're not even in the same league as
Krupp Arms
Dow Chemical, makers of napalm
Sandia Labs, developers of US nukes
The Chinese Military (who've become a bunch of megacorps)
Makers of military aircraft and intercontinental ballistic missiles.
Acxiom, the privacy-invading database purveyors whose pet lobbyist, Gen. Wesley Clark, was trying to get them a contract for CAPPS II from Dick Cheney
Nestle', whose baby formula dealers have been endangering the health of third-world children for decades
Of course it was written by marketdroids:-). But really, to call Sendmail "long-suffering" is to ignore ~20 years of history. It's a horrendously complex system that's had scads of major security holes since before the Morris Worm of 1988 and has a config file format that can be used to implement Turing machines. That doesn't mean that they don't try hard to fix problems, or that they aren't providing an industrial-strength product (for instance, compared to MS Exchange), but even big iron locomotives can have train wrecks.
Many of sendmail's problems are related to building an extremely general purpose mail forwarder that had to on the Unix of the mid-1980s, support _all_ the popular email protocols of the time (including relaying between UUCP, BITNET, and many other non-TCP/IP things) and providing end-user mail receiving and mail sending services on time-sharing machines, as opposed to running in a dedicated environment with a simpler set of features. On the other hand, the AT&T Bell Labs Research UPAS mailers that became SVR4's mailer was just about as powerful but much smaller, cleaner, and more modular, and even under System III, the mail delivery software didn't need to run as root, so it wasn't the same horrendous security hole.
Microsoft-bashing isn't appropriate here either. Sure, the Exchange MTA and Outlook clients have appalling security and reliability records and used to be pretty much the Mos Eisley of security nightmares, but these aren't the security problems you're looking for. This is about addressing the security problems that are inherent in SMTP when you implement it _correctly_, which allows the mailer to receive all kinds of mail that makes fraudulent, bogus, distracting, or otherwise inappropriate claims about its origin that gives the naive recipient no way to hunt down and kill the evil time-wasting perpetrator (or makes it easy for the naive recipient to hunt down and kill the often-innocent bystander whose name was forged, whether the naive recipient is a human or a mailbot.) The problems have a lot of synergy - the lack of even cursory sender validation makes email an attractive nuisance when delivered to the naive recipient, who can be trusted to click on the happy shiny icon promising a display of dancing pigs (especially since Outlook is friendly enough to hide the ugly details from the user), triggering all the appalling things that can happen when you tell Outlook to trust a message it just received. This work is fundamentally about interfaces and scalability, and Sendmail Inc. is the right group for Microsoft to work with.
The details of the system seem a bit baroque to me, but you knew it was XML within the first couple of paragraphs, and it said Microsoft in the first half-sentence. It's not as lean and mean as LMAP and it has broader goals than SPF (which was originally about joe-jobs, and has suffered from some limitations as its scope has expanded.) And it's not going to solve the entire problem, because nothing short of a worldwide moral transformation or the extinction of the species is going to eliminate human greed and gullibility, but that's ok - even if it only eliminates _half_ the spam, that'll buy us another year of being able to keep reading email, plus it will annoy the spammers out there.
Of course, the continuing success of viruses that depend on the naive recipient pressing the button to watch the dancing pigs means that if SPF/LMAP/RMX/etc becomes widespread, we'll see more exploitation of Mail User Agent bugs that send out spam pretending to be from the naive user (or coworkers of the naive user), and then you can go back to bashing Microsoft while the Enemy continues their side of the arms race.
Slashdot Mirror
(Most of us Stewarts are descended from Walter Fitzalan, third high Steward of Scotland, and/or from peasants on the land of various Stewart landlords (since Scots traditionally used somebody-son-of-somebody naming rather than inherited last names) or slaves of people named Stewart. I'm not aware of any close relationship between my family and Martha or Potter, but I do know bad decorating when I see it.)
"Stupid is as stupid does"
My mother-in-law has AOL on a Windows box, and every couple of years we need to wipe the disk and reinstall from scratch because there's just too much crap to clean up. It's a bit safer running XP now (expletive deleted couldn't get the Win98 or WinME disks to read...) and it's an ugly mess, but she likes AOL for the content and for chatting with her friends. She saves all her stuff on AOL, and doesn't use the disk much, so the reinstall approach really is pretty clean. But it's much much more trouble.
Comparing the price and energy output of a solar cell on the ground to a coal-burner plant on the ground is one thing - comparing the amount of available lift you'd waste by storing coal on the airship and the amount of energy and money you'd expend carrying coal refills up to the airshift gives you a much different equation :-) There probably are better fuels for this application than coal, such as hydrogen or methane, but anything that requires refills is a loser, and you're not going to hang a 20-km garden hose out the bottom to do continuous refills either.
This one might stick around, because the military often has radically different ideas of "useful" and "financially viable" and "other people's money" than the commercial world. However, I don't know how much of the difficulty with previous efforts has been the development cost of the aircraft (which is easier if the Feds force the taxpayers to subsidize it), versus the cost of deploying and operating it and the amount of revenue you can get from however many customers are within Line-of-Sight. It's easier to get enough customers with some of the proposals that fly at 50-70km instead of 20km, and of course it's easier to get enough customer density to be profitable if you're located over a big city where, ummm, everybody can get DSL and cable modems than over flyover farmland where they really want this.
On the other hand, the military has different failure scenarios to worry about. Battlefield applications have to worry about how long you can use them before they get shot down, so unmanned and high-altitude are good. But if they're really intending these things for ballistic missile defense, like the articles claim, as opposed to militarizing the Wars On Politically Incorrect Drugs or Mexican immigrants or augmenting Echelon or other illicit martial law activities, they've got to realize that any country that's technically sophisticated enough to launch an ICBM attack on the US can smuggle a few dozen SAMs into the country and blow these things out of the sky before launching The Big One. And the payload these platforms carry isn't big enough to add much counter-missile capability. It doesn't add up.
A m00se byted my sister once...
.
Sorry, but somebody had to say it. I'[ll go mod myself down now...
And then there's the problem of extra data hidden in the hashes - some of the signature algorithms, for instance, can carry a bunch of hidden "subliminal" bits, like the one that says you're a Jew or black or Dues-Paying Republican or a Federal Agent or a Known Troublemaker.
Spelling is a real problem. I have enough trouble because my ancestors or their relatives were either illiterate or at least using names like "Stewart" "Stuart" "Steward" and "Steuart" before English spelling became relatively standardized. But Americans munging the names of people who use other alphabets, like Arabs, or who don't use alphabets at all, like Chinese, can't just use simple hashes, because any misspelling can either let somebody whose name is the same as a Real Suspect not get flagged, or let some non-suspect whose name is close to a Real Suspect get flagged, and any terrorist smarter than the Shoe-Bomber knows to use an alternative spelling of his name or get some fake ID. You probably know Chinese people who use different names in English and Chinese, either as immigrants or kids of immigrants; I knew a Hakka Chinese family from Vietnam who also had Vietnamese names, and in at least one of their languages, they had an alternate set of names for use within the family (approximately "Number One Son" etc.) And then there's the problem of exactly which name parts to use if you've got more than three, and nicknames, etc.
And then there's the problem of people whose names are the same as Real Suspects' names, and people who ever had their wallet stolen. Just spend a day in traffic court listening to DMV-screwed-up-and-I-got-arrested-by-mistake cases some time if you weren't already worried, or read any news article about identity theft.
Great. While there are definite positive privacy things they _could_ accomplish with this, it's also open to lots of possible problems like "The computer said you matched a terrorist's name, no we don't know why, or where the list came from, we just have to cancel your account and call the police on you" which are as hard to defend against as being on the "No-Fly List" of Americans whose rights to travel are arbitrarily and unconstitutionally limited, or the "Strip-Search-Before-Flying" list, or the "Hollywood Suspected Commies Blacklist".
The difference that digital TV makes is spectrum efficiency - the US HDTV standards can fit a digital HDTV signal in the same space as an analog TV channel, or they can use the same bitstream-over-radio to carry about four lower-resolution TV channels, using protocols that are uglier than you'd expect to multiplex them on the bitstream. The ugliness of the protocols reflects the ugliness of political process that led to the design, with the FCC, the existing broadcast TV license-holders, the big networks, the cable TV companies, and several competing hardware folks in on the deal. They sold it to the public as High Definition TV, but of course there's not too much content where HDTV matters (mostly sports and movies, but not most sitcoms or dramas or news or talk shows), so by the time the standards were mandatory, the broadcast license owners got to convert their analog stations to "Digital TV", which can use the bits for HDTV or lower resolution content, giving them multiple low-res channels instead of the one they used to have, which they can essentialy sublet out to other people if they don't want to package their own content for it.
The US FCC essentially nationalized the public's airwaves back in the 30s, along with the rest of the New Deal power grabs, and rents it back to big media companies or occasionally small well-behaved media companies in return for the ability to bully them around about content. Occasional gaps in the coverage have slipped by, allowing things like WiFi, but most of the spectrum is subject to political control, and that means of course that everybody lobbies the FCC.
The other is more fundamental, which is that swarming protocols work because every peer is pumping out traffic, rather than only the central server, so on the average, you can only download at about the same as your upload rate unless there are generous users who are uploading for longer periods of time after they've finished their own downloads to make up for leeches like you who want to download 20 times as fast as their upstream bandwidth (or 3-10 times as fast, for us DSL users.) You can make that work a bit better by building BT clients that automate the process of handling multiple uploads of files you're finished downloading, but it's still fundamentally awkward. Asymmetry is basically lame stuff, more useful for couch potatoes than full peers, but it's what we've got at home.
Or you can cheat, like I sometimes do - use the 1 Mbps SDSL in the lab at work to download your Linux distros fast, and then FTP from there or burn them onto CDs in the morning :-) After all, that spare Pentium-133 wasn't doing anything else useful when you're not there to use it as a traffic generator for real projects, and it's also nice to the (pick-your-favorite-distro) community to leave it there seeding the recent distros overnight.
The Internet 2 project provides gimongous amounts of bandwidth between Major Research Universities in the US and Canada. If you've got a gigabit outbound connection and decent file sharing, you quickly run out of stuff to pirate :-) After all, Hollywood and Bollywood together don't put out more than a few movies per day, and they take about 5 minutes per DVD at those speeds - IF there's an application that can use the bandwidth effectively. Add in a hundred new audio CDs per day, and you're still done with piracy by 1am. The Internet2 front page currently references the Bittorrent article...
But now that some pieces have been done, putting them back together might make sense.
However, it's fairly good for letting universities and other fast-internal limited-external environments limit the amount of material they need to download from outside - and it's even better at letting them distribute software to the outside without burning infinite amounts of bandwidth, and serve files to internal users somewhat less server capacity, so it's a tool that makes sense for them to encourage.
There's still Research to be done in how to maximize clustering and localization of clients, so that most of the uploading and downloading stays within the fast LANs compared to the amount that uses the wide area network. BitTorrent has a certain amount of tuning in this direction that's driven by overall performance characteristics (obviously it makes sense to use fast links when you have them, but to do some balancing so that slow and isolated users get some content also and so rarer file segments get found if they're available), but most of the design work went into maximizing performance for the cloud as a whole and for end-users (more for non-leaching end-users) rather than for intermediate groupings of users.
Napster, while it was alive, did some work on this to avoid (ok, delay :-) getting thrown out of universities. Since it had centralized databases handling the indexing function, it was able to take identified groups of users and let them do most of their downloading within the group instead of outside. This was a Good Thing, particularly because Napster's client software (and therefore users) mainly knew peer performance by interface bandwidth, and sometimes by ping time, so they were more likely to grab a song from somebody on a 100 Mbps LAN, not knowing that there was an overloaded T1 in between until their ping times got ugly.
But it didn't say whether paying 20000 yen let you avoid replacing ink cartridges every not-very-many pages, or whether the high price just means you can print more pages before you've spent more on overpriced ink than you spent on the printer, or even brag about how you can replace the cartridge without breaking a fingernail.
And it doesn't say whether plugging the USB interface into your PC Just Works or requires installing drivers that don't get along with your version of Windows and have badly-translated instructions (We get signal! Somebody set up us the printer! It's you! How are you, lady! All your ink are belong to us!)
Bah - the Laserjet II was for wimps! Give me an old Imagen printer with the liquid toner that they used before the new dry toners came out! It was based on a mid-80s Canon copier mechanism, and the toner looked like used motor oil, but was really more like kerosene with carbon black dissolved in it. If the gauge shows that you're a quart low, you fill it up, after first making sure it wasn't just gunked up and lying about how full it was (the stuff's really nasty to clean up if it overflows.) Then you get to clean your hands like a Real Mechanic if you dripped any. And you get aromatic 240-dpi fuzzy pictures out of it, after having fun negotiating with the protocols.
Greetings. Meesa am Jojo Binkasa, Nephew of late engineer JarJar Binks. Meesa Unkle hadsa 65,000,000 credits in the Jedi bank of Tatooine whensa badsa things happendsa, and meesa needsa to find off-planet correspondent to transfer the money to the alliance. Plleeesa Helpsa meesa! Yousa are Meesa's Only Hope! May the Forsa be with yousa!
OK, it's easier to fit one of those VIA EPIA boards in a jar, or PC104, but you can pick up a used Sparcstation at Weird Stuff or HalTed for under $100, so why not build yourself an attractive server?
SSH is vulnerable to it also, but it takes the approach of recording a key the first time it connects to a destination and then complaining loudly if the key changes. You could adapt that to the "Open Secret" model if you wanted, though IPSEC doesn't usually have a user interface that you can use to get the user's attention.
Opportunistic Encryption does it mostly correctly, but not in a way that's very practical, because most people don't have control of their reverse DNS space and will therefore never deploy it. Also virtual hosting means that a given IP address can have lots of domain names behind it, and therefore potentially lots of different keys.
One alternative, "Open Secret", is to use a default preshared key that everybody knows, e.g. "Open Secret", so if you don't have anything better to use, you can still encrypt your conversations even though you're susceptible to Man-In-The-Middle attacks. The FreeSWAN crowd viewed that as too risky to bother adopting, even though it would have led to much better security for most users.
The paper describes fancier options, such as only impersonating numbers in some given range so that it only blocks reading some kinds of items, like the serial numbers on 100 Euro banknotes.
Of course, that doesn't invalidate Donaldson's Commentary ("Sturgeon was an optimist"), and there's lots of content that's not very interesting, but at least we need to get kids in the habit of providing things that are interesting to their friends and thinking of what they can do for society as a whole.
On the other hand, Sitefinder does know ports, so if Verisign DNS tells you Sitefinder's IP address, your application will try to talk to Sitefinder. It does something moderately correct if you send it an http request on port 80, and does something moderately broken if you send it an smtp request on port 25, and AFAIK it doesn't connect to any other port. (They could do an SSL-based search page on 443 if they wanted, and could also put their regular web server on popular alternative ports like 8000 and 8080 and their stubby email rejector on the alternative SMTP/SASL/SUBMIT ports.) (And I suppose I could nmap them to find out :-)
Of course, ICANN is much more concerned with "Intellectual Property" than with that other boring definition of IP that those boring computer networking people use, so perhaps they haven't noticed.
Many of sendmail's problems are related to building an extremely general purpose mail forwarder that had to on the Unix of the mid-1980s, support _all_ the popular email protocols of the time (including relaying between UUCP, BITNET, and many other non-TCP/IP things) and providing end-user mail receiving and mail sending services on time-sharing machines, as opposed to running in a dedicated environment with a simpler set of features. On the other hand, the AT&T Bell Labs Research UPAS mailers that became SVR4's mailer was just about as powerful but much smaller, cleaner, and more modular, and even under System III, the mail delivery software didn't need to run as root, so it wasn't the same horrendous security hole.
Microsoft-bashing isn't appropriate here either. Sure, the Exchange MTA and Outlook clients have appalling security and reliability records and used to be pretty much the Mos Eisley of security nightmares, but these aren't the security problems you're looking for. This is about addressing the security problems that are inherent in SMTP when you implement it _correctly_, which allows the mailer to receive all kinds of mail that makes fraudulent, bogus, distracting, or otherwise inappropriate claims about its origin that gives the naive recipient no way to hunt down and kill the evil time-wasting perpetrator (or makes it easy for the naive recipient to hunt down and kill the often-innocent bystander whose name was forged, whether the naive recipient is a human or a mailbot.) The problems have a lot of synergy - the lack of even cursory sender validation makes email an attractive nuisance when delivered to the naive recipient, who can be trusted to click on the happy shiny icon promising a display of dancing pigs (especially since Outlook is friendly enough to hide the ugly details from the user), triggering all the appalling things that can happen when you tell Outlook to trust a message it just received. This work is fundamentally about interfaces and scalability, and Sendmail Inc. is the right group for Microsoft to work with.
The details of the system seem a bit baroque to me, but you knew it was XML within the first couple of paragraphs, and it said Microsoft in the first half-sentence. It's not as lean and mean as LMAP and it has broader goals than SPF (which was originally about joe-jobs, and has suffered from some limitations as its scope has expanded.) And it's not going to solve the entire problem, because nothing short of a worldwide moral transformation or the extinction of the species is going to eliminate human greed and gullibility, but that's ok - even if it only eliminates _half_ the spam, that'll buy us another year of being able to keep reading email, plus it will annoy the spammers out there.
Of course, the continuing success of viruses that depend on the naive recipient pressing the button to watch the dancing pigs means that if SPF/LMAP/RMX/etc becomes widespread, we'll see more exploitation of Mail User Agent bugs that send out spam pretending to be from the naive user (or coworkers of the naive user), and then you can go back to bashing Microsoft while the Enemy continues their side of the arms race.