The trade press don't have any real devotion to fairness and even-handed columns. Recently I took a writer to task for his deliberate mishandling of the "hacker" / "cracker" semantic dispute. I wrote that
I understand when columnists mix-and-match the words "hacker" and "cracker": if nothing else, you guarantee enough email response to write a future column on Internet "flame mail" (just kidding).
The author in his reply admitted that he intended to "provoke--and even promote some flame mail" so that he might learn what people really thought. I did not, could not, reply to that.
Over the last few years I've seen similar behavior very often from Metcalfe; he's really not worth reading anymore.
Don't take these trade rag hacks seriously. It's a waste of cycles.
Also, if you have a Web server installed on your system, you should ensure that it does not listen to requests on whatever address you associate with the link4ads hostname. You could either configure the binding address, or possibly use a local kernel firewall to reject packets to that IP address.
Otherwise, I've found that Netscape will request weird URL's of my local httpd. In most cases this just means broken images, but in some cases the page refuses to load when the "ad" SRC sends a 404 error or somesuch.
Configure your system to resolve "van.ads.link4ads.com" to 127.0.0.. I forget how to do this with MacOS N (N < 10), but it would be/etc/hosts in Unix or \windows\hosts or \winnt\system32\drivers\etc\hosts for Windows 9x/NT.
This seems to be working for me.
Andover folks: I only do this for ad sites that use stuff like <SCRIPT> tags to bypass my "originating server" cookie settings, as link4ads.com does. I make no attempt to block the normal (adfu?) ads, and I do click through those sometimes. But if you want to send a third-party tracking cookie with the ads, sorry, I refuse.
Yahoo, et. al., ought to be working to figure out where the spoofed packets are coming from. The blame ultimately falls not onlyon the attackers, but the network admins who allow the spoofed packets to leave their nets.
First we started to track down open SMTP relays. Now we need to hunt down underprotected routers.
Are the high-profile victims doing that? Where's the evidence?
I didn't buy the cost-benefit argument, sorry.... OK, maybe you can justify it that way but it feels over conservative to me.
At least for the one site I'm most familiar with, serious hardware problems could easily cost hundreds of thousands of US dollars (if not millions), while expected revenue and traffic were incredibly low. Still, I agree that the shutdown is "fearful", and "conservative". But the more you have to lose by failure, and the less you stand to gain by perfect uptime, the more it makes sense.
I think there's an emotional factor in this for me, too. Pride, I guess.
Certainly my systems didn't shut down for midnight UTC or midnight local time, either. I really think that there's got to be a different level of pressure on these CTO's that are responisble for multi-million dollar infrastructures, and while I, too, chuckle a bit at the fearfulness, I can understand there being a strong urge to CYA. Some of this may be a geek-suit mindset difference; the programmers want to say they "did it", while the management types want to say they "managed risks".
Also, I suspect a lot of sites with distributed server farm architectures quietly pulled some servers offline last night, voluntarily reduced capacity to be safe. Just as conservative, but not as visible. We may never know.
I love how you totally skip my rational, cost-benefit-risk argument and latch onto one minor thread. Actually, I don't know the readiness of any system outside my control. External systems cannot be completely trusted: sure, they vendor may certify compliance/readiness, but I've got no way of verifying that. You mention the fact that many utilities have extra staff on duty tonight. Why? Could it be, oh, that they suspect/fear something may go wrong? Are they, too, "irrational and fearful" (you mean to say "stupid", don't you?) for taking extra precautions? How do you know your utility is ready? What first hand, direct evidence have you gathered?
Case in point: some power utilities sell, and ship, power across state borders to other utilities. They can test their systems, but can they really help test, or witness tests, of all the other utilities they might depend on? No. Everyone is dealing with some uncertainty when it comes to other people's systems. Everyone.
As I said, the chance of the infrastructure failing dramatically is very slim (and everything seems to be going fine), but the costs of worst-case failures will, in almost all Web commerce systems, vastly outweigh the costs of revenues lost by brief downtimes.
Again, if your site is down tonight, it's because your pants are down, buddy.
If my site crashes, then, yeah, it's likely (though not necessarily) my fault. But we're not talking about crashes, Bruce. We're talking about voluntary shutdowns. While I agree that these shutdowns could be called "fearful", they're anything but "irrational".
Somebody rate Bruce's post down as flame-bait. (Somehow it got the automatic Oh-My-God-It's-Bruce-Perens-Again 4 point bonus)
There are essentially two kinds of IS managers: those with a solid computer science background, and the other kind. To the other kind, computers are magic
Always good to start off with an irrational assertion.
If your site can hold up on the average day, it should have no problem this weekend.
So you know the status of my electric utility, and the capabilities of my UPS?
There will not be a reign of terror by computer criminals
which is not the only reason to go offline
oh yes, if your IS manager calls them "hackers", that's another sign he's not a computer science pro
Right. Using the wrong word is a clear indication of stupidity. And if you say "Afro-American" or "black" instead of "African-American", you're a racist. Thhhppppt!
There are lots of factors, costs, and probabilities that a rational business must take into account when deciding if they should go offline. Like factors beyond the companies' control. Like expected benefit/revenue of staying online and the cost of dealing with a worst-case scenario.
If a company expects to take in some 1 percent of an average days' sales between 11pm and 1am on New Year's (who's shopping, really?), but their systems would cost millions of dollars and three days (== something like 250 times as much revenue as they would lose in a volunatry, two-hour shutdown, plus hardware and staff costs) to restore if heavily damaged in a worse-case-scenario, then who could blame them for giving up very small profits in order to be certain they avoid very high costs?
Bruce, you're getting hyterical about the "technology" and missing the business case. You don't really think we're going to see a headline in the Wall Street Journal like "Ford overtakes General Motors in Q4 1999 due to GM Web site being offline for 120 minutes", or "Amazon underperforms; missed out on big New Year's Eve midnight sales", do you?
"robots.txt" is terrible; not only does in not support regular expressions, it doesn't even glob well.
Instead of asking robots to parse based on URL, we should have a new attribute for to indicate that the link could/should be followed. At the simplest level, this could look like INDEX="yes", but this could be extended in various ways, e.g. telling the spider if it needs to accept/send cookies, indicating a range of hours (in GMT) that the spider should restrict its queries to, etc.
The point is, when they spam you, they add your email address in the message on their end. Sending an email to journey@jps.net? Your image callout would be "foo.gif?journey@jps.net". It won't matter if your browser thinks you're president@whitehouse.gov.
Added fun: if you receive mail at multiple addresses, they can relate all those email addresses to the same cookie set. Including emails you might receive through anonymizing systems, e.g. they'd know that "862139@anon.penet.fi"[1] was the same user as "journey@jps.net".
We also use Java for the client, instead of just a web browser, so we can protect the client enviroment a little more against trojan horses and to make the digital certs easier.
This seems a very small improvement. By using the GUI virtual keyboard, you prevent the simplest client-side cracks like key-capture apps, but you're still trusting the JVM. Especially with projects like Kaffe, the JVM isn't much more trustworthy than an OS. You've raised the bar a bit, but only a bit.
The keys-on-floppies is almost a nice idea. What I'd like to see is a durable, relatively inexpensive smart hardware device that interfaced the computer via a floppy drive. You'd have a keypad and display about the size of a floppy, with a flexible ribbon attaching it to the computer interface. The computer would send a request to the device by "writing a file" and would pick up the response by "reading a file". For the poor iMac users, you might have an optional USB interface. [I like the idea of a USB-connected smart device, except 1) you'd want some sort of retractable cable to allow the keypad/display to be positioned away from the USB port, and 2) success of the iMac notwithstanding, 3.5 inch floppies are much more prevalent and better supported than USB.]
I just imagine lots of docs copying their floppies and challenge-response sheets so they won't have to lug them around. With a smart hardware device, that would not be an option, and you'd address the problem of compromised client machines.
Could someone please explain the feedback mechanism and post some sample ipchains/ipfwadm rules to disable it? Mainly I think we need to know what the destination networks/ports and protocol type are. Does it use HTTP through a proxy so that Squid, etc. need to be reconfigured, etc.?
I just got word from the Handspring folks that the source code package is available on their Web site, same page as the binary package. Problem solved.
There's another problem that I thought Slashdot would care more about. Last week, Handspring released their "PalmOS GNU Tools" Spftware Development Kit, which, by the admission of their own included documentation, is based on GNU's gcc tools. The problem is that Handspring is in violation of GPL Section 3, insofar as they have not made the required offer to make the source for their "GNU Tools" available. (Their documentation says that "The source code to the GNU tools is freely available on the Internet under terms of the GNU General Public License as are all derivatives based on the GNU source code, including the [PalmOS GNU Tools]." but does not give any indication where.)
Handspring is not responding to emailed questions about the problem. Word on usenet is that they plan to release the source, but not now, and maybe not for the current version. Of course GPL Sections 5 and 7 clearly state that you can't distribute derivative works unless you're prepared to offer source at the same time.
-Peter, no longer so enthusiastic about Handspring
So I've got my username and password, but none of the Test Drive systems recognize me. Does anyone know how long it takes for accounts to be activated after Compaq sends you a password?
Slashdot Mirror
The author in his reply admitted that he intended to "provoke--and even promote some flame mail" so that he might learn what people really thought. I did not, could not, reply to that.
Over the last few years I've seen similar behavior very often from Metcalfe; he's really not worth reading anymore.
Don't take these trade rag hacks seriously. It's a waste of cycles.
-Peter
Otherwise, I've found that Netscape will request weird URL's of my local httpd. In most cases this just means broken images, but in some cases the page refuses to load when the "ad" SRC sends a 404 error or somesuch.
-Peter
This seems to be working for me.
Andover folks: I only do this for ad sites that use stuff like <SCRIPT> tags to bypass my "originating server" cookie settings, as link4ads.com does. I make no attempt to block the normal (adfu?) ads, and I do click through those sometimes. But if you want to send a third-party tracking cookie with the ads, sorry, I refuse.
-Peter
Yeah, finding the attackers will take some hard work. But hard work is what's needed to solve this problem.
First we started to track down open SMTP relays. Now we need to hunt down underprotected routers.
Are the high-profile victims doing that? Where's the evidence?
Also, I suspect a lot of sites with distributed server farm architectures quietly pulled some servers offline last night, voluntarily reduced capacity to be safe. Just as conservative, but not as visible. We may never know.
Happy new year.
-Peter
I love how you totally skip my rational, cost-benefit-risk argument and latch onto one minor thread. Actually, I don't know the readiness of any system outside my control. External systems cannot be completely trusted: sure, they vendor may certify compliance/readiness, but I've got no way of verifying that. You mention the fact that many utilities have extra staff on duty tonight. Why? Could it be, oh, that they suspect/fear something may go wrong? Are they, too, "irrational and fearful" (you mean to say "stupid", don't you?) for taking extra precautions? How do you know your utility is ready? What first hand, direct evidence have you gathered?
Case in point: some power utilities sell, and ship, power across state borders to other utilities. They can test their systems, but can they really help test, or witness tests, of all the other utilities they might depend on? No. Everyone is dealing with some uncertainty when it comes to other people's systems. Everyone.
As I said, the chance of the infrastructure failing dramatically is very slim (and everything seems to be going fine), but the costs of worst-case failures will, in almost all Web commerce systems, vastly outweigh the costs of revenues lost by brief downtimes.
If my site crashes, then, yeah, it's likely (though not necessarily) my fault. But we're not talking about crashes, Bruce. We're talking about voluntary shutdowns. While I agree that these shutdowns could be called "fearful", they're anything but "irrational".-Peter
There are lots of factors, costs, and probabilities that a rational business must take into account when deciding if they should go offline. Like factors beyond the companies' control. Like expected benefit/revenue of staying online and the cost of dealing with a worst-case scenario.
If a company expects to take in some 1 percent of an average days' sales between 11pm and 1am on New Year's (who's shopping, really?), but their systems would cost millions of dollars and three days (== something like 250 times as much revenue as they would lose in a volunatry, two-hour shutdown, plus hardware and staff costs) to restore if heavily damaged in a worse-case-scenario, then who could blame them for giving up very small profits in order to be certain they avoid very high costs?
Bruce, you're getting hyterical about the "technology" and missing the business case. You don't really think we're going to see a headline in the Wall Street Journal like "Ford overtakes General Motors in Q4 1999 due to GM Web site being offline for 120 minutes", or "Amazon underperforms; missed out on big New Year's Eve midnight sales", do you?
Get real.
-Peter
Instead of asking robots to parse based on URL, we should have a new attribute for to indicate that the link could/should be followed. At the simplest level, this could look like INDEX="yes", but this could be extended in various ways, e.g. telling the spider if it needs to accept/send cookies, indicating a range of hours (in GMT) that the spider should restrict its queries to, etc.
The point is, when they spam you, they add your email address in the message on their end. Sending an email to journey@jps.net? Your image callout would be "foo.gif?journey@jps.net". It won't matter if your browser thinks you're president@whitehouse.gov.
Added fun: if you receive mail at multiple addresses, they can relate all those email addresses to the same cookie set. Including emails you might receive through anonymizing systems, e.g. they'd know that "862139@anon.penet.fi"[1] was the same user as "journey@jps.net".
-Peter
[1] RIP
The keys-on-floppies is almost a nice idea. What I'd like to see is a durable, relatively inexpensive smart hardware device that interfaced the computer via a floppy drive. You'd have a keypad and display about the size of a floppy, with a flexible ribbon attaching it to the computer interface. The computer would send a request to the device by "writing a file" and would pick up the response by "reading a file". For the poor iMac users, you might have an optional USB interface. [I like the idea of a USB-connected smart device, except 1) you'd want some sort of retractable cable to allow the keypad/display to be positioned away from the USB port, and 2) success of the iMac notwithstanding, 3.5 inch floppies are much more prevalent and better supported than USB.]
I just imagine lots of docs copying their floppies and challenge-response sheets so they won't have to lug them around. With a smart hardware device, that would not be an option, and you'd address the problem of compromised client machines.
-Peter
Could someone please explain the feedback mechanism and post some sample ipchains/ipfwadm rules to disable it? Mainly I think we need to know what the destination networks/ports and protocol type are. Does it use HTTP through a proxy so that Squid, etc. need to be reconfigured, etc.?
I just got word from the Handspring folks that the source code package is available on their Web site, same page as the binary package. Problem solved.
Handspring is not responding to emailed questions about the problem. Word on usenet is that they plan to release the source, but not now, and maybe not for the current version. Of course GPL Sections 5 and 7 clearly state that you can't distribute derivative works unless you're prepared to offer source at the same time.
-Peter, no longer so enthusiastic about Handspring
-Peter