Tabs at the side would take up even more space than tabs at the top or bottom.
But the space they're taking up is less useful. Increasingly people these days have wide-aspect displays...
And let's not forget that even the "old" aspect ratio displays still had more horizontal pixels than vertical. So even at 640x480, vertical space (top and bottom edges) is at a premium over horizontal space (left and right edges). I've always put my FVMW buttons module along the left size of the screen for that very reason.
With Firefox on my 20" 16:9 display, if I were to resize the window to take up the entire screen, I'd loose out. Most web pages are crafted with a 800x600 resolution in mind, and leave blank vertical strips along the left/right edges if the browser canvas is larger. (Sure, that is bad web design, but if you think that's a viable objection, perhaps you haven't seen the Internet before.) Even pages which resize (like Slashdot) tend to make the lines of text so wide as to make them harder to read. (Text is easier to read in narrower columns; there's a reason newspapers lay things out the way they do.)
But thanks to Tree Style Tabs, I have the option of putting all my tabs in a box on the left. It also puts the tabs in a hierarchy, with collapsible sub-trees, which fits my browsing and thinking habits perfectly. I middle-click (new tab) for practically everything. I can drag-and-drop to restructure. This lets me structure and compartmentalize my thinking. I frequently find I have 50+ tabs open, with several collapsed, reflecting what I'm working on and what I've backgrounded.
Long titles are rarely a problem (I've got 25+ characters visible in my tabs), and tooltips work for the few times I need more.
I find myself wishing for a window/desktop manager that could organize windows this way. It's like the power of virtual desktops on steroids. There's an arbitrary number of groupings and levels of groupings, while virtual desktops are typically limited (in practical terms) to one or two levels, and two to six groupings at each level.
Like change system files? Nope. How about bind to privileged ports? Nope. So... it can mess up my documents? Darn.
Why do you have the computer? Just so you can have some privileged ports and system files that a remote exploit to an unprivileged account can't touch? Or do you actually, you know, use your computer for stuff?
Because if you're using your computer for anything, then that's what's really valuable.
Case in point: The private keys used to sign Red Hat/Fedora packages qualify as "documents" in your scenario.
When a particular app goes haywire and starts... that particular app just gets a NULL back when there is no longer any memory available.... I would not even begin to think how Linux could handle this
Ummm... forget about the OOM-tuning stuff the other people are preaching, how about the good old ulimit command? It's only been around since... System V Release 4, according to ulimit(3).
So the chip itself hasn't been cracked, it's more a question of the international passport encryption network being worthless.
Technically accurate. But. The chip by itself is worthless. It's only worth something if it counters some kind of threat. This is why security isn't about products or techniques, it's about working systems. If the "chipped passports" don't have a working PKI, then there's really no point to the chips. They go together.
ObQuote: "Security is a process, not a product." -- Bruce Schneier
this is an article about an exploit in the BEA Weblogic J2EE Server, which until very recently had nothing to do with Oracle (the company)
If the software sucks so much, maybe they shouldn't have bought it.
(Note to those with a high input impedance, the above is called hyperbole. I don't know a thing about BEA WebLogic J2EE server, other than that I'm sure it's expensive. The point is that when a company purchases another company, they're taking on obligations with it. This is Oracle Inc's problem.)
(I agree that clarifying that this isn't Oracle-the-product in The Summary would have been a good thing.)
I have never seen panic as a reasonable means to solve problems, only to exacerbate them. I find it much simpler to let the people who need to deal with the problems do so, and avoid mass hysteria.
Given the issues this patch caused with vista, i'm not at all surprised they're putting more thorough testing through on this.
The issue wasn't with Windows, it was with ZoneAlarm (which is not a Microsoft product). And Vista wasn't even effected, only 2000/XP, according to the ZA website:
Specifically, the ZoneAlarm firewall component assumed that DNS queries would always come from a single port. The fix for this DNS vulnerability is to intentionally randomize query source ports. ZoneAlarm simply assumed that DNS queries would only ever come from a single port, and fell apart. From an intrusion-detection standpoint, I could see that change in behavior raising some flags, but apparently ZoneAlarm's initial response was that the patch was defective, which suggests they simply didn't know what was going on.
Does Apple routinely test their OS security updates to make sure they don't break poorly-written third-party software? (I honestly have no idea; I'm not a Mac user.)
issues with cache poisoning can be dramatically reduced in risk by limiting requests for recursion to hosts within your own network.
I would generally expect it to be pretty easy to induce network members into doing DNS lookups. Some examples:
* Send spoofed email messages with hyperlinks to a web page you control to users inside your network. Use follow-on links or JavaScript on that web page to manipulate the user's web browser's to requesting the DNS names you want. * Connect to a mail server that does lookups on the HELO or MAIL FROM domains (most of them, these days).
That's only true of TDMA or FDMA networks. CDMA allows you to dynamically squeeze in more channels with corresponding decrease in SNR due to increasing mutual interference.
Interesting. I didn't know that. Of course, if the tower is out of channels in the landline trunks feeding it, it doesn't really matter how much radio bandwidth is available. Anyone know what the limiting factor usually is? Or does it vary?
we spent great effort fixing Y2K bugs, which would not have caused serious damage (even if we had not fixed them). Therefore, we should not have fixed the Y2K bugs.
I was involved or exposed to a number of Y2K bugs which would have led to serious problems in one field or another. (For appropriate definitions of "serious".) I don't know if planes would have fallen out of the sky, but billing statements being calculated wrong, schedules being planned wrong, phone systems crashing, etc., are pretty serious to the people actually using those systems.
Understand that one of the biggest myths about Y2K was that the problems would manifest at 12:00 AM on 1 January 2000. Y2K problems started well before then. For example, banks, railroads, airlines, and similar started having to worry about Y2K back in the 1980's -- they routinely work on schedules spanning decades.
I won't deny that a lot of people turned legitimate Y2K concerns into marketing opportunities, but that doesn't mean it wasn't an issue.
For example, fans of djbdns are having a field day with this DNS thing, since djbdns doesn't have this flaw. Marketing opportunity. Not that I blame them.:-)
DNSSEC won't solve the present problem. Almost nobody has deployed it. In particular, the root zone does not use it, and I haven't seen mention of any GTLD or ccTLD zone doing so, either. Certainly not the big three (.COM,.NET,.ORG).
I am not saying cryptographically securing DNS is not a good idea. It is, and indeed, is the only viable long-term fix. I'm just saying that DNSSEC is not magic dust.
Oh noes, the world is going to crash down around us! Just saying, why overreact?
A problem you ignore will have full impact. A problem you prepare for and take counter-measures against is prevented from having a serious impact. That's the whole point.
We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.
I guess, since seat belts have saved lives, we should not wear them.
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."
I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.
it's an acronym for "Berkeley Internet Name Daemon"
Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)
If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.
Completely rewriting your code base is generally considered bad.
It is certainly bad if a rewrite is considered necessarily. That either means the code was so poorly written/maintained that it has become an unsalvageable mess, or that programmer understanding is so bad that a rewrite is needed just to grok things. Either way, it is basically a worst-case situation for the code base. But if that situation really has come to pass, then the fact that it's bad doesn't change the fact that it *is*. Kind of like major surgery; nobody really *wants* to have to have it, but if that's what's needed to fix a problem, better to do it.
I can't really speak to whether the BIND 8 rewrite was warranted or not. I saw some of the BIND 8 code back in the day, and it certainly seemed confusing, but I didn't take the time to understand it, so that might have been me. (I have the same reaction looking at the djbdns code.) The fact that BIND 9 has such a better track record when it comes to exploitable code bugs is suggestive, but not conclusive.
I can say that many of the exploitable bugs in BIND 8 appear to be fairly unremarkable code bugs (buffer overflows and the like). Best practices like chroot and least-privilege will help mitigate such -- keeping them from compromising the rest of the system -- but they won't eliminate them. If you're running a production nameserver, even a simple crash is a big problem. So I can't agree that the counter-measures you suggest would have been effective for BIND 8.
As for the rest of what you've posted... it's prolly best if we just agree to disagree. I doubt either of us is much interested in debating those issues with each other.
Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.
As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)
I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.
if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end?
DNS is UDP, these attacks assume a spoofed source address. So the responses are relatively hard to distinguish from legitimate responses. You could do deep packet inspection to try and recognize an attack heuristically, but that would be rather demanding from a CPU/memory standpoint. Keep in mind that big, busy caching resolvers can be answering tens of thousands of queries per second.
Blocking closer to the spoofing source sounds like it might work. But that didn't work for the spam problem. I don't expect it would work any better for this.
Throw in a bot net, and it becomes hard to isolate the source.
Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.
While it does seem that most people don't bother with the subject line, that's not everyone.
Slashdot Mirror
When Shakespeare wrote "first kill all the lawyers"* his ire was somewhat misdirected.
You know it was Jack Cade, the villian of the piece, that said this right?
FYI: Apparently, it was "Dick the butcher", and not "Jack Cade". Cade did concur, though.
Sources:
* http://en.wikiquote.org/wiki/Henry_VI,_Part_2
* http://www.shakespeare-literature.com/Henry_VI,_part_2/13.html
* http://www.gutenberg.org/dirs/etext98/2ws0210.txt
Tabs at the side would take up even more space than tabs at the top or bottom.
But the space they're taking up is less useful. Increasingly people these days have wide-aspect displays...
And let's not forget that even the "old" aspect ratio displays still had more horizontal pixels than vertical. So even at 640x480, vertical space (top and bottom edges) is at a premium over horizontal space (left and right edges). I've always put my FVMW buttons module along the left size of the screen for that very reason.
With Firefox on my 20" 16:9 display, if I were to resize the window to take up the entire screen, I'd loose out. Most web pages are crafted with a 800x600 resolution in mind, and leave blank vertical strips along the left/right edges if the browser canvas is larger. (Sure, that is bad web design, but if you think that's a viable objection, perhaps you haven't seen the Internet before.) Even pages which resize (like Slashdot) tend to make the lines of text so wide as to make them harder to read. (Text is easier to read in narrower columns; there's a reason newspapers lay things out the way they do.)
But thanks to Tree Style Tabs, I have the option of putting all my tabs in a box on the left. It also puts the tabs in a hierarchy, with collapsible sub-trees, which fits my browsing and thinking habits perfectly. I middle-click (new tab) for practically everything. I can drag-and-drop to restructure. This lets me structure and compartmentalize my thinking. I frequently find I have 50+ tabs open, with several collapsed, reflecting what I'm working on and what I've backgrounded.
Long titles are rarely a problem (I've got 25+ characters visible in my tabs), and tooltips work for the few times I need more.
I find myself wishing for a window/desktop manager that could organize windows this way. It's like the power of virtual desktops on steroids. There's an arbitrary number of groupings and levels of groupings, while virtual desktops are typically limited (in practical terms) to one or two levels, and two to six groupings at each level.
Like change system files? Nope. How about bind to privileged ports? Nope. So... it can mess up my documents? Darn.
Why do you have the computer? Just so you can have some privileged ports and system files that a remote exploit to an unprivileged account can't touch? Or do you actually, you know, use your computer for stuff?
Because if you're using your computer for anything, then that's what's really valuable.
Case in point: The private keys used to sign Red Hat/Fedora packages qualify as "documents" in your scenario.
When a particular app goes haywire and starts ... that particular app just gets a NULL back when there is no longer any memory available. ... I would not even begin to think how Linux could handle this
Ummm... forget about the OOM-tuning stuff the other people are preaching, how about the good old ulimit command? It's only been around since... System V Release 4, according to ulimit(3).
http://certcities.com/editorial/columns/story.asp?EditorialsID=214
Maybe Linux's handling of memory limits could be more intelligent (I have no idea), but that's no excuse to ignore basic Unix process accounting.
The article I read said 6 bit encryption... 64 possibilities.
64 possibilities ought to be enough for anyone.
What?
So the chip itself hasn't been cracked, it's more a question of the international passport encryption network being worthless.
Technically accurate. But. The chip by itself is worthless. It's only worth something if it counters some kind of threat. This is why security isn't about products or techniques, it's about working systems. If the "chipped passports" don't have a working PKI, then there's really no point to the chips. They go together.
ObQuote: "Security is a process, not a product." -- Bruce Schneier
this is an article about an exploit in the BEA Weblogic J2EE Server, which until very recently had nothing to do with Oracle (the company)
If the software sucks so much, maybe they shouldn't have bought it.
(Note to those with a high input impedance, the above is called hyperbole. I don't know a thing about BEA WebLogic J2EE server, other than that I'm sure it's expensive. The point is that when a company purchases another company, they're taking on obligations with it. This is Oracle Inc's problem.)
(I agree that clarifying that this isn't Oracle-the-product in The Summary would have been a good thing.)
Stereotype much? Some women I know swear like sailors...
Damn it, now I have to get my irony meter recalibrated. You just pegged it.
Just because you've bought into the whole "cheap cynicism is cool" BS
"The power of accurate observation is often called 'cynicism' by those who do not have it." (attributed to George Bernard Shaw)
I have never seen panic as a reasonable means to solve problems, only to exacerbate them. I find it much simpler to let the people who need to deal with the problems do so, and avoid mass hysteria.
Ahhh, I see, now. No argument there! :)
Given the issues this patch caused with vista, i'm not at all surprised they're putting more thorough testing through on this.
The issue wasn't with Windows, it was with ZoneAlarm (which is not a Microsoft product). And Vista wasn't even effected, only 2000/XP, according to the ZA website:
http://download.zonealarm.com/bin/free/pressReleases/2008/LossOfInternetAccessIssue.html
Specifically, the ZoneAlarm firewall component assumed that DNS queries would always come from a single port. The fix for this DNS vulnerability is to intentionally randomize query source ports. ZoneAlarm simply assumed that DNS queries would only ever come from a single port, and fell apart. From an intrusion-detection standpoint, I could see that change in behavior raising some flags, but apparently ZoneAlarm's initial response was that the patch was defective, which suggests they simply didn't know what was going on.
Does Apple routinely test their OS security updates to make sure they don't break poorly-written third-party software? (I honestly have no idea; I'm not a Mac user.)
issues with cache poisoning can be dramatically reduced in risk by limiting requests for recursion to hosts within your own network.
I would generally expect it to be pretty easy to induce network members into doing DNS lookups. Some examples:
* Send spoofed email messages with hyperlinks to a web page you control to users inside your network. Use follow-on links or JavaScript on that web page to manipulate the user's web browser's to requesting the DNS names you want.
* Connect to a mail server that does lookups on the HELO or MAIL FROM domains (most of them, these days).
From there, it's a short trip to explotvile.
That's only true of TDMA or FDMA networks. CDMA allows you to dynamically squeeze in more channels with corresponding decrease in SNR due to increasing mutual interference.
Interesting. I didn't know that. Of course, if the tower is out of channels in the landline trunks feeding it, it doesn't really matter how much radio bandwidth is available. Anyone know what the limiting factor usually is? Or does it vary?
we spent great effort fixing Y2K bugs, which would not have caused serious damage (even if we had not fixed them). Therefore, we should not have fixed the Y2K bugs.
I was involved or exposed to a number of Y2K bugs which would have led to serious problems in one field or another. (For appropriate definitions of "serious".) I don't know if planes would have fallen out of the sky, but billing statements being calculated wrong, schedules being planned wrong, phone systems crashing, etc., are pretty serious to the people actually using those systems.
Understand that one of the biggest myths about Y2K was that the problems would manifest at 12:00 AM on 1 January 2000. Y2K problems started well before then. For example, banks, railroads, airlines, and similar started having to worry about Y2K back in the 1980's -- they routinely work on schedules spanning decades.
I won't deny that a lot of people turned legitimate Y2K concerns into marketing opportunities, but that doesn't mean it wasn't an issue.
For example, fans of djbdns are having a field day with this DNS thing, since djbdns doesn't have this flaw. Marketing opportunity. Not that I blame them. :-)
The fix is DNSSEC.
DNSSEC won't solve the present problem. Almost nobody has deployed it. In particular, the root zone does not use it, and I haven't seen mention of any GTLD or ccTLD zone doing so, either. Certainly not the big three (.COM, .NET, .ORG).
I am not saying cryptographically securing DNS is not a good idea. It is, and indeed, is the only viable long-term fix. I'm just saying that DNSSEC is not magic dust.
Oh noes, the world is going to crash down around us! Just saying, why overreact?
A problem you ignore will have full impact. A problem you prepare for and take counter-measures against is prevented from having a serious impact. That's the whole point.
We spent great effort fixing Y2K bus, thus prevented the bugs from causing serious damage. Therefore, you conclude, we should not have fixed the Y2K bugs.
I guess, since seat belts have saved lives, we should not wear them.
Get it now? :-)
Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."
I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.
http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar
it's an acronym for "Berkeley Internet Name Daemon"
Actually, BIND stands for "Berkeley Internet Name Domain". Berkeley did the seminal work for the original DNS implementation, and that's what they called their idea. BIND is a suite which includes a stub resolver, some utilities, and named (name daemon). (Along with some other stuff, now.)
If you want to get fancy, "ISC BIND named" is the proper name of the software we're talking about. ISC is the company, BIND is the product, named is the program.
See: http://www.isc.org/sw/bind/index.php
Completely rewriting your code base is generally considered bad.
It is certainly bad if a rewrite is considered necessarily. That either means the code was so poorly written/maintained that it has become an unsalvageable mess, or that programmer understanding is so bad that a rewrite is needed just to grok things. Either way, it is basically a worst-case situation for the code base. But if that situation really has come to pass, then the fact that it's bad doesn't change the fact that it *is*. Kind of like major surgery; nobody really *wants* to have to have it, but if that's what's needed to fix a problem, better to do it.
I can't really speak to whether the BIND 8 rewrite was warranted or not. I saw some of the BIND 8 code back in the day, and it certainly seemed confusing, but I didn't take the time to understand it, so that might have been me. (I have the same reaction looking at the djbdns code.) The fact that BIND 9 has such a better track record when it comes to exploitable code bugs is suggestive, but not conclusive.
I can say that many of the exploitable bugs in BIND 8 appear to be fairly unremarkable code bugs (buffer overflows and the like). Best practices like chroot and least-privilege will help mitigate such -- keeping them from compromising the rest of the system -- but they won't eliminate them. If you're running a production nameserver, even a simple crash is a big problem. So I can't agree that the counter-measures you suggest would have been effective for BIND 8.
As for the rest of what you've posted... it's prolly best if we just agree to disagree. I doubt either of us is much interested in debating those issues with each other.
Thanks for taking the time to reply.
Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.
As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)
I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.
Also anoying: people who don't use the signature facility and instead sign their messages manually so that others have no choice but to read them.
That's not a signature, it's a referral to evidence supporting my argument.
lied about BIND8 and BIND9's complete rewrites,
Got a source I can check? (Or, to use the Wikipedia flavor, "Citation needed".)
I'm honestly curious.
if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end?
DNS is UDP, these attacks assume a spoofed source address. So the responses are relatively hard to distinguish from legitimate responses. You could do deep packet inspection to try and recognize an attack heuristically, but that would be rather demanding from a CPU/memory standpoint. Keep in mind that big, busy caching resolvers can be answering tens of thousands of queries per second.
Blocking closer to the spoofing source sounds like it might work. But that didn't work for the spam problem. I don't expect it would work any better for this.
Throw in a bot net, and it becomes hard to isolate the source.
I don't see this as a trivial problem.
Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.
While it does seem that most people don't bother with the subject line, that's not everyone.
http://it.slashdot.org/~DragonHawk/
I dunno about the universe, but the coldest place in the solar system is the dark side of Mercury, right?
(10 points to anyone who gets the reference.)
((Points can be redeemed at participating Milliway's locations.))