In a similar vein, it was never explained how Colin Powell had a transcript of Bin Laden's last taped message, before the al-Jazeera station even had the tape.
Correction: before al-Jazeera admitted they had the tape publicly. Or do you believe their denial of ever having heard of the tape and then airing it as Powell had predicted?
If al-Jazeera isn't thoroughly compromised internally via both human and electronic assets, than the CIA/NSA aren't doing their job. They're clearly a very likely avenue for tracking OBL. No doubt we knew before half of al-Jazeera did that the tape had shown up in the shipping room.
No, I get the point completely. It isn't a complex design.
My point is about what the end result will be after programmers use this: cruft. Major cruft. Cruft beyond all cruftiness of cruftension. So it has always been with apps that get picky about library version, and so it will always be. I have seen this happen to Unix applications, I have seen it happen to Windows applications, I have seen it happen to COM/DCOM, and I recognize the beast when presented as.NET.
Assemblies in.NET are quite powerful and useful.
No doubt. In the programming world, however, power is rarely wielded wisely or for good.
I think this simply works by allowing different versions of the same DLL.
Right - given N programs using foo.dll, how many different versions of foo.dll do you expect will be needed? Based on my experience with Windows, I would expect somewhere between N and 2*N (allowing for "upgrades" of N[i] which won't remove the "old" DLL version.
Yes, theoretically, you'll have a smaller number of DLLs than you do programs. Realistically, I don't see it happening. The various versions of Microsoft's XML DLL (which comes to mind because of the security patch which requires you to figure out which versions you have installed, which is always more than 1) illustrate this perfectly.
Sounds like a great idea.... each and every program will have it's "own" DLL
Call me old-fashioned, but I thought the point of dynamic libraries was to reduce program size and duplication of effort by allowing multiple programs to load common functions out of libraries.
So, it's a great idea, insofar as it completely negates the advantage of having DLLs in the first place. Why don't they just compile statically instead?
It's BB&N... er, GTEI... er, Genuity that's getting pounded. They provide caching DNS servers to the entire Internet at 4.2.2.1 (.2,...) and because they're so easily memorizable, I've never met a sysadmin who didn't put them in a hosts' configuration in a pinch.
You hear it so much from Tufts because so many of the students at Tufts applied and got rejected by Ivy League schools. It's completely acknowledged as an "Ivy back-up" school within the student population.
These are completely untrue
Well, I wasn't there in the 60s, and the story seemed credibly described when I saw it. A little Googling supports the "Myth" interpretation, though, so it looks like you're right. I'll avoid spreading the rumor any further;>
You're absolutely right. djbdns doesn't have anything going for it except exceptional security and performance, and why would a root name server need that?
Tufts is an old, prestigious school that is not neccessarily well known. It's just a step below Ivy (was in fact considered for joining the Ivy League in the 60s), but doesn't have anywhere near the same recognition. Pointing out its age is a way of saying that we're not talking about Community College of East Podunk here; slightly higher standards of behavior are expected out of students who have to pass a difficult entrant selection and pay ludicrous amounts of money to go to the school.
Having said that, I'm not suprised by the story. It's well in line with some of the... computer activities... that took place in my days there.
Now, can we compare this with a timeline of security flaws in linux and packages frequently installed on linux like mysql, bind, apache, etc?
Yes, but it is more difficult. A good place to start would be the SecurityFocus Vulnerabilities archive. Part of the difficulty is that vulnerabilities are often reported multiple times due to the various vendors, etc. etc.
Without going into a detailed analysis, Bind has the worst history if you go far back, but its frequency is a lot better now. At its worst, it was at roughly IIS levels of hole frequency and seriousness. Apache and Mysql have both low frequency of holes, and Apache tends to have more non-fatal holes than serious ones (i.e., access to files rather than remote root exploitation).
Another interesting comparison would be the resources and man hours put into, say, IIS versus Apache or MS-SQL versus MySQL. Without hard information, I think its safe to assume that the Microsoft products have had a lot more development done on them. While in a perfect world this would improve their security, I think the practical effect is to decrease their security due to code and feature bloat - "Trustworthy Computing" notwithstanding.
it just seemed like they based their whole thesis of security shortcommings on one recent incident.
I think it has more to do with the anniversary of the Trustworthy Computing effort within Microsoft. It was a year ago that the Bill announced that security was their new focus, that all the software engineers were standing down for a month of no new code, just security bug-finding and bug-fixing. And there have been recent announcements reiterating this sort of "commitment".
Mind you, this worm is a poor example of Microsoft insecurity. Not only was there a patch out, but it was SQL - any admin who didn't have it patched should at least have had it firewalled. But the timing of it points out that Microsoft has had many years of insecure feature-oriented software engineering to go back and fix up, and that their "new direction" has a lot of inertia to overcome.
Thank you. It is understandable how you could construe it that way.
I'm a bit broken up over this whole thing. I was home sick on Jan 28th, 1986 and watched the Challenger disintegrate live on TV. This whole incident brought those memories back in a flash.
I'm with you. I wasn't home sick, but I did go home from school and watched them replay the explosion in what seemed like an endless loop all afternoon. This time I turned off the TV quickly because I'm older and smarter and am not going to subject myself to it again. Part of why I want to discuss technicalities is because it helps hold off the emotions.
You disgust me. 7 people are dead and all you can think of is making digs against a program you don't agree with.
You assume I don't agree with the program. Your assumption is incorrect. However, interception of any object in ballistic motion is a difficult problem, which is all the link was intended to convey. Had I wanted to convey some moral judgement about the Star Wars program, there's numerous links (e.g., Greenpeace's opinions) which would do better.
Care to re-examine your other assumptions?
I think 7 people died, probably because of equipment failure during an extremely dangerous part of their job - or is it sickeing of me to think about why they died? I mourn for them, and I mourn for their families. I wasn't aware I had to make all this explicit in a technical forum, for fear of offending people like you.
Has no one considered surreptitious manual damage to some critical part of the vehicle before takeoff?
Yes, but it seems to me that such damage would be more likely to affect liftoff (lots of rocket fuel going boom, more dramatic effect, less time for damage to be discovered and addressed before it has a chance to do anything bad).
My money is on failure of some part of the heat shielding, probably the part that was damaged earlier. At that point in reentry, if enough heat shielding fails at the wrong time, the result is catastrophic. It's arguably the second most dangerous part of the flight (next to the boosters going off).
at an altitude of 200,000 feet (61km) and velocity of 12,000 miles per hour (19,000 km/h)
That makes terrorism highly unlikely. That's too high and too fast for much of anything to hit it. It's more like a ballistic missile than an airplane at that point, and we all know how well the Star Wars project is faring.
Can anyone give a good reason for needing files larger than 2gb?
Forensic analysis of disk images. And yes, from experience I can tell you that half the file tools on RedHat (like, say, Perl) aren't compiled to support >2GB files.
In what organization does anyone look at the code and understand it, but furthermore find the vulnerabilities? That argument seems to crop up as the first few paragraphs in security / technical articles and just never seems to pass muster.
Because it is taken as a given that the whether or not the organization has a qualified individual is completely moot if the source isn't available.
If the source is closed, then you will never have a chance to audit the source for vulnerabilities. If the source is open, then you may or may not have a qualified person - but if the shit hits the fan, you can get one fast.
Consider this: Your web farm uses (Apache or IIS). You find that someone with a 0day is able to compromise your servers; you quickly tweak your IDS so that you can detect and clean up after successful attacks, but until you get a patch you're just playing catch-up.
Now: Given that you have the exploit on the wire, how hard is it for you to hire a contractor to find the bug, fix it, and get your ass off the griddle? How much time will it take? If you're using Apache? If you're using IIS? If you have to depend on Microsoft to do the looking and fixing for you?
Even if you don't have a qualified person on staff who previously audited a code... now's a damn good time to have the source. Would it be better for the company to have audited it beforehand? Sure, but failing that, with the source you can bounce back from problems a lot faster.
PGP (for windows or mac, ie not GPG) has two commands related to this: wipe file and wipe free space.
And for those wishing for only mid-grade free space wiping, check out "cipher" which comes with Win XP and Win2K SP3. 'cipher/w:c:' will wipe all the free space on c: with 0s, then with 1s, then with random data.
I have mine cron'ned - er, "Task Scheduled" - to run several times a week, just to keep things on the sanitary side. You never know when the layoffs will leave you wondering who is looking at your old hard drive.
You can't really 'skin' it. Yes, the shells are interchangeable, but at the factory. A home user bolting on one of these in his/her garage is opening up all sorts of safety concerns.
I'm betting that your friendly neighborhood GM dealer would be happy to provide "Skinning" service so that you can rent a minivan skin for the holiday trip to grandma's and go back to your sedan for the next work week. If GM wants this idea to go over, as far as the dealers are concerned that idea is going to be massive. Dealers have been getting less and less return work over the last few decades; this is a way to send more business to the dealers. Of COURSE, they'll have to run a diagnostic before skinning, and suggest fixes for any problems they find...
I love this HyWire car. Too bad it's GM and not Ford doing it;>
This is so timely. I just finished reading Ayn Rand's Atlas Shrugged and was a bit disappointed, thinking that its portrayal of viciously greedy second-handers in a world where the capable are punished for not allowing the incompetent to leech off of them was just too surreal.
Thank's for setting me straight, Search King. And stay away from that harmonic destructor thingy.
The big thing is that email is one of the "killer apps" of the Internet. Any anti-Spam solution has to be universal. I do not see micropayments for email ever being universal. This would mean that every single ISP across the globe would have to go to it to truly work.
Why does it have to be universal? And why does every single ISP have to do it?
Let's look at existing anti-SPAM measures, like MAPS and RFC-Ignorant. As such businesses like to point out, they are not a filter or censor - they are merely a list which individuals and groups may choose to use to filter their email. The same is even more true at the MUA level, where individuals may or may not use or implement filtering (such as SpamAssassin Pro)
Also, the need for it is not universal, so why need the solution be? How much is your time worth? Would it be worth it to you to charge - and be charged - a miniscule amount to have a reasonably clear email stream? How about your mother? How about the CEO of your company? Different people have different thresholds of need, and different willingness to pay and/or inconvenience their correspondents.
Systems already exist which automate the process of kicking unknown sender's mail back with instructions on how to overcome the block - again, it's something individuals choose to use today, without killing the "universal" nature of email.
And you do not get to the real question: How is micropayments for email not a step backwards.
It is a given that the problem with SPAM is that it costs the sender nothing, and there is no market restraint upon it. Therefore, I took it as a given that some form of cost is involved in the solution. You take that as a backwards step. I don't neccessarily agree - but I retain the right not to send people email if I don't feel they are worth dropping.001 cents on.
Not everything that is free is good, and not everything which costs is bad.
(You also decided not to touch upon the issue that a lot of people have problems with PayPal, the example you decided to use - these types of problems are always going to arise when it comes to a universal system involving people's money)
Of course not - because such problems
are not unique to the Internet or Micropayments, but have existed since Ogg first required Mog to exchange clam shells for food. It is a given that such a system will either be regulated or not, and will either be trustworthy or not. It is also a given that even with the best controls, someone somewhere will get scalped someday, because humans suck.
Think about the full implications of *whatever SMTP server you use having some credit card information about you*.
The people working on micropayments have spent a lot of time thinking about it. There's also a lot of people thinking about anonymous cash on the network. Most of them are damn smart, but it's a difficult problem. Despite that, you'll see it within a decade, I think.
That's why the people who say "micropayments" get modded up, because anybody who knows anything about micropayments knows it isn't that brain-dead. Or do you give your credit card number to everyone you PayPal?
The answer is to modify SMTP as we have it. Require authorization. Make it impossible to forge headers.
Such schemes only work if you can trust each node that can handle mail. I would claim that you can't. (Well, no, it isn't a claim. It's a fact. Even if you could trust every machine's owner, you couldn't trust everyone capable of rooting a machine.) What you suggest - "require authorization" - is little different than doing AUTH/IDENT lookups, which were a good idea right up until they invented the PC and put it online.
Didn't the book Snow Crash have something similar in it? I think both YT and Hiro were wearing suits that incorporated similar stuff to this.
Yes. YT went into detail at one point explaining how it inflated around the neck and head, removing the need for a helmet. She wore one all the time when skating. Hiro wore one when he, ah, bought that motorcycle; his had the added advantage of being bulletproof.
Now if only someone'd build smartwheels, we could avoid being chiseled spam.
Tell that to the Somalis who forced the U.S. out of their country with (mostly) small arms.
You misspelled "headlines."
Somali "arms" had nothing to do with "forcing" the US out. Getting a picture of a single US airman with the shit beat out of him and a few pictures of bodies dragged in the streets splashed across the media, combined with a government and people who didn't know or care what the US was there for, had everything to do with it.
A lot of the advantages of a high tech, heavily armed disappear in urban combat, especially when the high tech army doesn't want to cause incredible numbers of innocent casualties.
This is true... but not about Mogadishu. After all was said and done, the US troops held an untenable position for a long time, inflicting massive casualties while suffering comparatively few themselves. If you set aside the logistical and organizational fuckups that led to the battle, the actual battle was pretty one-sided against the Somalis.
You should read Black Hawk Down and pay attention to the numbers. I haven't seen the movie, but I can't imagine it bears any resemblance to the book, truth, fact, or history.
You folks act like being easy to use is a _bad_ thing. While the rest of the world thinks it's a good thing.
IT consultants have a saying: "Any idiot can set up Windows - and most do."
Of course, when they come to the hard-won conclusion that NetBIOS workgroups don't scale to 300 hosts on a chained 10 MB hub topology, they hire us to come in and fix their mess.
This sort of statistic won't show up in any study of Fortune 500 companies (because they hire real admins, they don't ask the shipping clerk who "knows windows" to run things), but if you run around to a number of small/mid-sized companies, I guarantee you you'll find gordian knots that are strangling the companies. So they pay IT consultants to come in and cut the knot.
Easy to use is good. Hard to use wrong is better. Linux isn't any better in this respect, but you should be aware of the sharp edge on the back face of your "easy to use" sword.
Slashdot Mirror
In a similar vein, it was never explained how Colin Powell had a transcript of Bin Laden's last taped message, before the al-Jazeera station even had the tape.
Correction: before al-Jazeera admitted they had the tape publicly. Or do you believe their denial of ever having heard of the tape and then airing it as Powell had predicted?
If al-Jazeera isn't thoroughly compromised internally via both human and electronic assets, than the CIA/NSA aren't doing their job. They're clearly a very likely avenue for tracking OBL. No doubt we knew before half of al-Jazeera did that the tape had shown up in the shipping room.
No, I get the point completely. It isn't a complex design.
My point is about what the end result will be after programmers use this: cruft. Major cruft. Cruft beyond all cruftiness of cruftension. So it has always been with apps that get picky about library version, and so it will always be. I have seen this happen to Unix applications, I have seen it happen to Windows applications, I have seen it happen to COM/DCOM, and I recognize the beast when presented as .NET.
Assemblies in .NET are quite powerful and useful.
No doubt. In the programming world, however, power is rarely wielded wisely or for good.
I think this simply works by allowing different versions of the same DLL.
Right - given N programs using foo.dll, how many different versions of foo.dll do you expect will be needed? Based on my experience with Windows, I would expect somewhere between N and 2*N (allowing for "upgrades" of N[i] which won't remove the "old" DLL version.
Yes, theoretically, you'll have a smaller number of DLLs than you do programs. Realistically, I don't see it happening. The various versions of Microsoft's XML DLL (which comes to mind because of the security patch which requires you to figure out which versions you have installed, which is always more than 1) illustrate this perfectly.
Sounds like a great idea.... each and every program will have it's "own" DLL
Call me old-fashioned, but I thought the point of dynamic libraries was to reduce program size and duplication of effort by allowing multiple programs to load common functions out of libraries.
So, it's a great idea, insofar as it completely negates the advantage of having DLLs in the first place. Why don't they just compile statically instead?
It's BB&N... er, GTEI... er, Genuity that's getting pounded. They provide caching DNS servers to the entire Internet at 4.2.2.1 (.2, ...) and because they're so easily memorizable, I've never met a sysadmin who didn't put them in a hosts' configuration in a pinch.
You hear it so much from Tufts because so many of the students at Tufts applied and got rejected by Ivy League schools. It's completely acknowledged as an "Ivy back-up" school within the student population.
These are completely untrue
Well, I wasn't there in the 60s, and the story seemed credibly described when I saw it. A little Googling supports the "Myth" interpretation, though, so it looks like you're right. I'll avoid spreading the rumor any further ;>
Oh wait. NONE OF THAT IS TRUE. Never mind.
You're absolutely right. djbdns doesn't have anything going for it except exceptional security and performance, and why would a root name server need that?
What does it matter that Tufts is 151 years old?
Tufts is an old, prestigious school that is not neccessarily well known. It's just a step below Ivy (was in fact considered for joining the Ivy League in the 60s), but doesn't have anywhere near the same recognition. Pointing out its age is a way of saying that we're not talking about Community College of East Podunk here; slightly higher standards of behavior are expected out of students who have to pass a difficult entrant selection and pay ludicrous amounts of money to go to the school.
Having said that, I'm not suprised by the story. It's well in line with some of the... computer activities... that took place in my days there.
Now, can we compare this with a timeline of security flaws in linux and packages frequently installed on linux like mysql, bind, apache, etc?
Yes, but it is more difficult. A good place to start would be the SecurityFocus Vulnerabilities archive. Part of the difficulty is that vulnerabilities are often reported multiple times due to the various vendors, etc. etc.
Without going into a detailed analysis, Bind has the worst history if you go far back, but its frequency is a lot better now. At its worst, it was at roughly IIS levels of hole frequency and seriousness. Apache and Mysql have both low frequency of holes, and Apache tends to have more non-fatal holes than serious ones (i.e., access to files rather than remote root exploitation).
Another interesting comparison would be the resources and man hours put into, say, IIS versus Apache or MS-SQL versus MySQL. Without hard information, I think its safe to assume that the Microsoft products have had a lot more development done on them. While in a perfect world this would improve their security, I think the practical effect is to decrease their security due to code and feature bloat - "Trustworthy Computing" notwithstanding.
It would have been nice to see some kind of list, or maybe a timeline of sorts with other MS security flaws.
That would be here.
it just seemed like they based their whole thesis of security shortcommings on one recent incident.
I think it has more to do with the anniversary of the Trustworthy Computing effort within Microsoft. It was a year ago that the Bill announced that security was their new focus, that all the software engineers were standing down for a month of no new code, just security bug-finding and bug-fixing. And there have been recent announcements reiterating this sort of "commitment".
Mind you, this worm is a poor example of Microsoft insecurity. Not only was there a patch out, but it was SQL - any admin who didn't have it patched should at least have had it firewalled. But the timing of it points out that Microsoft has had many years of insecure feature-oriented software engineering to go back and fix up, and that their "new direction" has a lot of inertia to overcome.
I'm sorry that I misconstrued your intent.
Thank you. It is understandable how you could construe it that way.
I'm a bit broken up over this whole thing. I was home sick on Jan 28th, 1986 and watched the Challenger disintegrate live on TV. This whole incident brought those memories back in a flash.
I'm with you. I wasn't home sick, but I did go home from school and watched them replay the explosion in what seemed like an endless loop all afternoon. This time I turned off the TV quickly because I'm older and smarter and am not going to subject myself to it again. Part of why I want to discuss technicalities is because it helps hold off the emotions.
You disgust me. 7 people are dead and all you can think of is making digs against a program you don't agree with.
You assume I don't agree with the program. Your assumption is incorrect. However, interception of any object in ballistic motion is a difficult problem, which is all the link was intended to convey. Had I wanted to convey some moral judgement about the Star Wars program, there's numerous links (e.g., Greenpeace's opinions) which would do better.
Care to re-examine your other assumptions?
I think 7 people died, probably because of equipment failure during an extremely dangerous part of their job - or is it sickeing of me to think about why they died? I mourn for them, and I mourn for their families. I wasn't aware I had to make all this explicit in a technical forum, for fear of offending people like you.
Has no one considered surreptitious manual damage to some critical part of the vehicle before takeoff?
Yes, but it seems to me that such damage would be more likely to affect liftoff (lots of rocket fuel going boom, more dramatic effect, less time for damage to be discovered and addressed before it has a chance to do anything bad).
My money is on failure of some part of the heat shielding, probably the part that was damaged earlier. At that point in reentry, if enough heat shielding fails at the wrong time, the result is catastrophic. It's arguably the second most dangerous part of the flight (next to the boosters going off).
at an altitude of 200,000 feet (61km) and velocity of 12,000 miles per hour (19,000 km/h)
That makes terrorism highly unlikely. That's too high and too fast for much of anything to hit it. It's more like a ballistic missile than an airplane at that point, and we all know how well the Star Wars project is faring.
Can anyone give a good reason for needing files larger than 2gb?
Forensic analysis of disk images. And yes, from experience I can tell you that half the file tools on RedHat (like, say, Perl) aren't compiled to support >2GB files.
In what organization does anyone look at the code and understand it, but furthermore find the vulnerabilities? That argument seems to crop up as the first few paragraphs in security / technical articles and just never seems to pass muster.
Because it is taken as a given that the whether or not the organization has a qualified individual is completely moot if the source isn't available.
If the source is closed, then you will never have a chance to audit the source for vulnerabilities. If the source is open, then you may or may not have a qualified person - but if the shit hits the fan, you can get one fast.
Consider this: Your web farm uses (Apache or IIS). You find that someone with a 0day is able to compromise your servers; you quickly tweak your IDS so that you can detect and clean up after successful attacks, but until you get a patch you're just playing catch-up.
Now: Given that you have the exploit on the wire, how hard is it for you to hire a contractor to find the bug, fix it, and get your ass off the griddle? How much time will it take? If you're using Apache? If you're using IIS? If you have to depend on Microsoft to do the looking and fixing for you?
Even if you don't have a qualified person on staff who previously audited a code... now's a damn good time to have the source. Would it be better for the company to have audited it beforehand? Sure, but failing that, with the source you can bounce back from problems a lot faster.
PGP (for windows or mac, ie not GPG) has two commands related to this: wipe file and wipe free space.
And for those wishing for only mid-grade free space wiping, check out "cipher" which comes with Win XP and Win2K SP3. 'cipher /w:c:' will wipe all the free space on c: with 0s, then with 1s, then with random data.
I have mine cron'ned - er, "Task Scheduled" - to run several times a week, just to keep things on the sanitary side. You never know when the layoffs will leave you wondering who is looking at your old hard drive.
You can't really 'skin' it. Yes, the shells are interchangeable, but at the factory. A home user bolting on one of these in his/her garage is opening up all sorts of safety concerns.
I'm betting that your friendly neighborhood GM dealer would be happy to provide "Skinning" service so that you can rent a minivan skin for the holiday trip to grandma's and go back to your sedan for the next work week. If GM wants this idea to go over, as far as the dealers are concerned that idea is going to be massive. Dealers have been getting less and less return work over the last few decades; this is a way to send more business to the dealers. Of COURSE, they'll have to run a diagnostic before skinning, and suggest fixes for any problems they find...
I love this HyWire car. Too bad it's GM and not Ford doing it ;>
This is so timely. I just finished reading Ayn Rand's Atlas Shrugged and was a bit disappointed, thinking that its portrayal of viciously greedy second-handers in a world where the capable are punished for not allowing the incompetent to leech off of them was just too surreal.
Thank's for setting me straight, Search King. And stay away from that harmonic destructor thingy.
Nethack .
One of these days I'll ascend, but until them, that dev team is a bunch of complete bastards.
The big thing is that email is one of the "killer apps" of the Internet. Any anti-Spam solution has to be universal. I do not see micropayments for email ever being universal. This would mean that every single ISP across the globe would have to go to it to truly work.
Why does it have to be universal? And why does every single ISP have to do it?
Let's look at existing anti-SPAM measures, like MAPS and RFC-Ignorant. As such businesses like to point out, they are not a filter or censor - they are merely a list which individuals and groups may choose to use to filter their email. The same is even more true at the MUA level, where individuals may or may not use or implement filtering (such as SpamAssassin Pro)
Also, the need for it is not universal, so why need the solution be? How much is your time worth? Would it be worth it to you to charge - and be charged - a miniscule amount to have a reasonably clear email stream? How about your mother? How about the CEO of your company? Different people have different thresholds of need, and different willingness to pay and/or inconvenience their correspondents.
Systems already exist which automate the process of kicking unknown sender's mail back with instructions on how to overcome the block - again, it's something individuals choose to use today, without killing the "universal" nature of email.
And you do not get to the real question: How is micropayments for email not a step backwards.
It is a given that the problem with SPAM is that it costs the sender nothing, and there is no market restraint upon it. Therefore, I took it as a given that some form of cost is involved in the solution. You take that as a backwards step. I don't neccessarily agree - but I retain the right not to send people email if I don't feel they are worth dropping .001 cents on.
Not everything that is free is good, and not everything which costs is bad.
(You also decided not to touch upon the issue that a lot of people have problems with PayPal, the example you decided to use - these types of problems are always going to arise when it comes to a universal system involving people's money)
Of course not - because such problems are not unique to the Internet or Micropayments, but have existed since Ogg first required Mog to exchange clam shells for food. It is a given that such a system will either be regulated or not, and will either be trustworthy or not. It is also a given that even with the best controls, someone somewhere will get scalped someday, because humans suck.
Think about the full implications of *whatever SMTP server you use having some credit card information about you*.
The people working on micropayments have spent a lot of time thinking about it. There's also a lot of people thinking about anonymous cash on the network. Most of them are damn smart, but it's a difficult problem. Despite that, you'll see it within a decade, I think.
That's why the people who say "micropayments" get modded up, because anybody who knows anything about micropayments knows it isn't that brain-dead. Or do you give your credit card number to everyone you PayPal?
The answer is to modify SMTP as we have it. Require authorization. Make it impossible to forge headers.
Such schemes only work if you can trust each node that can handle mail. I would claim that you can't. (Well, no, it isn't a claim. It's a fact. Even if you could trust every machine's owner, you couldn't trust everyone capable of rooting a machine.) What you suggest - "require authorization" - is little different than doing AUTH/IDENT lookups, which were a good idea right up until they invented the PC and put it online.
Didn't the book Snow Crash have something similar in it? I think both YT and Hiro were wearing suits that incorporated similar stuff to this.
Yes. YT went into detail at one point explaining how it inflated around the neck and head, removing the need for a helmet. She wore one all the time when skating. Hiro wore one when he, ah, bought that motorcycle; his had the added advantage of being bulletproof.
Now if only someone'd build smartwheels, we could avoid being chiseled spam.
Tell that to the Somalis who forced the U.S. out of their country with (mostly) small arms.
You misspelled "headlines."
Somali "arms" had nothing to do with "forcing" the US out. Getting a picture of a single US airman with the shit beat out of him and a few pictures of bodies dragged in the streets splashed across the media, combined with a government and people who didn't know or care what the US was there for, had everything to do with it.
A lot of the advantages of a high tech, heavily armed disappear in urban combat, especially when the high tech army doesn't want to cause incredible numbers of innocent casualties.
This is true... but not about Mogadishu. After all was said and done, the US troops held an untenable position for a long time, inflicting massive casualties while suffering comparatively few themselves. If you set aside the logistical and organizational fuckups that led to the battle, the actual battle was pretty one-sided against the Somalis.
You should read Black Hawk Down and pay attention to the numbers. I haven't seen the movie, but I can't imagine it bears any resemblance to the book, truth, fact, or history.
You folks act like being easy to use is a _bad_ thing. While the rest of the world thinks it's a good thing.
IT consultants have a saying: "Any idiot can set up Windows - and most do."
Of course, when they come to the hard-won conclusion that NetBIOS workgroups don't scale to 300 hosts on a chained 10 MB hub topology, they hire us to come in and fix their mess.
This sort of statistic won't show up in any study of Fortune 500 companies (because they hire real admins, they don't ask the shipping clerk who "knows windows" to run things), but if you run around to a number of small/mid-sized companies, I guarantee you you'll find gordian knots that are strangling the companies. So they pay IT consultants to come in and cut the knot.
Easy to use is good. Hard to use wrong is better. Linux isn't any better in this respect, but you should be aware of the sharp edge on the back face of your "easy to use" sword.