It's also a great solution for those of us who want to run linux on any machine we walk up to (eg. Knoppix sans reboot). "Free" has two meanings... Even IF VMWare lets your CD key travel, or even if you were rich enough to afford thousands of VMware licenses, the open source alternative would be much less painful because you don't have to deal with CD keys, allowing you to use a guest computer for just 5 minutes without worrying about wasting time activating the software you own.
You could presumably boot multiple kernels at once, like User Mode Linux. One could get running debian and apt-get installing away, another Mandrake, another Red Hat, one the latest 2.6 kernel, debian with a super-old-but-ostensibly-stable 2.4 kernel. You could do QoS queuing and complex firewalling within one box, or have an entire DMZ within various boxes running on the same phsyical machine.
Imagine a world where you can walk up to any machine, slide a CD in, and be working in your favorite environment in about 30 seconds, with lots of complex network and multimedia apps going. Pull the CD out, reboot, and the computer's owners won't necessarily even know you were ever there.
Now imagine a world where you can do the same thing, but it takes 15 seconds to boot, and you don't have to exit the person's applications, log them out, shut down their internet daemons, etc. Walk up to virtually any computer, and you have the full comfort of your standard environment.
It does put some burden on the sender as well though. These are the options I see:
The sender manages to keep your address confidential (meaning no catching outlook viruses, no cc'ing you along with 20 of their friends, no using it to send you stupid postcards). Not bloody likely for very many people.
All spams are responded to with a URL that users can use to get a new address from a warped GIF. Unfortunately the ISP has to pay doubly for spam.
The server simply drops spams (or puts them in a separate box that you never check since its S/N ratio is SOOOOO bad, curiously because this method is so effective). If that was the last contact info of you they had, they have to google you and find the above URL. For the masses, this would involve one or more email registries that people would have to remember to keep updated, including some of their personal info to differentiate David H. Newcum in illinois from David L. Newcum in Missouri. Unfortunately this means you have to give up a little extra private info, and it means you have to remember to keep the site updated in case your email address or domain changes (it would generate new disposable addresses periodically, so it wouldn't be THAT tedious). But this option also makes it slightly more likely that people will lose contact with you because googling isn't always easy.
But if there are invariants associated with spam, then systems will be at least partially effective.
Currently, spammers can create new spam relays only so fast.
Currently, spammers want to receive money via credit card over the internet.
Currently, it's hard enough to effectively spam that there aren't tens of thousands who are actively doing it, so blacklisting certain credit card vendor IDs could work.
Currently, spammers want to make it harder to "follow the money" so they use crazy javascript stuff on the front page of their websites, and the crazy javascript is one clue that the trail you're following is spammy. (add it to all the other clues you find, and you have a score that you can use to make a yes/no determination)
The unlimited-email-addresses basically comes down to requiring a password before someone can send you email (eg. if everyone accepted *@their.domain.com, spammers would just pick some random characters for the left side. So you have to have some sort of checksum or hash built into the characters, but if everyone uses the same algorithm, spammers would be able to generate their own random list again. So the only way to make it work universally is to salt the hash with something like a private key).
If people have to get passwords from you before they can contact you, then... what do you do if you're an open source author... or if an ex from college wants to hook up again and googles you, and finds your website, but STILL can't contact you... or you want to sign up for match.com so that random women can email you.
So that explains why RBLs are so unpopular, right?
ANY technical solution is going to require extra work on the client side, so rejecting this outright is kind of rediculous unless you're advocating a purely legal, market-based, or vigilante solution.
Spam is getting to be such a problem that techies are setting up things like SpamAssassin for themselves and friends, and major ISPs are using RBLs. So this isn't really a problem.
(x) Eternal arms race involved in all filtering approaches
One of the few constants is that there will be way for money to get from the target back to the original spammer or seller. (well, it's possible something more complex is going on and that's not the real goal of spam, but at the least, it's something that's remained constant for years, which is notable in the world of spam). So "following the money" is really based on an acceptance of the above criticism, and a realization that the arms race can never get around the money stream.
Filters may be lead to arms races, but does anyone NOT use them right now? There are few alternatives, namely things like making email non-anonymous / PKI, enacting large legal penalties along with huge international support, rejecting email from anyone you don't know,....
(x) Whitelists suck
Actually, it's a blacklist. Blacklists may suck, but it's possible they suck less than spam, and the proliferation of RBLs kind of implies that.
Sure, there might be a way to stop spam once and for all and then blacklists would be hated, but the very presence of a antispam-rejection-template implies that there won't be a magic bullet for a long time to come.
(x) Sorry dude, but I don't think it would work.
The only way it CAN'T work is if money isn't the real goal of spammers, or if they make it hard enough to "follow the money" that other methods are easier/nicer.
As an alternative, if you're already handy with perl, there are several tiny-yet-still-readable TCP proxies that can be tweaked to do on-the-fly stream modification or anything else you dream up.
Actually... (admitedly, this is a little convoluted, but...) netcat can act as a logging proxy for a single TCP connection. So.... if you add a slirp connection over the netcat logger, TECHNICALLY you're displaying everything that goes over a specific IP link. It's not just not terribly readable. Maybe someone needs to make a version of slirp that transfers everything in human-readable ascii, with the other end able to parse it back into raw packets.;)
If they're all hooked up with a hub, you can install it on any machine. If (more likely) they're connected via a switch, you likely have to install it on one machine that sits between the switch and the internet. (or is there a way to do something tricky with uplink ports or something?)
Anyway, in lieu of a better solution, what I do is described here... find a laptop with one built-in ethernet port... burn a knoppix CD (ethereal built-in)... buy a little bitty USB - ethernet adapter, and plug the laptop temporarily in between the cable modem and the switch. This has the side benefit that you can take the laptop + USB NIC elsewhere (eg. say, your favorite institution's network cabinet) and similarly sniff just about anything you want.
Users range from single computers connected to a congested cable modem, to five-nines uptime network admins who maintain multiple datacenters around the world, so there's a wide range of complexity that different apps need to fill.
Add to that user preferences about specific OS's, licenses, languages, etc. they like to use, and you can spend days searching for just the right network app for your specific need.
Yes yes, your statement is more accurate. I just usually think of the filter string as being part of tcpdump, and you can use that within ethereal. But yes, even that is really handled by libpcap (or winpcap or other variants, if we're getting super-specific... not that we should be, because I've certainly made some mistake in this post that someone would want to knee-jerk respond to).
it's what runs underneath ethereal, so it's good to be aware of it
its filtering syntax is extremely flexible
it's lightweight and only needs text or file output, so you could run it on an iPaq or whatnot
you can record streams with tcpdump, move the log to another machine, and load it into ethereal to do the packet analysis / stream reconstruction at a later point.
in library form (aka libpcap), lots of languages can hook to it, so you can easily do on-the-fly custom statistics calculations, instead of eating IO and disk space writing a huge log out and only processing it later. For example, even Perl + Net::Pcap running on a pentium machine is fast enough to keep up with a T3.
The best text version of etherape is iftop, in case you don't have X handy (or if you just have a spare dumb terminal and want your pad to look more geeky).
The best web-based version is ntop, which is another one of those "Oh my god, this is SOOO cool" tools, similar to ethereal. It lets you drill-down through a fair bit of data, and pages load fast and it's virtually real-time, so you can bang on the reload key and see a similar sort of data that etherape/iftop would give you. It has a daemon piece and a CGI piece, so installing it via a package (eg. apt-get install ntop) may be much prefered to installing it by hand.
Paranoia can't be taken too far regarding voting, at least not conceptually. In practice, you can only spend so much time and effort on proving that votes haven't been tampered with, but if you combine electronic voting machines with the results of 50 years of research in computer security, then software should be able to do most of the grunt work, and it may be possible to have MUCH stronger proof that no tampering took place than is available with paper, without requiring very much reoccuring human time/effort.
Noticed Google lately? Should we declare Google useless too?
How 'bout blog comments? Usenet? Freeware with convoluted EULAs? Where do we stop and say "enough"?
Without even realizing it...
on
Why PHBs Fear Linux
·
· Score: 4, Insightful
Well, without even realizing it, PHBs might find their employees integrating tools like Apache, perl, GNU make, etc into their development process or tools. At which point you tell the boss that they've gotten all this functionality for free for so long, and how many problems have you had because of it? Right, so bring on the linux.
I work for a Fortune 100 telecom company who isn't terribly pro-linux. But one day I counted up all the open-sourced software we use on a daily basis, there's a ton of it... if someone ripped OSS software away from us, we'd be in a world of hurt.
LOL. You mention in your own post that MD5 is 128 bits long. If you just restrict yourself to documents that are, say, 10mb big, that means there are 2^81920 possible plaintext documents for each MD5 hash. Granted, only some of them will look remotely like english, STILL... 2^81920 is quite enough to come up with many plaintext documents per hash. If you restrict yourself to keys
Slashdot Mirror
It's also a great solution for those of us who want to run linux on any machine we walk up to (eg. Knoppix sans reboot). "Free" has two meanings... Even IF VMWare lets your CD key travel, or even if you were rich enough to afford thousands of VMware licenses, the open source alternative would be much less painful because you don't have to deal with CD keys, allowing you to use a guest computer for just 5 minutes without worrying about wasting time activating the software you own.
You could presumably boot multiple kernels at once, like User Mode Linux. One could get running debian and apt-get installing away, another Mandrake, another Red Hat, one the latest 2.6 kernel, debian with a super-old-but-ostensibly-stable 2.4 kernel. You could do QoS queuing and complex firewalling within one box, or have an entire DMZ within various boxes running on the same phsyical machine.
Now imagine a world where you can do the same thing, but it takes 15 seconds to boot, and you don't have to exit the person's applications, log them out, shut down their internet daemons, etc. Walk up to virtually any computer, and you have the full comfort of your standard environment.
CoLinux is apparently somewhat similar to Plex86, but additionally requires admin access whereas Plex86 wasn't supposed to. Anyone know more?
It does put some burden on the sender as well though. These are the options I see:
Currently, spammers can create new spam relays only so fast.
Currently, spammers want to receive money via credit card over the internet.
Currently, it's hard enough to effectively spam that there aren't tens of thousands who are actively doing it, so blacklisting certain credit card vendor IDs could work.
Currently, spammers want to make it harder to "follow the money" so they use crazy javascript stuff on the front page of their websites, and the crazy javascript is one clue that the trail you're following is spammy. (add it to all the other clues you find, and you have a score that you can use to make a yes/no determination)
If people have to get passwords from you before they can contact you, then... what do you do if you're an open source author... or if an ex from college wants to hook up again and googles you, and finds your website, but STILL can't contact you... or you want to sign up for match.com so that random women can email you.
ANY technical solution is going to require extra work on the client side, so rejecting this outright is kind of rediculous unless you're advocating a purely legal, market-based, or vigilante solution.
Spam is getting to be such a problem that techies are setting up things like SpamAssassin for themselves and friends, and major ISPs are using RBLs. So this isn't really a problem.
- (x) Users of email will not put up with it
We'll see.- (x) Eternal arms race involved in all filtering approaches
One of the few constants is that there will be way for money to get from the target back to the original spammer or seller. (well, it's possible something more complex is going on and that's not the real goal of spam, but at the least, it's something that's remained constant for years, which is notable in the world of spam). So "following the money" is really based on an acceptance of the above criticism, and a realization that the arms race can never get around the money stream.Filters may be lead to arms races, but does anyone NOT use them right now? There are few alternatives, namely things like making email non-anonymous / PKI, enacting large legal penalties along with huge international support, rejecting email from anyone you don't know, ....
- (x) Whitelists suck
Actually, it's a blacklist. Blacklists may suck, but it's possible they suck less than spam, and the proliferation of RBLs kind of implies that.Sure, there might be a way to stop spam once and for all and then blacklists would be hated, but the very presence of a antispam-rejection-template implies that there won't be a magic bullet for a long time to come.
- (x) Sorry dude, but I don't think it would work.
The only way it CAN'T work is if money isn't the real goal of spammers, or if they make it hard enough to "follow the money" that other methods are easier/nicer.Oops, forgot to remove that line. I was able to get the instructions there to work (with a few updates found while running them).
As an alternative, if you're already handy with perl, there are several tiny-yet-still-readable TCP proxies that can be tweaked to do on-the-fly stream modification or anything else you dream up.
Actually... (admitedly, this is a little convoluted, but...) netcat can act as a logging proxy for a single TCP connection. So.... if you add a slirp connection over the netcat logger, TECHNICALLY you're displaying everything that goes over a specific IP link. It's not just not terribly readable. Maybe someone needs to make a version of slirp that transfers everything in human-readable ascii, with the other end able to parse it back into raw packets. ;)
Anyway, in lieu of a better solution, what I do is described here... find a laptop with one built-in ethernet port... burn a knoppix CD (ethereal built-in)... buy a little bitty USB - ethernet adapter, and plug the laptop temporarily in between the cable modem and the switch. This has the side benefit that you can take the laptop + USB NIC elsewhere (eg. say, your favorite institution's network cabinet) and similarly sniff just about anything you want.
The thing is, there are tons of network applications that fulfill usefully different roles:
Users range from single computers connected to a congested cable modem, to five-nines uptime network admins who maintain multiple datacenters around the world, so there's a wide range of complexity that different apps need to fill.
Add to that user preferences about specific OS's, licenses, languages, etc. they like to use, and you can spend days searching for just the right network app for your specific need.
(actually, it looks a lot like ethereal, so maybe it's not total rubish)
Yes yes, your statement is more accurate. I just usually think of the filter string as being part of tcpdump, and you can use that within ethereal. But yes, even that is really handled by libpcap (or winpcap or other variants, if we're getting super-specific... not that we should be, because I've certainly made some mistake in this post that someone would want to knee-jerk respond to).
Yeah... When secretaries start quoting rates in BPS instead of WPM, *that's* when I get really impressed.
The best web-based version is ntop, which is another one of those "Oh my god, this is SOOO cool" tools, similar to ethereal. It lets you drill-down through a fair bit of data, and pages load fast and it's virtually real-time, so you can bang on the reload key and see a similar sort of data that etherape/iftop would give you. It has a daemon piece and a CGI piece, so installing it via a package (eg. apt-get install ntop) may be much prefered to installing it by hand.
Paranoia can't be taken too far regarding voting, at least not conceptually. In practice, you can only spend so much time and effort on proving that votes haven't been tampered with, but if you combine electronic voting machines with the results of 50 years of research in computer security, then software should be able to do most of the grunt work, and it may be possible to have MUCH stronger proof that no tampering took place than is available with paper, without requiring very much reoccuring human time/effort.
Slashdot is nearly a blog. You could have added "waste of time" while you were writing your comment, but even still, people continue to post....
How 'bout blog comments? Usenet? Freeware with convoluted EULAs? Where do we stop and say "enough"?
I work for a Fortune 100 telecom company who isn't terribly pro-linux. But one day I counted up all the open-sourced software we use on a daily basis, there's a ton of it... if someone ripped OSS software away from us, we'd be in a world of hurt.
LOL. You mention in your own post that MD5 is 128 bits long. If you just restrict yourself to documents that are, say, 10mb big, that means there are 2^81920 possible plaintext documents for each MD5 hash. Granted, only some of them will look remotely like english, STILL... 2^81920 is quite enough to come up with many plaintext documents per hash. If you restrict yourself to keys