I completely agree.. I did not complete my engineering degree, but the time I spent working on it was very valuable nonetheless. Any Joe Coder can read CS books and gain the necessary intelligence to do a job, but a good university program also teaches you the wisdom to know how and when to apply what you've learned. Some of this can be learned by practical on-the-job application, but I tend to find that people with an engineering/science degree tend to find their niche in a new position faster than someone self-taught. A self-taught coder tends to learn how to do things well "their way" and has difficulty adapting to the requirements of a client or maintaining focus on a project not directly in their line of focus. Of course, these are enormous generalizations and will vary widely depending on the nature of the person, but this is my experience.
In addition, the engineering classes I took weren't really valuable for the formulae and math. I found them valuable for the problem-solving skills they taught. I don't believe even science degrees approach this sort of problem solving, and I find that those with some sort of engineering background (or a "hard" science like Physics) generally make for better programmers, administrators and architects of IT shops.
DNS was never well-suited to be at the layer users interacted with the Internet. Its purpose was to identify nodes on the Internet with names. If you wanted to find the web server for a given company, you weren't expected to know or remember the company's web server's hostname; you were expected to locate them on a directory and have the software automatically send your web browser to the correct URL behind-the-scenes. Heck, even URL's weren't meant to be human-visible.
The problem is that the directory technology never matured fast enough, and was never adopted globally enough for it to serve that purpose. We're just now getting LDAP to start serving in the capacity of an e-mail directory, but short of the numerous incompatible search engines and proprietary "keyword" services out there, nothing has been able to do the same thing to sit above the DNS layer in a sane fashion.
If things had turned out the way they should have, DNS space wouldn't be traded like such a huge commodity, and we wouldn't have everybody and their freakin' pets with their own domain space sitting right off the top-level domains like we do today. It would end up as a nice hierarchy, but nobody but the techies would even care because it's not something generally exposed to the public. It's just ridiculous the way things are today.
Another poster mentioned that having his identity associated with a geographical domain name would suck since he'd have to rename everything when he moved. If things had been done right, this wouldn't really be an issue. The only naming that would need to change would be the naming of the Internet hosts that would move with him. If he was using a geographically-identified ISP and moved, he'd probably need to get a new ISP anyway, so his e-mail address would have changed. If he was hosting his own e-mail on his geographically-identified hosts, his hosts would have to move with him, so not only would he have to renumber, but yah, he'd have to rename as well. This really wouldn't have been as bad as it seems, since a higher-level directory would be what's linking his name and identity with his e-mail address, so after changing the address, a quick trip to the directory's update function would still allow him to receive his e-mail.
I really don't see a huge problem with the top-level generic domains like.com and.org, provided they were used for the purposes they were intended. It's just a namespace. Companies or individuals that are not geographically centered shouldn't be forced under a geographically-centered domain. You have to root those guys somewhere, so the generics are the place to be. I was rather distressed to hear that new TLD's like.biz were going to be opened up. I see no distinction in functionality between.biz and.com, and they're still intending to open them up for anyone that wants one. Now we just have ambiguity when people are trying to locate businesses. Do I try www.microsoft.com or www.microsoft.biz?
But who knows, this may force a globally-recognized directory of proper names to services. As the number of "equivalent" top-level domain names increase, so does the ambiguity. Users are going to start using search engines more to locate an organization, which I see is a good thing, and the overall value of DNS space will begin to diminish.
Things will get there eventually, but many of us will be banging our heads on our desks in the mean time...
The single thing that had the most effect on the amount of spam I receive is blocking client connections to my mail server from IP addresses that either do not have, or have broken reverse DNS. Since the bulk of mail servers that are misconfigured with respects to their relay settings are also broken with respects to their DNS, this has very neatly curbed 95% of the spam I receive. The rest of the spam comes from domains with correctly configured DNS, which usually means they have a manned and relatively clueful abuse@ contact that will take care of the rest.
Though in the couple of months I've done this, I occasionally review my mail logs to see what's being rejected, and I've found 2 pieces of legitimate correspondence that were rejected. One of them finally got back to me with a "oops, my bad" message while the other one was a victim of a clueless ISP that I had to allow through by hand. Still, it's worth it.
I used to use MAPS, but now that they've changed their policies, they require me to mail in two original copies of some hefty contracts just for their free personal-use service, so I haven't gotten around to doing that yet. I've done some tests though, and the MAPS RSS would have nuked most (if not all) of the spam that's blocked by my refusal to traffic with hosts that have broken reverse DNS.
Lighten up! Don't use the "adventure game" front-end for the configurator if you don't want to. The new default front-end is geared towards non-technical users, but this isn't that front-end. Are you assuming that he's really intending this adventure game to be the configuration tool he expects people to use?
The Xing license agreement wasn't the issue at bar, only the injunction on the grounds that it was trade secret information he was posting. The first amendment protects your right to speech regardless of your age.
You're right; none of this has anything to do with the DMCA. Remember that this is just an appeal to the preliminary injunction. Most of the true meat of the DeCSS case is irrelevant here. All that matters was whether or not the lower court was justified in granting the injunction based on the arguments made by the plaintiffs, and they weren't. We are most certainly not out of the woods, and anybody that starts posting DeCSS as a result of this can still end up facing legal trouble, but at this point a court can't order them to take it down. This can be a good thing, or a great way for people to shoot themselves in the foot.
Not quite.. All this decision is about is the preliminary injunction preventing the guy from posting DeCSS on his site on the grounds that it unlawfully discloses their trade secrets. It makes NO ruling whatsoever regarding any other penalties or damages they can slap on him if he continues to do so. Just because it's a trade secret doesn't mean somebody can't write about it.
In addition, if he violated the terms of a contract (e.g. "click-wrap" license) by reverse engineering the software to obtain any of this information, Xing could potentially sue him on those grounds, but that would end up testing the validity of those types of licenses, and I don't think they're confident they'd win.
So basically, this was just the court saying, "You can't forbid him from posting this just because he's discussing a trade secret." He can still bring problems down on himself via other avenues if he decides to continue doing so.
While this might be OK for lesser government agencies, some portions of the government may have a need for a specialized solution to a sensitive problem. Open publication of file/data formats might not be possible or wanted by the client.
But generally in any situation where interoperability is crucial, a company should not actively work to keep that interoperability from happening. Microsoft is known for doing this. Forcing the publication of file and data formats in publicly-used software is a potentially great solution, but I'm not sure that that completely solves the problem. Microsoft is still free to revise and make-incompatible successive versions of these file formats, and so long as they half-heartedly publish the specs for each one, they're in compliance, despite making it a nightmare for those trying to code interoperability.
Without laws on the books, we either have to (a) put up with spam until effective laws are passed; or (b) find a way to pool our knowledge of known spammers and spam-friendly networks and block e-mail and/or network traffic from them.
Remember that MAPS started as a home-grown effort to do (b). Individually, blackholing each individual netblock that spammed you and wouldn't go away was a significant effort. People got together and decided to centralize this effort and distribute the master list back to the community for the purposes of filtering. Is this really so bad? Sure, it's bigger now, but the concept and spirit is still the same, in my opinion.
MAPS is bothered about collatoral damage. Do you think I want connectivity to innocent sites blocked when I use their RBL to block traffic to my network? Of course I don't, but there's only so much MAPS can do. Either they list the IP address(es) anyways, and I lose some connectivity with some customers of a spam-friendly ISP (99.99% odds I'd never notice this), or they don't list the IP address(es), and I get spammed.
You may prefer MAPS not list them at all, but then you're not a customer or user of a MAPS list, are you? I am, and I would rather they add them to the RBL.
It's not my fault that your ISP may choose to use the RBL, and that ends up blocking you from an unrelated site. Why reduce the effectiveness of a tool I want to use because you disagree with your ISP's decision to use the same tool?
Until we have effective laws on the books and effective enforcement of those laws to see spam curbed (which I don't think will ever happen now that spam is so firmly entrenched overseas), we need ways of identifying spamming and spam-friendly networks. If you put MAPS out of business, there will be many more unofficial, grass-roots efforts that will spring up to take its place.
This is a complaint that needs to be aired with the individual ISP's that USE MAPS, not with MAPS itself. By its very nature, if a customer of MAPS doesn't want to use MAPS, they simply don't.
If an ISP is using MAPS to block traffic to sites MAPS considers spammers or spam-friendly, it's up to the ISP to make a business case for or against selectively offering that filtering to their clients. If an ISP were inclined to do as AOL did, they'd set up different network subnets or e-mail filtering zones, one filtered by MAPS and the other wide-open.
However, the challenges an ISP faces with constructing their network and mail system like this, as well as the mechanism for allowing their customers to choose which mode of operation they want to be under, is probably somewhat costly.
In any event, it's the ISP that's made this business decision, and if a customer doesn't like it, they're perfectly within their rights to take their business elsewhere. Unfortunately, many users aren't aware that their ISP is blocking traffic and/or e-mail based on the MAPS list until they get something blocked. It might be nice if ISP's were more vocal about their filtering policies.
Yah, sorry. I hit the first site in the list, saw the porn pop-ups, and assumed that since the second one was similarly named that it might be similar in function.
I'm not sure I understand. The IP address for safesurf.com resolves to the same IP address as ustoyou.com (the porn site). It's certainly possible that the use of NAT or some other IP trickery puts these sites on different machines, but this is unlikely. My system resolved both domains to the same IP address, and that IP address served up pages for both domains. The logical conclusion is that they are both being hosted on the same physical box at the same ISP.
Organizationally, I know they're not connected, but they use a common ISP, and that's how that ISP arranged things.
I was just noting that in cases like this, even if MAPS targeted a spam-related site as specifically as they possibly could, there would still be some collatoral damage in the form of other domains being hosted on that same IP address being inadvertantly blocked.
As such, it's not fair to immediately jump to the conclusion that MAPS was censoring safesurf.com or even had any knowledge whatsoever that they were blocking safesurf.com in the process of issuing that RBL entry.
Now, I'm not saying that MAPS isn't behaving in this fashion, but I wanted to point out that there's no factual data to support this, and it goes against common sense.
Let's try to be a little more objective about this.
They just want cookie confirmation?
on
EU May Outlaw Cookies
·
· Score: 5, Informative
It sounds like all they want is a method to have the user explicitely agree to accept a cookie whenever one's proposed. Many (most?) browsers already support that functionality. Maybe browsers just need to ship with that defaulted to "on" for EU countries. I don't really understand why they're making such a fuss.
To be honest, I think they're going about this thing entirely the wrong way. Don't attack a technology because it has the *ability* to do something you don't like. Attack those that are abusing the technology. In this case, full and proper support for the W3C's P3P initiative looks like it addresses all of the privacy concerns that go with cookies. Maybe they should be looking at this instead.
One thing Microsoft has done right recently is P3P support in IE6, and setting the browser to default itself to what I would consider a reasonable setting out of the box, which automatically blocks a significant number of 3rd-party cookies. I love seeing this in action.
Don't attribute to malice what can be explained equally well by non-malicious intent. Consider the possibility that this isn't some sort of evil, "stealth" attempt at censoring Internet content, and that it just MIGHT be because safesurf.com is hosted by a spam-friendly ISP, or is hosted on the same IP address as a spammer. There are porn sites hosted on the same IP address used by www.safesurf.com, so clearly their ISP is pretty lax with respects to the types of sites it hosts.
Even if the MAPS RBL listed a single IP address here, there would certainly be innocent victims that happen to share that IP address. This is impossible to avoid if an ISP chooses to go the cheapie IP-less route when hosting web sites.
Note that I am making an assumption here that it was (or could have been) their specific IP targeted by the RBL. It's equally possible, though, that the RBL included this ISP's entire subnet, if the ISP itself were targeted by the MAPS RBL. This has its own set of religious debates.
In either case, I would be interested in knowing WHY my subnet was blacklisted. If my ISP is indeed involved in some shady, spam-friendly business practices, this kind of fall-out is hardly unexpected. I'd take my business elsewhere.
There's not much MAPS could have done to prevent this from happening, assuming an RBL listing was necessary. It looks like their ISP is using IP-less virtual hosting, relying upon the browser-provided Host: header to determine where the user is sent.
$ host www.safesurf.com
www.safesurf.com. is an alias for safesurf.com.
safesurf.com. has address 63.107.146.25
$ host 63.107.146.25
25.146.107.63.in-addr.arpa. domain name pointer ustoyou.com.
25.146.107.63.in-addr.arpa. domain name pointer safesurf.com.
25.146.107.63.in-addr.arpa. domain name pointer us2you.com.
WARNING: Browse the 'us2you.com' sites at your own risk. Porn pop-ups abound.
Their analogy of MAPS blocking an entire telephone prefix isn't very sound. It's more like safesurf.com using a party line, and MAPS blocks access to their very specific phone number. It's not their fault you chose to get your site connectivity with a shared IP address.
*shrug* I personally think this is pretty amusing. I would definitely be asking my provider for a new IP address, though, one that wasn't being used by the types of people the MAPS RBL targets.
Please take a moment to learn who your senators and representatives are, figure out how to e-mail them (if you can, otherwise let them know you'd like to), and KEEP IN TOUCH. These people are there to represent YOU. They need to be made aware that issues like this affect you in very negative ways, and many are not technical enough to fully understand the ramifications of certain pieces of legislation. It's up to us to educate them.
I have no doubt in my mind that those of us that did end up writing to congress ended up being most of what this "opposition" was.
I say absolutely restrict and control the tools. Useful technologies like this do have enormous privacy implications. This is why wiretaps and the like require court orders, and why evidence obtained from illegal wiretaps is inadmissable as evidence.
Similarly, technologies allowing the tracking of civilian devices like this should, and (obviously) will or do in cases where they already exist.
If you're talking about banning this technology outright, preventing its use even in cases of justified need or court order, that I think is going too far.
If court orders or warrants are insufficient in your eyes to control the access or use of technologies such as this, it sounds more like you have some trust issues with your local authorities. If your local government and law enforcement is untrustworthy, it is your duty to replace them.
Maybe you should bring up these issues at your next city council meeting.
Really I don't know why I'm defending Vixie or Bind here. I just think it's silly to go off on someone's codebase because you think it's "evil" or "unsafe" based upon your personal feelings about the author. If Linus Torvalds suddenly was convicted of some hacking charge, would you suddenly look upon the Linux source code with suspicion? Would you think of it as evil code whose authors have ulterior motives?
I could care less what DNS software you choose to use on your network, and in fact, I encourage non-Bind solutions. Heterogenity is a good thing.
I'm perfectly aware of the whole MAPS/ORBS/AboveNet crap, but it has absolutely nothing to do with this issue here.
You're also looking at Vixie's code as it was written in the pre-script-kiddie days. You'll find that most ubiquitous software of that magnitude from that day also have similar vulnerabilities. Most anything written from scratch recently is significantly more secure. Including Bind 9.
continues to release known bad programming methods
Huh? Bind 8 is being obsoleted and its use discouraged. Its codebase has been retired in favor of Bind 9, which was unaffected by this bug. It sounds like he's moving in the right direction here, if you ask me.
only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught
In this case, and cases like it, the discovery was made by the "good guys". And before you point out that there's plenty of bad guys in the good guy line to get wind of this vulnerability, note that a) it didn't happen in this case (root name servers were patched a week before this bug was announced); and b) there's also plenty of good guys on the other side of the fence that would notice the discovery and distribution of these exploits. In this latter case, I would expect an announcement to be rushed.
Again, this whole "membership" thing is not a new thing for ISC and Bind vulnerability announcements. Whenever there's something like this discovered that doesn't have a pressing need to be announced immediately, they always go for the critical systems first. Patch the root servers, patch the TLD servers, and then announce it to the general public. All they're doing is extending this existing policy to an "official" early-warning membership. It is nice to have vendor packages with critical security updates ready for you to install the moment a vulnerability is announced, yes?
And again, I totally agree that this makes no sense and will not help anybody if a vulnerability is already known and exploits are in the wild. It is non-sensical to pursue a closed announcement and a waiting period. I think the people that run our Internet infrastructure are a little smarter than that, yes?
And that, my friend, is why they are running our critical infrastructure and you are not. If something is not yet in the wild and being actively exploited, such as this recent bug, there is zero reason to speed to an announcement to the general public before critical systems are secured against it. The script kiddie exploits, in these cases, come after the announcement, not before.
Do you consider yourself more deserving of patches/alerts than the root-level nameserver operators?
That's just silly. Critical infrastructure is by definition critical, and they need advance warning (if at all possible). If a vulnerability is already public and exploits are in the wild, then a group like this doesn't serve any practical use and should (and likely will) be circumvented in favor of more direct announcements and patch releases.
You'll find the same holes in lots of software written in the "pre-script kiddie" era. Lots of education has come about in the last 5 years or so, and most any piece of software written (from the ground up) in the last 2 years will be significantly more secure than something equivalent written 7 years ago.
All the more reason to upgrade to Bind 9 instead of sticking with the Bind 8 codebase.
Bind 9 is also of a completely different codebase. It's also more compatible, more powerful (offering most anything Bind 8 does), and arguably more stable/trusted.
Though I'm not trying to reduce the number of people using alternative DNS products (heterogenity is a good thing). I just don't like to see something like BIND get trashed for no good reason. Bind 9 has little in common (besides features and compatibility) with Bind 8.
ISC will, as they say. I do not anticipate membership to an organization like this to be given lightly, or to anyone at all that can't demonstrate a critical need for it. Root- and TLD-level nameservers, yes. Registrars, perhaps. Major ISP's? Maybe. Major companies? Doubtful.
But then again I'm not ISC. I can't imagine something like this working, though, without a very tightly limited list of members.
Slashdot Mirror
I completely agree.. I did not complete my engineering degree, but the time I spent working on it was very valuable nonetheless. Any Joe Coder can read CS books and gain the necessary intelligence to do a job, but a good university program also teaches you the wisdom to know how and when to apply what you've learned. Some of this can be learned by practical on-the-job application, but I tend to find that people with an engineering/science degree tend to find their niche in a new position faster than someone self-taught. A self-taught coder tends to learn how to do things well "their way" and has difficulty adapting to the requirements of a client or maintaining focus on a project not directly in their line of focus. Of course, these are enormous generalizations and will vary widely depending on the nature of the person, but this is my experience.
In addition, the engineering classes I took weren't really valuable for the formulae and math. I found them valuable for the problem-solving skills they taught. I don't believe even science degrees approach this sort of problem solving, and I find that those with some sort of engineering background (or a "hard" science like Physics) generally make for better programmers, administrators and architects of IT shops.
DNS was never well-suited to be at the layer users interacted with the Internet. Its purpose was to identify nodes on the Internet with names. If you wanted to find the web server for a given company, you weren't expected to know or remember the company's web server's hostname; you were expected to locate them on a directory and have the software automatically send your web browser to the correct URL behind-the-scenes. Heck, even URL's weren't meant to be human-visible.
.com and .org, provided they were used for the purposes they were intended. It's just a namespace. Companies or individuals that are not geographically centered shouldn't be forced under a geographically-centered domain. You have to root those guys somewhere, so the generics are the place to be. I was rather distressed to hear that new TLD's like .biz were going to be opened up. I see no distinction in functionality between .biz and .com, and they're still intending to open them up for anyone that wants one. Now we just have ambiguity when people are trying to locate businesses. Do I try www.microsoft.com or www.microsoft.biz?
The problem is that the directory technology never matured fast enough, and was never adopted globally enough for it to serve that purpose. We're just now getting LDAP to start serving in the capacity of an e-mail directory, but short of the numerous incompatible search engines and proprietary "keyword" services out there, nothing has been able to do the same thing to sit above the DNS layer in a sane fashion.
If things had turned out the way they should have, DNS space wouldn't be traded like such a huge commodity, and we wouldn't have everybody and their freakin' pets with their own domain space sitting right off the top-level domains like we do today. It would end up as a nice hierarchy, but nobody but the techies would even care because it's not something generally exposed to the public. It's just ridiculous the way things are today.
Another poster mentioned that having his identity associated with a geographical domain name would suck since he'd have to rename everything when he moved. If things had been done right, this wouldn't really be an issue. The only naming that would need to change would be the naming of the Internet hosts that would move with him. If he was using a geographically-identified ISP and moved, he'd probably need to get a new ISP anyway, so his e-mail address would have changed. If he was hosting his own e-mail on his geographically-identified hosts, his hosts would have to move with him, so not only would he have to renumber, but yah, he'd have to rename as well. This really wouldn't have been as bad as it seems, since a higher-level directory would be what's linking his name and identity with his e-mail address, so after changing the address, a quick trip to the directory's update function would still allow him to receive his e-mail.
I really don't see a huge problem with the top-level generic domains like
But who knows, this may force a globally-recognized directory of proper names to services. As the number of "equivalent" top-level domain names increase, so does the ambiguity. Users are going to start using search engines more to locate an organization, which I see is a good thing, and the overall value of DNS space will begin to diminish.
Things will get there eventually, but many of us will be banging our heads on our desks in the mean time...
The single thing that had the most effect on the amount of spam I receive is blocking client connections to my mail server from IP addresses that either do not have, or have broken reverse DNS. Since the bulk of mail servers that are misconfigured with respects to their relay settings are also broken with respects to their DNS, this has very neatly curbed 95% of the spam I receive. The rest of the spam comes from domains with correctly configured DNS, which usually means they have a manned and relatively clueful abuse@ contact that will take care of the rest.
Though in the couple of months I've done this, I occasionally review my mail logs to see what's being rejected, and I've found 2 pieces of legitimate correspondence that were rejected. One of them finally got back to me with a "oops, my bad" message while the other one was a victim of a clueless ISP that I had to allow through by hand. Still, it's worth it.
I used to use MAPS, but now that they've changed their policies, they require me to mail in two original copies of some hefty contracts just for their free personal-use service, so I haven't gotten around to doing that yet. I've done some tests though, and the MAPS RSS would have nuked most (if not all) of the spam that's blocked by my refusal to traffic with hosts that have broken reverse DNS.
Lighten up! Don't use the "adventure game" front-end for the configurator if you don't want to. The new default front-end is geared towards non-technical users, but this isn't that front-end. Are you assuming that he's really intending this adventure game to be the configuration tool he expects people to use?
The Xing license agreement wasn't the issue at bar, only the injunction on the grounds that it was trade secret information he was posting. The first amendment protects your right to speech regardless of your age.
You're right; none of this has anything to do with the DMCA. Remember that this is just an appeal to the preliminary injunction. Most of the true meat of the DeCSS case is irrelevant here. All that matters was whether or not the lower court was justified in granting the injunction based on the arguments made by the plaintiffs, and they weren't. We are most certainly not out of the woods, and anybody that starts posting DeCSS as a result of this can still end up facing legal trouble, but at this point a court can't order them to take it down. This can be a good thing, or a great way for people to shoot themselves in the foot.
Not quite.. All this decision is about is the preliminary injunction preventing the guy from posting DeCSS on his site on the grounds that it unlawfully discloses their trade secrets. It makes NO ruling whatsoever regarding any other penalties or damages they can slap on him if he continues to do so. Just because it's a trade secret doesn't mean somebody can't write about it.
In addition, if he violated the terms of a contract (e.g. "click-wrap" license) by reverse engineering the software to obtain any of this information, Xing could potentially sue him on those grounds, but that would end up testing the validity of those types of licenses, and I don't think they're confident they'd win.
So basically, this was just the court saying, "You can't forbid him from posting this just because he's discussing a trade secret." He can still bring problems down on himself via other avenues if he decides to continue doing so.
While this might be OK for lesser government agencies, some portions of the government may have a need for a specialized solution to a sensitive problem. Open publication of file/data formats might not be possible or wanted by the client.
But generally in any situation where interoperability is crucial, a company should not actively work to keep that interoperability from happening. Microsoft is known for doing this. Forcing the publication of file and data formats in publicly-used software is a potentially great solution, but I'm not sure that that completely solves the problem. Microsoft is still free to revise and make-incompatible successive versions of these file formats, and so long as they half-heartedly publish the specs for each one, they're in compliance, despite making it a nightmare for those trying to code interoperability.
Without laws on the books, we either have to (a) put up with spam until effective laws are passed; or (b) find a way to pool our knowledge of known spammers and spam-friendly networks and block e-mail and/or network traffic from them.
Remember that MAPS started as a home-grown effort to do (b). Individually, blackholing each individual netblock that spammed you and wouldn't go away was a significant effort. People got together and decided to centralize this effort and distribute the master list back to the community for the purposes of filtering. Is this really so bad? Sure, it's bigger now, but the concept and spirit is still the same, in my opinion.
MAPS is bothered about collatoral damage. Do you think I want connectivity to innocent sites blocked when I use their RBL to block traffic to my network? Of course I don't, but there's only so much MAPS can do. Either they list the IP address(es) anyways, and I lose some connectivity with some customers of a spam-friendly ISP (99.99% odds I'd never notice this), or they don't list the IP address(es), and I get spammed.
You may prefer MAPS not list them at all, but then you're not a customer or user of a MAPS list, are you? I am, and I would rather they add them to the RBL.
It's not my fault that your ISP may choose to use the RBL, and that ends up blocking you from an unrelated site. Why reduce the effectiveness of a tool I want to use because you disagree with your ISP's decision to use the same tool?
Until we have effective laws on the books and effective enforcement of those laws to see spam curbed (which I don't think will ever happen now that spam is so firmly entrenched overseas), we need ways of identifying spamming and spam-friendly networks. If you put MAPS out of business, there will be many more unofficial, grass-roots efforts that will spring up to take its place.
This is a complaint that needs to be aired with the individual ISP's that USE MAPS, not with MAPS itself. By its very nature, if a customer of MAPS doesn't want to use MAPS, they simply don't.
If an ISP is using MAPS to block traffic to sites MAPS considers spammers or spam-friendly, it's up to the ISP to make a business case for or against selectively offering that filtering to their clients. If an ISP were inclined to do as AOL did, they'd set up different network subnets or e-mail filtering zones, one filtered by MAPS and the other wide-open.
However, the challenges an ISP faces with constructing their network and mail system like this, as well as the mechanism for allowing their customers to choose which mode of operation they want to be under, is probably somewhat costly.
In any event, it's the ISP that's made this business decision, and if a customer doesn't like it, they're perfectly within their rights to take their business elsewhere. Unfortunately, many users aren't aware that their ISP is blocking traffic and/or e-mail based on the MAPS list until they get something blocked. It might be nice if ISP's were more vocal about their filtering policies.
Yah, sorry. I hit the first site in the list, saw the porn pop-ups, and assumed that since the second one was similarly named that it might be similar in function.
I'm not sure I understand. The IP address for safesurf.com resolves to the same IP address as ustoyou.com (the porn site). It's certainly possible that the use of NAT or some other IP trickery puts these sites on different machines, but this is unlikely. My system resolved both domains to the same IP address, and that IP address served up pages for both domains. The logical conclusion is that they are both being hosted on the same physical box at the same ISP.
Organizationally, I know they're not connected, but they use a common ISP, and that's how that ISP arranged things.
I was just noting that in cases like this, even if MAPS targeted a spam-related site as specifically as they possibly could, there would still be some collatoral damage in the form of other domains being hosted on that same IP address being inadvertantly blocked.
As such, it's not fair to immediately jump to the conclusion that MAPS was censoring safesurf.com or even had any knowledge whatsoever that they were blocking safesurf.com in the process of issuing that RBL entry.
Now, I'm not saying that MAPS isn't behaving in this fashion, but I wanted to point out that there's no factual data to support this, and it goes against common sense.
Let's try to be a little more objective about this.
It sounds like all they want is a method to have the user explicitely agree to accept a cookie whenever one's proposed. Many (most?) browsers already support that functionality. Maybe browsers just need to ship with that defaulted to "on" for EU countries. I don't really understand why they're making such a fuss.
To be honest, I think they're going about this thing entirely the wrong way. Don't attack a technology because it has the *ability* to do something you don't like. Attack those that are abusing the technology. In this case, full and proper support for the W3C's P3P initiative looks like it addresses all of the privacy concerns that go with cookies. Maybe they should be looking at this instead.
One thing Microsoft has done right recently is P3P support in IE6, and setting the browser to default itself to what I would consider a reasonable setting out of the box, which automatically blocks a significant number of 3rd-party cookies. I love seeing this in action.
Don't attribute to malice what can be explained equally well by non-malicious intent. Consider the possibility that this isn't some sort of evil, "stealth" attempt at censoring Internet content, and that it just MIGHT be because safesurf.com is hosted by a spam-friendly ISP, or is hosted on the same IP address as a spammer. There are porn sites hosted on the same IP address used by www.safesurf.com, so clearly their ISP is pretty lax with respects to the types of sites it hosts.
Even if the MAPS RBL listed a single IP address here, there would certainly be innocent victims that happen to share that IP address. This is impossible to avoid if an ISP chooses to go the cheapie IP-less route when hosting web sites.
Note that I am making an assumption here that it was (or could have been) their specific IP targeted by the RBL. It's equally possible, though, that the RBL included this ISP's entire subnet, if the ISP itself were targeted by the MAPS RBL. This has its own set of religious debates.
In either case, I would be interested in knowing WHY my subnet was blacklisted. If my ISP is indeed involved in some shady, spam-friendly business practices, this kind of fall-out is hardly unexpected. I'd take my business elsewhere.
There's not much MAPS could have done to prevent this from happening, assuming an RBL listing was necessary. It looks like their ISP is using IP-less virtual hosting, relying upon the browser-provided Host: header to determine where the user is sent.
$ host www.safesurf.com
www.safesurf.com. is an alias for safesurf.com.
safesurf.com. has address 63.107.146.25
$ host 63.107.146.25
25.146.107.63.in-addr.arpa. domain name pointer ustoyou.com.
25.146.107.63.in-addr.arpa. domain name pointer safesurf.com.
25.146.107.63.in-addr.arpa. domain name pointer us2you.com.
WARNING: Browse the 'us2you.com' sites at your own risk. Porn pop-ups abound.
Their analogy of MAPS blocking an entire telephone prefix isn't very sound. It's more like safesurf.com using a party line, and MAPS blocks access to their very specific phone number. It's not their fault you chose to get your site connectivity with a shared IP address.
*shrug* I personally think this is pretty amusing. I would definitely be asking my provider for a new IP address, though, one that wasn't being used by the types of people the MAPS RBL targets.
Please take a moment to learn who your senators and representatives are, figure out how to e-mail them (if you can, otherwise let them know you'd like to), and KEEP IN TOUCH. These people are there to represent YOU. They need to be made aware that issues like this affect you in very negative ways, and many are not technical enough to fully understand the ramifications of certain pieces of legislation. It's up to us to educate them.
I have no doubt in my mind that those of us that did end up writing to congress ended up being most of what this "opposition" was.
I say absolutely restrict and control the tools. Useful technologies like this do have enormous privacy implications. This is why wiretaps and the like require court orders, and why evidence obtained from illegal wiretaps is inadmissable as evidence.
Similarly, technologies allowing the tracking of civilian devices like this should, and (obviously) will or do in cases where they already exist.
If you're talking about banning this technology outright, preventing its use even in cases of justified need or court order, that I think is going too far.
If court orders or warrants are insufficient in your eyes to control the access or use of technologies such as this, it sounds more like you have some trust issues with your local authorities. If your local government and law enforcement is untrustworthy, it is your duty to replace them.
Maybe you should bring up these issues at your next city council meeting.
Really I don't know why I'm defending Vixie or Bind here. I just think it's silly to go off on someone's codebase because you think it's "evil" or "unsafe" based upon your personal feelings about the author. If Linus Torvalds suddenly was convicted of some hacking charge, would you suddenly look upon the Linux source code with suspicion? Would you think of it as evil code whose authors have ulterior motives?
I could care less what DNS software you choose to use on your network, and in fact, I encourage non-Bind solutions. Heterogenity is a good thing.
I'm perfectly aware of the whole MAPS/ORBS/AboveNet crap, but it has absolutely nothing to do with this issue here.
You're also looking at Vixie's code as it was written in the pre-script-kiddie days. You'll find that most ubiquitous software of that magnitude from that day also have similar vulnerabilities. Most anything written from scratch recently is significantly more secure. Including Bind 9.
continues to release known bad programming methods
Huh? Bind 8 is being obsoleted and its use discouraged. Its codebase has been retired in favor of Bind 9, which was unaffected by this bug. It sounds like he's moving in the right direction here, if you ask me.
only means the rest of us have to sit around like mushrooms while the cracker nets are passing the info around in their own secretive ways to avoid getting caught
In this case, and cases like it, the discovery was made by the "good guys". And before you point out that there's plenty of bad guys in the good guy line to get wind of this vulnerability, note that a) it didn't happen in this case (root name servers were patched a week before this bug was announced); and b) there's also plenty of good guys on the other side of the fence that would notice the discovery and distribution of these exploits. In this latter case, I would expect an announcement to be rushed.
Again, this whole "membership" thing is not a new thing for ISC and Bind vulnerability announcements. Whenever there's something like this discovered that doesn't have a pressing need to be announced immediately, they always go for the critical systems first. Patch the root servers, patch the TLD servers, and then announce it to the general public. All they're doing is extending this existing policy to an "official" early-warning membership. It is nice to have vendor packages with critical security updates ready for you to install the moment a vulnerability is announced, yes?
And again, I totally agree that this makes no sense and will not help anybody if a vulnerability is already known and exploits are in the wild. It is non-sensical to pursue a closed announcement and a waiting period. I think the people that run our Internet infrastructure are a little smarter than that, yes?
And that, my friend, is why they are running our critical infrastructure and you are not. If something is not yet in the wild and being actively exploited, such as this recent bug, there is zero reason to speed to an announcement to the general public before critical systems are secured against it. The script kiddie exploits, in these cases, come after the announcement, not before.
Do you consider yourself more deserving of patches/alerts than the root-level nameserver operators?
That's just silly. Critical infrastructure is by definition critical, and they need advance warning (if at all possible). If a vulnerability is already public and exploits are in the wild, then a group like this doesn't serve any practical use and should (and likely will) be circumvented in favor of more direct announcements and patch releases.
You'll find the same holes in lots of software written in the "pre-script kiddie" era. Lots of education has come about in the last 5 years or so, and most any piece of software written (from the ground up) in the last 2 years will be significantly more secure than something equivalent written 7 years ago.
All the more reason to upgrade to Bind 9 instead of sticking with the Bind 8 codebase.
Bind 9 is also of a completely different codebase. It's also more compatible, more powerful (offering most anything Bind 8 does), and arguably more stable/trusted.
Though I'm not trying to reduce the number of people using alternative DNS products (heterogenity is a good thing). I just don't like to see something like BIND get trashed for no good reason. Bind 9 has little in common (besides features and compatibility) with Bind 8.
ISC will, as they say. I do not anticipate membership to an organization like this to be given lightly, or to anyone at all that can't demonstrate a critical need for it. Root- and TLD-level nameservers, yes. Registrars, perhaps. Major ISP's? Maybe. Major companies? Doubtful.
But then again I'm not ISC. I can't imagine something like this working, though, without a very tightly limited list of members.