"this is the way the OS asks applications to behave"
Where does Windoze ask that applications should run anything they find, from any source, any way they can figure out how, without asking the user first?
It must be the same place that Linux asks applications to run anything they can find in the/etc/mailcap without asking first. (BTW, Mozilla does not do that, because it would be dangerous. What a concept.)
"the only thing I see at this point is that they need to start maintaining a black list of protocol schemes"
Arggh! No! They (the Mozilla developers) should assume everything external is dangerous, because they have no control over it. Mozilla should prompt the user with a variation on the same "Save/Open/Cancel" dialog they use for other external handlers. That way, the user has to take a very specific action to invoke an external handler.
This doesn't solve the problem of stupid users (who will open anything), of course, but that is not a Mozilla problem.
"Mozilla doesn't do what you described... it doesn't hand off any executable to the OS."
No, it hands off an arbitrary command to the OS, which (for purposes of security) is the same damn thing.
"All three platforms [*doze, Mac, *nix] use external protocol handlers to register helper applications."
Yes. On *nix, you can find/etc/mailcap for that sort of thing. The critical difference is that Mozilla does not blindly run anything it finds in/etc/mailcap without asking the user first.
"The part that I think is significant is that the OS registered a protocol handler that isn't safe in an internet context. "
I do not believe that there is anything in MS-Windows that promises the protocol registry is always safe to use. It's simply a mechanism for mapping "protocols" to "handles". It is not a mechanism for displaying Internet content.
"why the hell would you want a "run any program" protocol handler?"
For a generallize shell interface (which *doze has), it makes sense to have a "default protocol" which handles everything. Again, *nix has similar things ("if an executable file's type cannot be determined, run it through/bin/sh and hope for the best"). Sure, Mozilla does not invoke those capabilites, because doing so from an untrusted source (the Internet) is dangerous. So why does Mozilla do it on *doze?
I can't believe I'm defending Microsoft Windows, but the fact of the matter is, there was a clear danger here, and the Mozilla people have known about it for years. (See another of my comments in this thread for details.) This should have been fixed a long time ago. (Again, the fact that it was not fixed just means that the Mozilla people are fallible, just like all other humans.)
"It's not a Mozilla issue. It's an issue with using an OS which keeps a registry. It's an issue with users who demand to be able to open any data format in any application and have the OS automatically spawn the correct application because the users can't be bothered to match data types with applications."
I guess that means that *nix is also a lousy OS.
(Hint: Look up what/etc/mailcap does some time.)
The issue is not that Mozilla spawns external programs. The issue is that Mozilla does so without asking.
I prefer postmaster@[site]. Internet standards require postmaster be a working mailbox (not everyone follows the standards, but many/most do). I also find webmaster@[any-domain] tends to gets tons of dictionary-attack spam, thus making it more likely to be filtered already. Most (not all!) spammers filter out postmaster@[all-domains] (spammers may be stupid, but they're not *that* stupid). Finnally, postmaster@ is, I suspect, more likely to be read by people who care (sysadmins rather then marketing weenies).
"...and I check all of the "Email me adverts for all this shit!" boxes, too."
I never do that. I also check off whatever "opt-out" options the form offers. That way, they are encouraged to adhere to their own policies. If they do not spam unless you ask them to, then postmaster@ will not be spammed. If they send stuff without asking, then postmaster@ gets it.
Alas, more and more registration forms check for obvious things like a domain the organization already operates.
"Agreed. It's not really a bug in the browser, it's a flaw in Windows."
I disagree. I feel this is a Mozilla problem. (It may be a Windows problem, too, but that's not the issue here.)
Let me explain in terms of Linux, another Slashdot favorite:
I run mainly Linux on my home and work PCs. The Linux OS looks at the start of any executable file to determine how to run said file. If it recognizes a particular "magic number", it invokes the appropriate handler (ELF, a.out, Java, etc.). If it recognizes a she-bang line (first line starts with "#!" followed by the path to a program), it will run that program. Otherwise, Linux feeds the executable to the default shell (/bin/sh) and hopes for the best.
The fact that my OS can do all of these things does not mean I want Mozilla to do them. If I click a link that leads to an executable file on the web, I do not want Mozilla to hand-off the executable to the host OS (Linux) to see if Linux can find a way to run said executable.
The security exposure is apparently due to the fact that Mozilla, running on MS-Windows, will hand off any "URI scheme" Mozilla does not recognize to the OS. This only happens on MS-Windows. Since Windows may (and indeed, does, by default) know about URI schemes that do things you would not want a web page doing (like run programs), this is considered a problem for Mozilla.
I have to agree that this is a Mozilla issue. To use a slightly contrived comparison: I read my mail using UW Pine. If someone sends me a script via attachment in email, I do not want Pine to test and see if the interpreter in the she-bang line is available on the host OS. My OS is not my mail reader; I do not want my mail reader allowing everything my OS can do. Ditto my web browser.
There appear to be at least three Mozilla Bugzilla Bugs related to this (likely a lot more):
#1 = Mozilla Bug 163767 (20 Aug 2002) "Pref to disable external protocol handlers" http://bugzilla.mozilla.org/show_bug.cg i?id=163767
#2 = Mozilla Bug 167475 (9 Sep 2002) "Disable external protocol handlers in all cases, excluding <A HREF" http://bugzilla.mozilla.org/show_bug.cgi?id =167475
#3 = Mozilla Bug 250180 (7 Jul 2004) "Shell: protocol allows access to local files" http://bugzilla.mozilla.org/show_bug.cgi?i d=250180
It appears that Mozilla developers have been worried about this kind of problem going back to at least Aug 2002 (see #1 above). #1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.
#2 talks about an approach that uses context to determine if an external handler should be invokved. Basically, it assumes that if a user clicked a link, they wanted to invoke the handler; anything that happened implictly (such as image loading) should not invoke an external handler. I do agree with those who commented (in that bug) that this is not the right approach. It adds complexity, and it still fails to address the fact that clicking a link is not something that should just up and run anything the web page wants. If I wanted that, I'd use MSIE.
#3 is a reference to the "shell:" URI scheme in particular being abused this way. It blocks the "shell:" scheme to prevent that abuse. It does nothing to prevent abuses of other possible schemes, though. I suspect we may see this "feature" of Mozilla rear its ugly head again in the future.
This is not a failure of Open Source in particular. Nor does it prove Mozilla is crap or Microsoft is okay after all. It means that people make mistakes. This should not surprise anyone. Stop pointing fingers and fix the problem.
It appears that, at around 8:30 AM EDT (US Eastern Daylight Time), Akamai's DNS network experiened some kind of major failure. All of their DNS servers (that anybody could find) were not responding to DNS queries. It appears that Akamai started to come back online at around 10:00 AM EDT.
Since a great many big name sites use Akamai, this effectively made large parts of the Internet unreachable. The destination servers themselves were up, but clients were unable to turn names (like www.example.com) into network addresses (like 192.0.2.42).
As Akamai maintains dozens, if not hundreds, of DNS servers across the globe, it is extremely unlikely that this was due to a normal equipment failure or DoS attack. Some kind of internal system trouble is much more likely. Whether a deliberate attack, or an accident, is unknown to me at this time. It could just be an internal configuration change blew up in a really bad way. Sh*t happens.
I do not know if this was just an Akamai DNS problem, or if other Akamai services were also affected.
Due to the way Akamai is usually implemented, it happened that, in many cases, the second-level domain names (like example.com) worked, but subdomains (like www.example.com and mail.example.com) did not. This is because most organizations put in CNAME records (pointing to names in *.akadns.net) for the subdomains. You cannot use a CNAME record for a domain that has other records, though, so most domains still had traditional A records, on their own nameservers, at the second-level.
The following sites/organizations are known to use Akamai: Yahoo, Google, Microsoft, Altavista, FedEx, Xerox, Apple
I was thinking about this while scrambling to answer the phone, check outage reports, and generally calm down customers.
If a product or service, such as Akamai, does their job very well, everybody will want to use them. If everybody uses them, you create a single point-of-failure. Any design flaw in that product or service becomes a disaster, simply through volume. Does this mean a successful product or service can actually be a bad thing for people?
Other examples include just about anything from Microsoft, older versions of Sendmail and BIND (worm-of-the-week problem), and Firestone tires.
(I'm not trying to advocate communism, excessive government regulation, or anything like that. So fanatical libertarians, conspiracy theorists, etc., can put down the rant-o-matic flamethrowers.:) )
Can't load any of the images. It appears the ops for the nameservers for the sdk-team.com web servers just yanked the A record right out of their DNS zone. I guess that's one way to stop a Slashdotting.
When it comes to budget, "if it ain't broke, don't fix it" rules the day. Companies would prefer to keep using the same computer systems forever, if they did the job. And I cannot say that's really a wrong attitude.
Of course, at many companies, the attitude is "even if it is broke, don't fix it unless it's stopping production outright". I just spent two weeks in a rather insane upgrade-a-thon at a customer, because they got bought by a larger company, and their new corporate IT department nearly had a heart attack when they saw the state of their systems. Many computers were stilling running Windows 95. Their main server was running Novell NetWare 4.11. These products are ten years old, unsupported, obsolete, and flat out broken. Win95 can't even get a DHCP lease without three patches (Y2K bugs). Oh, and a fleet of ten megabit unmanaged repeaters. And dead anti-virus software. And missing the disks for the backup software. And...
When corporate deployed their anti-virus software to this site, it darn near exploded. Over 8000 infected files on one PC alone. Their WAN guys were screaming bloody murder about all the worm traffic coming from this site.
It was great fun. For sufficiently small definitions of "fun".
And, like I said, that's murky. Where do you define "first"? You state, "If the BBS initiates the transfer not at the behest of the user, the system is uploading to the user's system." Well, lets' talk about that timed event in the BBS system that sends a file to the user at a given time, regardless of where they are in the system. By your definition, of the sysop of the board sets up the timed event, the BBS is uploading to the PC. But if the user sets up the timed event, the PC is downloading from the BBS. Same software and mechanisms and actions on both ends, both times. That's inconsistent.
But, if we define "upload" to mean "send" and "download" to mean "receive", then in all of the timed event cases, the BBS is uploading to the PC, and the PC is downloading from the BBS. Consistent and symmetric.
Consider the venerable XModem protocol. There is no way for one end to signal the other in XModem. So, to transfer a file with XModem, one end has to start sending, and the other end has to start receiving. In the case of a person using a menu system like a BBS, then the send on the BBS might be trigger by the user in the menu system, who then commands his terminal emulator to receive. But what about two terminal emulators connected head-to-head? Now a person at both ends is invoking the menu commands. Likewise, what about two scripted systems running unattended? Now no human being is involved.
Remember, we're talking about computers here. Users don't actually transfer files. Computers do. Instructions have to execute for anything to happen, and that means both ends have to do something.
You use the term "passive action". That's a contradiction in terms, an oxymoron. Passive is, by definition, the lack of action. Active is, by definition, the presence of action. You cannot have a "passive action" any more then you can have a "dry wet".
You claim receiving is involuntary. Not at all. Perhaps it might be in the physical world, but not in terms of file transfers. Both sides have to participate in a file transfer. If a BBS (or an Internet host, for that matter) starts sending without the far end taking action to receive, then the data is discarded, and no transfer takes place.
"The definitions I always understood had downloading be pulling and uploading be pushing, both being active actions. Push and pull; put and get; give and take."
I'm with you on everything but the "active actions" part. (Again, by definition, all actions are active.)
Push and pull is fine. But when one end pulls, the other end has to push. Think of a rope; if two people are each holding a rope taught, one has to push the rope for the other to pull.
Give and take is fine. But if you want to give something to me, I have to take it. If I refuse to take it, you can't give it to me. Likewise, you can't take something from me unless I let you; unless I give it to you.
In all cases, both ends are involved. You simply cannot transfer data between two systems unless both ends are involved.
"...this becomes important legislatively regarding penalties for uploading or downloading files. If you divest the definitions of active actions, you can't assign culpability. So both must be defined actively."
That's bunk, too. Any law that attempts to say "uploading" is okay but "downloading" is not is insane. But fortunately, we don't need to worry about that. You don't outlaw uploading or downloading files. Those are not intrinsically good or bad behaviors. You outlaw things like copying data without permission, or modifying a system without permission.
Yah. Total agreement with the parent, especially on XML/OOP/COBOL.
"There is no silver bullet", as Fred Brooks says.
Which gives me an opportunity to plug one of my favorite non-fiction books. Anyone who is interested in computer engineering or history and has not read Fred Brooks's classic The Mythical Man-Month should do so as soon as possible. I am continually amazed that most of the problems we're facing today in 2003 are the same ones early software engineers were facing in 1955. If anything, things have gotten worse, not better.
"Upload/download also refers to who is initiating the action."
This is the way I've always used the terms:
download: v. To receive data from another computer/system. upload: v. To send data to another computer/system.
That definition is easily understood and less ambiguous.
"But if you're downloading data from a site, the site is not also uploading that data to you."
I disagree. A "download" is always paired with an "upload". One end of the transfer has to call a program (subroutine, whatever) which sends the data, and the other end has to call a program which receives it. You have to have both. Every action has an equal but opposite reaction. Call it "Dragonhawk's First Law of Data Transmission".:-)
"The action exists at only one end of the operation, at the initiator of the action."
Trying to talk about who "initiated" the transfer can get murky. For example: The ZModem file transfer protocol can automatically signal the other end to start a transfer. This was typically used by interactive menu systems connected to terminal emulators -- BBSes and PCs, to use the popular terms. The user, at the PC, hits a key to select a file. The BBS gets that keystroke, and sends the signal to start the transfer. The BBS is sending and the PC is receiving, but who really initiated that transfer? The BBS software because it sent the signal? Or the user, because he hit the button? What about if the BBS has some kind of timed event to automatically send a file at a given time? What if the PC does that in a script?
(I suspect this is a troll, but I want to debunk this particular myth anyway.)
MSIE has been doing this for ages, and I never found it to be a problem
Microsoft Internet Explorer isn't the Internet. MSIE is one program that some people use for one task -- browsing the web. You don't have to use it. MSIE is also not a mail exchanger, diagnostic tool, or any of the many other things that this VeriSign change breaks.
If you run a nameserver and want to return NXDOMAIN instead of Verisign's IP, add this code to your named.conf if you are running BIND 9.2.2
zone "11.110.94.64.in-addr.arpa" { type master; allow-query { none; }; };
Uh, no.
That only affects reverse lookups (number-to-name)( on that IP address. That has virtually no consequence. Forward lookups (name to number) still work the way VeriSign wants them to.
It also doesn't result in NXDOMAIN; it just causes your nameserver to refuse the query.
That would leave browsers waiting to timeout. ICMP-Rejects wouldn't be much better.
Uh, no. A "null-route" means there is no route. Not "drop packets do this destination" but "there is no way to reach this destination". That will result in an ICMP "destination unreachable" message being sent back to the originator, which should be interpreted properly by any program worth a damn.
Verisign will add some more numbers, and soon we'll have blacklists.
That possability has occured to me and many others, too. However, as VeriSign is a single entitity, it should be pretty easy to keep tabs on them.
Well, it would depend on the resolver you use, but I would still expect the answer to be "no". But I've already seen public discussion over how to patch ISC BIND to do it. And that was hours ago.
Of course, if you use a closed-source resolver, you're be stuck. But then, you knew that, right?:-)
I feel it is worthwhile to post a more general response to this point as well.
There is this myth that "the Internet" exists as a single, cohesive network. It does not, and never has. "The Internet" is a network of networks. What that means is that a bunch of independent network operators have agreed to exchange traffic with each other because it benefits them. When you dial in to your ISP of choice (or plug in your Ethernet cable or whatever), you're not connecting to the Internet. You're connecting to your ISP. Your ISP probably connects to their ISP. Their ISP (if you're lucky) connects to several other ISPs, who connect to other ISPs, and so on. All these independent network operators form "the Internet". So, "the Internet" exists as an abstract concept (and a useful one), but not as something you can touch. Not even as something you can route traffic through. All you can do is connect to some other guy's network and hope for the best.
The reason this is important is because we are already seeing ISPs implementing countermeasures against this VeriSign move. Some are null-routing that IP address at layer two; others are using DNS tricks to give us the old behavior. If enough ISPs do this, VeriSign's move will be largely ineffective. In effect, ISPs as a community can veto VeriSign or anyone else. It only works if most of them agree and take action, of course, and it remains to be seen if they will do that. And, of course, some of these countermeasures may themselves be easily defeated, leading to an arms race (like the spammer vs anti-spam arms race).
The possible consequences of all this are, shall we say, interesting.
(BTW, I don't disagree with the OP's suggested course of action, nor with the principle behind it. I'm just pointing out that things are, as usual, more complicated then they might appear.)
they were granted the power to run the root servers and manage primary DNS by the federal government.
Actually, the US government transferred that to ICANN some time ago. ICANN currently contracts VeriSign to run the SOA for the roots and GTLDs, and other companies and organizations run the other nameservers.
Of course, ICANN could drop the hammer on VeriSign, but given ICANN's past performance, I doubt they will. Apparently, other TLD operators have already tried this, and the slap on the wrist was easily ignored.
FYI, that IP address (64.94.110.11) is being null-routed by many ISPs. For example, it is unreachable from my home ISP right now, but if I SSH into work, I can reach it from there. I've also heard of ISPs configuring their resolvers to return NXDOMAIN for any query that returns an A record with that IP address.
Okay, everybody and their brother is trying to resolve "bogusdomainname.com" or whatever and finding they get a NXDOMAIN error (as they should). There are a lot of possible reasons for this, which I will simply handwave as "caching".
To see the real thing in action, query an authoritative nameserver directly. For example:
$ host www.bogusdomainname.com Host www.bogusdomainname.com not found: 3(NXDOMAIN) $ host www.bogusdomainname.com a.gtld-servers.net Using domain server: Name: a.gtld-servers.net Address: 192.5.6.30#53 Aliases:
www.bogusdomainname.com has address 64.94.110.11 $
The first query uses the default resolver on my system, which is a local named which in turn forwards to my ISP's resolvers, which do who knows what. The second query says to ask a.gtld-servers.net, which causes the host utility to send the query directly to one of the authoritative nameservers for the GTLDs (Global Top Level Domains, as opposed to country-specific domains like.us). Then I see the current authoritative response.
In the event of a large scale failure, you can have huge surges and sags in the power grid. The effect then spreads out over the grid and reaches other power stations and equipment. Those systems see it for the problem it is and automatically shutdown to avoid damage. ("Shutdown" might be a bit of a euphemism; it could be something as simple as a very large fuse blowing.) We are talking about systems with hundreds of thousands of volts and an ungodly current capacity here. It's one thing if your CRT gets hit with a surge and smokes. At a major power plant, it could be like a bomb going off. Far better to have a major outage that takes a few hours to clean up, then a cascade failure that does lasting damage everywhere.
It is also worth pointing out that Niagara Falls provides a huge amount of power to the surrounding regions. A failure there could mean a serious loss of capacity.
Slashdot Mirror
"this is the way the OS asks applications to behave"
/etc/mailcap without asking first. (BTW, Mozilla does not do that, because it would be dangerous. What a concept.)
Where does Windoze ask that applications should run anything they find, from any source, any way they can figure out how, without asking the user first?
It must be the same place that Linux asks applications to run anything they can find in the
"the only thing I see at this point is that they need to start maintaining a black list of protocol schemes"
Arggh! No! They (the Mozilla developers) should assume everything external is dangerous, because they have no control over it. Mozilla should prompt the user with a variation on the same "Save/Open/Cancel" dialog they use for other external handlers. That way, the user has to take a very specific action to invoke an external handler.
This doesn't solve the problem of stupid users (who will open anything), of course, but that is not a Mozilla problem.
"Mozilla doesn't do what you described... it doesn't hand off any executable to the OS."
/etc/mailcap for that sort of thing. The critical difference is that Mozilla does not blindly run anything it finds in /etc/mailcap without asking the user first.
/bin/sh and hope for the best"). Sure, Mozilla does not invoke those capabilites, because doing so from an untrusted source (the Internet) is dangerous. So why does Mozilla do it on *doze?
No, it hands off an arbitrary command to the OS, which (for purposes of security) is the same damn thing.
"All three platforms [*doze, Mac, *nix] use external protocol handlers to register helper applications."
Yes. On *nix, you can find
"The part that I think is significant is that the OS registered a protocol handler that isn't safe in an internet context. "
I do not believe that there is anything in MS-Windows that promises the protocol registry is always safe to use. It's simply a mechanism for mapping "protocols" to "handles". It is not a mechanism for displaying Internet content.
"why the hell would you want a "run any program" protocol handler?"
For a generallize shell interface (which *doze has), it makes sense to have a "default protocol" which handles everything. Again, *nix has similar things ("if an executable file's type cannot be determined, run it through
I can't believe I'm defending Microsoft Windows, but the fact of the matter is, there was a clear danger here, and the Mozilla people have known about it for years. (See another of my comments in this thread for details.) This should have been fixed a long time ago. (Again, the fact that it was not fixed just means that the Mozilla people are fallible, just like all other humans.)
"It's not a Mozilla issue. It's an issue with using an OS which keeps a registry. It's an issue with users who demand to be able to open any data format in any application and have the OS automatically spawn the correct application because the users can't be bothered to match data types with applications."
/etc/mailcap does some time.)
I guess that means that *nix is also a lousy OS.
(Hint: Look up what
The issue is not that Mozilla spawns external programs. The issue is that Mozilla does so without asking.
"I usually use webmaster@ ..."
I prefer postmaster@[site]. Internet standards require postmaster be a working mailbox (not everyone follows the standards, but many/most do). I also find webmaster@[any-domain] tends to gets tons of dictionary-attack spam, thus making it more likely to be filtered already. Most (not all!) spammers filter out postmaster@[all-domains] (spammers may be stupid, but they're not *that* stupid). Finnally, postmaster@ is, I suspect, more likely to be read by people who care (sysadmins rather then marketing weenies).
"...and I check all of the "Email me adverts for all this shit!" boxes, too."
I never do that. I also check off whatever "opt-out" options the form offers. That way, they are encouraged to adhere to their own policies. If they do not spam unless you ask them to, then postmaster@ will not be spammed. If they send stuff without asking, then postmaster@ gets it.
Alas, more and more registration forms check for obvious things like a domain the organization already operates.
"Agreed. It's not really a bug in the browser, it's a flaw in Windows."
I disagree. I feel this is a Mozilla problem. (It may be a Windows problem, too, but that's not the issue here.)
Let me explain in terms of Linux, another Slashdot favorite:
I run mainly Linux on my home and work PCs. The Linux OS looks at the start of any executable file to determine how to run said file. If it recognizes a particular "magic number", it invokes the appropriate handler (ELF, a.out, Java, etc.). If it recognizes a she-bang line (first line starts with "#!" followed by the path to a program), it will run that program. Otherwise, Linux feeds the executable to the default shell (/bin/sh) and hopes for the best.
The fact that my OS can do all of these things does not mean I want Mozilla to do them. If I click a link that leads to an executable file on the web, I do not want Mozilla to hand-off the executable to the host OS (Linux) to see if Linux can find a way to run said executable.
Make sense?
The security exposure is apparently due to the fact that Mozilla, running on MS-Windows, will hand off any "URI scheme" Mozilla does not recognize to the OS. This only happens on MS-Windows. Since Windows may (and indeed, does, by default) know about URI schemes that do things you would not want a web page doing (like run programs), this is considered a problem for Mozilla.
g i?id=163767
d =167475
i d=250180
I have to agree that this is a Mozilla issue. To use a slightly contrived comparison: I read my mail using UW Pine. If someone sends me a script via attachment in email, I do not want Pine to test and see if the interpreter in the she-bang line is available on the host OS. My OS is not my mail reader; I do not want my mail reader allowing everything my OS can do. Ditto my web browser.
There appear to be at least three Mozilla Bugzilla Bugs related to this (likely a lot more):
#1 = Mozilla Bug 163767 (20 Aug 2002)
"Pref to disable external protocol handlers"
http://bugzilla.mozilla.org/show_bug.c
#2 = Mozilla Bug 167475 (9 Sep 2002)
"Disable external protocol handlers in all cases, excluding <A HREF"
http://bugzilla.mozilla.org/show_bug.cgi?i
#3 = Mozilla Bug 250180 (7 Jul 2004)
"Shell: protocol allows access to local files"
http://bugzilla.mozilla.org/show_bug.cgi?
It appears that Mozilla developers have been worried about this kind of problem going back to at least Aug 2002 (see #1 above). #1 talks about an option to disable external protocol handlers (URI schemes) by default. I have to say that would be the right thing to do. "Secure by default" is the correct approach.
#2 talks about an approach that uses context to determine if an external handler should be invokved. Basically, it assumes that if a user clicked a link, they wanted to invoke the handler; anything that happened implictly (such as image loading) should not invoke an external handler. I do agree with those who commented (in that bug) that this is not the right approach. It adds complexity, and it still fails to address the fact that clicking a link is not something that should just up and run anything the web page wants. If I wanted that, I'd use MSIE.
#3 is a reference to the "shell:" URI scheme in particular being abused this way. It blocks the "shell:" scheme to prevent that abuse. It does nothing to prevent abuses of other possible schemes, though. I suspect we may see this "feature" of Mozilla rear its ugly head again in the future.
This is not a failure of Open Source in particular. Nor does it prove Mozilla is crap or Microsoft is okay after all. It means that people make mistakes. This should not surprise anyone. Stop pointing fingers and fix the problem.
It appears that, at around 8:30 AM EDT (US Eastern Daylight Time), Akamai's DNS network experiened some kind of major failure. All of their DNS servers (that anybody could find) were not responding to DNS queries. It appears that Akamai started to come back online at around 10:00 AM EDT.
Since a great many big name sites use Akamai, this effectively made large parts of the Internet unreachable. The destination servers themselves were up, but clients were unable to turn names (like www.example.com) into network addresses (like 192.0.2.42).
As Akamai maintains dozens, if not hundreds, of DNS servers across the globe, it is extremely unlikely that this was due to a normal equipment failure or DoS attack. Some kind of internal system trouble is much more likely. Whether a deliberate attack, or an accident, is unknown to me at this time. It could just be an internal configuration change blew up in a really bad way. Sh*t happens.
I do not know if this was just an Akamai DNS problem, or if other Akamai services were also affected.
Due to the way Akamai is usually implemented, it happened that, in many cases, the second-level domain names (like example.com) worked, but subdomains (like www.example.com and mail.example.com) did not. This is because most organizations put in CNAME records (pointing to names in *.akadns.net) for the subdomains. You cannot use a CNAME record for a domain that has other records, though, so most domains still had traditional A records, on their own nameservers, at the second-level.
The following sites/organizations are known to use Akamai: Yahoo, Google, Microsoft, Altavista, FedEx, Xerox, Apple
I was thinking about this while scrambling to answer the phone, check outage reports, and generally calm down customers.
:) )
If a product or service, such as Akamai, does their job very well, everybody will want to use them. If everybody uses them, you create a single point-of-failure. Any design flaw in that product or service becomes a disaster, simply through volume. Does this mean a successful product or service can actually be a bad thing for people?
Other examples include just about anything from Microsoft, older versions of Sendmail and BIND (worm-of-the-week problem), and Firestone tires.
(I'm not trying to advocate communism, excessive government regulation, or anything like that. So fanatical libertarians, conspiracy theorists, etc., can put down the rant-o-matic flamethrowers.
Comments?
Can't load any of the images. It appears the ops for the nameservers for the sdk-team.com web servers just yanked the A record right out of their DNS zone. I guess that's one way to stop a Slashdotting.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33136
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; AUTHORITY SECTION:
$ dig +nocmd +noques +nostat www.sdk-team.com. @ns2.01asp.net. ANY
sdk-team.com. 86400 IN SOA ns1.01asp.net. support.01asp.net. 20110810 10800 3600 604800 86400
When it comes to budget, "if it ain't broke, don't fix it" rules the day. Companies would prefer to keep using the same computer systems forever, if they did the job. And I cannot say that's really a wrong attitude.
Of course, at many companies, the attitude is "even if it is broke, don't fix it unless it's stopping production outright". I just spent two weeks in a rather insane upgrade-a-thon at a customer, because they got bought by a larger company, and their new corporate IT department nearly had a heart attack when they saw the state of their systems. Many computers were stilling running Windows 95. Their main server was running Novell NetWare 4.11. These products are ten years old, unsupported, obsolete, and flat out broken. Win95 can't even get a DHCP lease without three patches (Y2K bugs). Oh, and a fleet of ten megabit unmanaged repeaters. And dead anti-virus software. And missing the disks for the backup software. And...
When corporate deployed their anti-virus software to this site, it darn near exploded. Over 8000 infected files on one PC alone. Their WAN guys were screaming bloody murder about all the worm traffic coming from this site.
It was great fun. For sufficiently small definitions of "fun".
"The initial actor, the first action."
And, like I said, that's murky. Where do you define "first"? You state, "If the BBS initiates the transfer not at the behest of the user, the system is uploading to the user's system." Well, lets' talk about that timed event in the BBS system that sends a file to the user at a given time, regardless of where they are in the system. By your definition, of the sysop of the board sets up the timed event, the BBS is uploading to the PC. But if the user sets up the timed event, the PC is downloading from the BBS. Same software and mechanisms and actions on both ends, both times. That's inconsistent.
But, if we define "upload" to mean "send" and "download" to mean "receive", then in all of the timed event cases, the BBS is uploading to the PC, and the PC is downloading from the BBS. Consistent and symmetric.
Consider the venerable XModem protocol. There is no way for one end to signal the other in XModem. So, to transfer a file with XModem, one end has to start sending, and the other end has to start receiving. In the case of a person using a menu system like a BBS, then the send on the BBS might be trigger by the user in the menu system, who then commands his terminal emulator to receive. But what about two terminal emulators connected head-to-head? Now a person at both ends is invoking the menu commands. Likewise, what about two scripted systems running unattended? Now no human being is involved.
Remember, we're talking about computers here. Users don't actually transfer files. Computers do. Instructions have to execute for anything to happen, and that means both ends have to do something.
You use the term "passive action". That's a contradiction in terms, an oxymoron. Passive is, by definition, the lack of action. Active is, by definition, the presence of action. You cannot have a "passive action" any more then you can have a "dry wet".
You claim receiving is involuntary. Not at all. Perhaps it might be in the physical world, but not in terms of file transfers. Both sides have to participate in a file transfer. If a BBS (or an Internet host, for that matter) starts sending without the far end taking action to receive, then the data is discarded, and no transfer takes place.
"The definitions I always understood had downloading be pulling and uploading be pushing, both being active actions. Push and pull; put and get; give and take."
I'm with you on everything but the "active actions" part. (Again, by definition, all actions are active.)
Push and pull is fine. But when one end pulls, the other end has to push. Think of a rope; if two people are each holding a rope taught, one has to push the rope for the other to pull.
Give and take is fine. But if you want to give something to me, I have to take it. If I refuse to take it, you can't give it to me. Likewise, you can't take something from me unless I let you; unless I give it to you.
In all cases, both ends are involved. You simply cannot transfer data between two systems unless both ends are involved.
"...this becomes important legislatively regarding penalties for uploading or downloading files. If you divest the definitions of active actions, you can't assign culpability. So both must be defined actively."
That's bunk, too. Any law that attempts to say "uploading" is okay but "downloading" is not is insane. But fortunately, we don't need to worry about that. You don't outlaw uploading or downloading files. Those are not intrinsically good or bad behaviors. You outlaw things like copying data without permission, or modifying a system without permission.
Yah. Total agreement with the parent, especially on XML/OOP/COBOL.
"There is no silver bullet", as Fred Brooks says.
Which gives me an opportunity to plug one of my favorite non-fiction books. Anyone who is interested in computer engineering or history and has not read Fred Brooks's classic The Mythical Man-Month should do so as soon as possible. I am continually amazed that most of the problems we're facing today in 2003 are the same ones early software engineers were facing in 1955. If anything, things have gotten worse, not better.
"Upload/download also refers to who is initiating the action."
:-)
This is the way I've always used the terms:
download: v. To receive data from another computer/system.
upload: v. To send data to another computer/system.
That definition is easily understood and less ambiguous.
"But if you're downloading data from a site, the site is not also uploading that data to you."
I disagree. A "download" is always paired with an "upload". One end of the transfer has to call a program (subroutine, whatever) which sends the data, and the other end has to call a program which receives it. You have to have both. Every action has an equal but opposite reaction. Call it "Dragonhawk's First Law of Data Transmission".
"The action exists at only one end of the operation, at the initiator of the action."
Trying to talk about who "initiated" the transfer can get murky. For example: The ZModem file transfer protocol can automatically signal the other end to start a transfer. This was typically used by interactive menu systems connected to terminal emulators -- BBSes and PCs, to use the popular terms. The user, at the PC, hits a key to select a file. The BBS gets that keystroke, and sends the signal to start the transfer. The BBS is sending and the PC is receiving, but who really initiated that transfer? The BBS software because it sent the signal? Or the user, because he hit the button? What about if the BBS has some kind of timed event to automatically send a file at a given time? What if the PC does that in a script?
(I suspect this is a troll, but I want to debunk this particular myth anyway.)
MSIE has been doing this for ages, and I never found it to be a problem
Microsoft Internet Explorer isn't the Internet. MSIE is one program that some people use for one task -- browsing the web. You don't have to use it. MSIE is also not a mail exchanger, diagnostic tool, or any of the many other things that this VeriSign change breaks.
Please understand the issues before posting.
Null-routing an IP address at layer two is an interesting concept
You're right, of course. I meant layer three. Good catch.
If you run a nameserver and want to return NXDOMAIN instead of Verisign's IP, add this code to your named.conf if you are running BIND 9.2.2
zone "11.110.94.64.in-addr.arpa" { type master; allow-query { none; }; };
Uh, no.
That only affects reverse lookups (number-to-name)( on that IP address. That has virtually no consequence. Forward lookups (name to number) still work the way VeriSign wants them to.
It also doesn't result in NXDOMAIN; it just causes your nameserver to refuse the query.
That would leave browsers waiting to timeout. ICMP-Rejects wouldn't be much better.
Uh, no. A "null-route" means there is no route. Not "drop packets do this destination" but "there is no way to reach this destination". That will result in an ICMP "destination unreachable" message being sent back to the originator, which should be interpreted properly by any program worth a damn.
Verisign will add some more numbers, and soon we'll have blacklists.
That possability has occured to me and many others, too. However, as VeriSign is a single entitity, it should be pretty easy to keep tabs on them.
Any idea if that can be done without code change?
:-)
Well, it would depend on the resolver you use, but I would still expect the answer to be "no". But I've already seen public discussion over how to patch ISC BIND to do it. And that was hours ago.
Of course, if you use a closed-source resolver, you're be stuck. But then, you knew that, right?
(Pre-emptive strike: Insert Matrix-spoon reference here.)
I feel it is worthwhile to post a more general response to this point as well.
There is this myth that "the Internet" exists as a single, cohesive network. It does not, and never has. "The Internet" is a network of networks. What that means is that a bunch of independent network operators have agreed to exchange traffic with each other because it benefits them. When you dial in to your ISP of choice (or plug in your Ethernet cable or whatever), you're not connecting to the Internet. You're connecting to your ISP. Your ISP probably connects to their ISP. Their ISP (if you're lucky) connects to several other ISPs, who connect to other ISPs, and so on. All these independent network operators form "the Internet". So, "the Internet" exists as an abstract concept (and a useful one), but not as something you can touch. Not even as something you can route traffic through. All you can do is connect to some other guy's network and hope for the best.
The reason this is important is because we are already seeing ISPs implementing countermeasures against this VeriSign move. Some are null-routing that IP address at layer two; others are using DNS tricks to give us the old behavior. If enough ISPs do this, VeriSign's move will be largely ineffective. In effect, ISPs as a community can veto VeriSign or anyone else. It only works if most of them agree and take action, of course, and it remains to be seen if they will do that. And, of course, some of these countermeasures may themselves be easily defeated, leading to an arms race (like the spammer vs anti-spam arms race).
The possible consequences of all this are, shall we say, interesting.
(BTW, I don't disagree with the OP's suggested course of action, nor with the principle behind it. I'm just pointing out that things are, as usual, more complicated then they might appear.)
they were granted the power to run the root servers and manage primary DNS by the federal government.
Actually, the US government transferred that to ICANN some time ago. ICANN currently contracts VeriSign to run the SOA for the roots and GTLDs, and other companies and organizations run the other nameservers.
Of course, ICANN could drop the hammer on VeriSign, but given ICANN's past performance, I doubt they will. Apparently, other TLD operators have already tried this, and the slap on the wrist was easily ignored.
FYI, that IP address (64.94.110.11) is being null-routed by many ISPs. For example, it is unreachable from my home ISP right now, but if I SSH into work, I can reach it from there. I've also heard of ISPs configuring their resolvers to return NXDOMAIN for any query that returns an A record with that IP address.
Perhaps I'm missing something here, but wouldn't this open them to all kinds of lawsuits from companies that were affected in that way?
Sure. Are your lawyers better then their lawyers? That's all that matters.
Okay, everybody and their brother is trying to resolve "bogusdomainname.com" or whatever and finding they get a NXDOMAIN error (as they should). There are a lot of possible reasons for this, which I will simply handwave as "caching".
.us). Then I see the current authoritative response.
To see the real thing in action, query an authoritative nameserver directly. For example:
$ host www.bogusdomainname.com
Host www.bogusdomainname.com not found: 3(NXDOMAIN)
$ host www.bogusdomainname.com a.gtld-servers.net
Using domain server:
Name: a.gtld-servers.net
Address: 192.5.6.30#53
Aliases:
www.bogusdomainname.com has address 64.94.110.11
$
The first query uses the default resolver on my system, which is a local named which in turn forwards to my ISP's resolvers, which do who knows what. The second query says to ask a.gtld-servers.net, which causes the host utility to send the query directly to one of the authoritative nameservers for the GTLDs (Global Top Level Domains, as opposed to country-specific domains like
Why in the world is it engineered that way?
In the event of a large scale failure, you can have huge surges and sags in the power grid. The effect then spreads out over the grid and reaches other power stations and equipment. Those systems see it for the problem it is and automatically shutdown to avoid damage. ("Shutdown" might be a bit of a euphemism; it could be something as simple as a very large fuse blowing.) We are talking about systems with hundreds of thousands of volts and an ungodly current capacity here. It's one thing if your CRT gets hit with a surge and smokes. At a major power plant, it could be like a bomb going off. Far better to have a major outage that takes a few hours to clean up, then a cascade failure that does lasting damage everywhere.
It is also worth pointing out that Niagara Falls provides a huge amount of power to the surrounding regions. A failure there could mean a serious loss of capacity.