How does it get the zombie's email address in order to send it spam? Maybe what you meant to say is that IBM DoS's the zombie? Or maybe IBM sends spam to the forged sender email address?
But I do think IBM would deserve the RBL listing if they go forward with the brain-dead idea.
The original project proposed C/R be sent to the forged sender email address... under the conditions where it appears to be spoofed. What this does is mostly eliminate C/R for legitimate mail (that's fine) but it imposes C/R for spoofed sender spam (this is bad, very bad). Sending anything to a spoofed email address is wrong. It needs to be verified before any email can be sent. More than 70% of email traffic is now spam, and probably 50% of email traffic (most of the spam) has spoofed sender. What FairUCE's "C/R only if apparently spoofed" will do is add 50% more to the email traffic, annoy millions of people who about mail they never sent, and get the users of FairUCE blacklisted for backscatter.
If the sender email has NOT been verified, the challenge must NOT be sent.
If the sender email has been verified, the challenge is not needed.
There is a gray area in that where the spoofed email is actually on the same provider as the spammer's zombie. It may appear to be valid, but isn't.
It is registered by the author who wrote this article and published it on the IBM alphaWorks site. And spam has not lost the battle at all. In fact FairUCE actually gives spammers a new tool to do DDoS attacks. The logic of FairUCE is all wrong. And the code does not appear to be free open source. Networks that send C/R will still get blacklisted.
That will get the user of FairUCE blacklisted. It's called backscatter. The email address provided in the SMTP transaction, or the message headers, should ABSOLUTELY NOT be considered valid unless, and until, the IP is verified as designated by the domain of the RHS of that email address. And then even that won't work very well if spammers start forging addresses within the same domain as the zombied machine. Don't forget that spammers do have a list of lots of email addresses within all the major domains. They only need to pick one at random that has @comcast.net as the RHS for the zombies running on comcast.net.
Many businesses already have. To send them feedback or ask for more info, they don't provide you with an email address; they make you fill out a web form. But I guess they didn't do it right because when I give them my own web feedback form for "email address" it rejects it. It even rejects their own, so I guess it is broken.
I do a redirection of http://CALLSIGN.ham.org/ to a ham radio operator's web site. I used 302 because I wanted this to be a means for the ham operator to move their site. Google indexed it under http://CALLSIGN.ham.org/ and that has made at least one site operator angry (at me, because he thought I stole his content). Google should not present it as content belonging to http://CALLSIGN.ham.org/ but rather to the redirected to site, but with a notation of where to find the site if it moves (e.g. the ham.org URL the redirection came from).
Of course this is exploitable to some extent. People can flood Google's indexing with copy-cat sites, without actually doing the copying. That's not good, but it's really a Google issue; it doesn't otherwise break the referenced site... unless visitors are not properly redirected.
I saw this months ago. I run a redirect site for ham radio callsigns as a hostname in the domain "ham.org". I had chosen to use "302 found" initially. This ran like this for a couple years. Finally a got a complaint from a ham operator complaining that his web site was showing under the ham.org URL in a google search. He was right, it was. I subsequently changed the redirect to "301 moved". But I still feel that "302 found" would be more appropriate. But having "ham.org" URLs show up in Google with other site's content was not the intent. I reported this to Google and all they would say was to use "301 moved", so they clearly are aware of it. I replied back that this would be a way for someone to exploit Google, but they dismissed the notion. IMHO, if the browser changes the displayed URL when visiting, then search engines should show that same redirect target URL. And this applies to both 301 and 302.
Colocation within the CO does happen for DSL and you can get the IP of the ISP, not the telco. But that's not the case 100% as many "ISPs" are just resellers of the telco's own DSL service. Both business models exist. The big question with FiOS is whether both business models will exist there, as well. The fact that Verizon is offering this willingly suggests the possibility it is a re-sell model. I've seen no clarification either way.
There is "end run around" taking place. Wireless is one example. Power companies are trying BPL ([B]andwidth [P]ermanently [L]ow) which I believe will fail in a few years anyway.
Then maybe you can answer the question I have beeing trying to get answered (and no one knows). Will getting FiOS via another ISP mean the other ISP is just re-selling Verizon IP layer service (e.g. I get a Verizon IP address) or will this literally go through the other ISP network and I get the other ISP's IP address (or multiple addresses as the case may be)?
You wouldn't have to worry about retaining your email address if you had your own domain name or used a freemail service. With a domain, you are in control over where it is hosted. If you're using someone else's domain, they are in control.
In order to gain access to publish, require the authors to participate (no pay) in the peer review process much like moderators on Slashdot (but more formalized). Then have a meta peer review process to back that up. You get free peer reviewing by requiring authors to do some of that to continue to publish. But unlike Slashdot, the mod points would go to verified degreed people in academic or other research areas who would be selected first early access to do the reviews. When an article is submitted, distribute it to randonly selected reviewers. Then if it's not completely shot down, follow up with more review cycles until the reviewer sample size gives a good ranking.
Do the actual distribution via BitTorrent, with the article in the clear, but cryptographically signed by the prestigious journal. The journal's web site would have the abstracts, links, and public key.
It's not totally paid for this way, but the cost of distribution gets covered, and peer reviewers come free.
It's really silly to go ahead and prepare an acceptance letter that you're going to retract. Maybe in paper that might be needed, but not electronically since a template derived from a database is all that is really needed. It might be different if one were to see that they are close, but not quite close enough to get in, through statistics. But those would be figures that aren't supposed to be known to the applicants, at least not yet. So I just don't buy this. My respect for HBS just dropped another notch (it's rather low already).
I didn't care about spyware. Since I use Linux and Firefox, what do I need to worry about. So I didn't really worry. Let the Windows lusers have their popups and misdirected browsers. I didn't really care. Besides, I've been getting $500 a pop for coming in and re-installing people's Windows machines for them (after extracting their important data they never backed up). So why should I have cared about making this illegal.
But once these people go so far as to have lawyers make threats against people exercising the right of free speech to reveal the truth that in many cases the big media will completely miss (look how often they are led to their stories now due to a blog), now I'm pissed off. So now I fully favor the law being passed against spyware. I just hope they don't screw it up like they did with the law against spam.
But I also favor the idea of creating a SLAPP/CE blacklist. Or maybe there is one already I don't know about. In any case, the idea is to block the bastards right at the router. Obviously the first places to block are their web sites and mail servers found in DNS. But being spyware, it most likely is trying to communicate with home base in other ways, too, and may be doing it without the use of DNS. In such cases, the only way to block it is to put in an access-list or null route it. If it is being directed to do things from home base (once it knows you are infected), then null routing may not be enough and an access-list is needed (either deny or use route maps to redirect the traffic). These people need to be cut off at the jugular.
BTW, the biggest reason I want to see this practice be illegal is so in future cases where they try a SLAPP lawsuit, their lawyers can be taken down with them for failure to properly advise their clients. Getting lawyers disbarred, or even jailed, is one of my favorite hobbies I don't get to enjoy anywhere near enough.
What part of "support" did you not understand? Sure, the boot loader read the paper tape. But it did NOT provide a read function for the code that was loaded from paper tape. The boot loader was way too small, anyway (about 12 CPU instructions) to provide for a general purpose read function. So the code loaded from the paper tape reader was on its own. Fortunately, they didn't make I/O devices so complicated back then, so a simple fetch from the paper tape reader's I/O port memory address would get the next piece of data. So even the code loaded in could do I/O relatively easily on its own.
The early BIOS was there to provide basic I/O support... hence the name. but not all machines in the day had such a thing. This really came about from the fact that microprocessors were also being utilized in embedded applications involving firmware. So it was natural to think of having a firmware do common parts, like low level hardware support. But big computers, such as IBM mainframes, had no such thing. And they didn't need it. And a PC doesn't need it, either... especially an I/O API part.
What is really needed to get an operating system started? Really, just a boot loader. The first computer I used was a PDP-8 minicomputer. It had a front panel where you could set switches to define data and address, and store the results into core memory. There was a boot loader program we would manually toggle into core memory when we needed to (core memory, BTW, retained its contents when powered off). That boot loader would then read the paper tape reader and load the operating system. But there was no I/O support from the boot loader. There was no firmware. The OS being loaded was self contained.
The next computer I worked on was an IBM mainframe (several of them, actually). Early models (360 series), did what was call IPL (initial program load) by triggering a single CPU instruction to perform a single channel I/O operation to read from a specified device (selected numerically by dials on the front panel). The first read operation loaded in just enough additional instructions to start more read operations to bring in enough of a boot loader to load the entire OS image. Then it branched to the OS and things took off. Again, there was no firmware I/O support other than these machines did have separate "I/O channel processors". The OS had to do whatever it would do on it's own.
Fast forward to the emergence of BSD and Linux on PC. The BIOS is used to load the boot loader which loads the OS. The boot loaders generally do use the BIOS API, but in theory, they should not have to. The OS (32 bit and 64 bit versions now) don't need, and generally can't use, the BIOS API.
So I say, get rid of it. Let's not have an I/O API in the BIOS anymore. Then let's quit calling it a BIOS (because it won't be that anymore).
That leaves 2 functions which what we now call a BIOS does already, which we still need to do. One is to configure the hardware. This is one of the hard parts because it has to be tailored to the chipset and maybe even CPU involved. The other is to load the operating system.
The hardware configuration could be handled in a different way. By adding on a 2nd smaller (maybe 16-bit) CPU, it can run a firmware program separate from the OS (the host CPU) that not only configures the hardware, but can also constantly monitor it while the OS is running. It could even be networked for those 10,000 machine server farms.
This same extra CPU could also do the boot loading. But it wouldn't need to do much device I/O. It should have the ability to read a few basic devices (serial port, USB, Firewire, floppy, CDROM, ethernet, and IDE/SATA hard drives) sequentially from a specified starting point and load blocks into RAM or into flash memory (or flash to RAM). Put it in a loop and it can do this with megabytes of OS images directly (this serving as the full boot loader). Flash memory of 4MB to 16MB would be plenty (for now).
I doubt we'll ever get a totally non-proprietary machine. But at least by having no more OS to firmware interfacing, we can eliminate some of the issues. And the extra control processor (something the later IBM mainframes already have many of anyway) will enhance the hardware support as well.
If you can't find them, then you aren't looking very hard. Put the URL to your current job openings in your Slashdot signature and you could start to get them. But drop the CS requirement. While more good programmers have gone through such programs, there are lots of good ones that have not (look at their experience to see). BTW, one of the best programmers I ever had working for me was before that job working as a mechanic at a Pep Boys (he was good at that, too), with barely half a year of college course work done. So don't get into that snobish degree requirement bit. A degree tells you some things about a person, but the lack of one doesn't tell you what they can't do.
Financial institutions, such as banks, credit agencies, and payroll processors, should learn something from this aspect of the motion picture industry. Data about people should be treated as just as valuable (because really, it is).
Using an SSN as an ID is just fine. As the grandparent comment points out, however, the issue is in authentication. In theory, if I have your SSN, I should be able to do no more than refer to you. Sure, I might be able to get information about you with that information. What should never be allowed to happen is to pretend to be you. But if I want into a bank and produce some faked ID and give your SSN I can open an account in your name (with my fake of your signature on the signature card) and put in $250. Then when the checks arrive, I can write a whole bunch at once all over town, for small amounts ($100 here, $200 there) totalling thousands, and disappear with the goods, leaving you to clean up the mess in some town 1000 miles away from where you really live that you've never even been to. The fact that the bank ass-u-me-s I was really you is the flaw in the system.
There should at least be a law that says if you deny being the person who opened the above account, then that bank must produce proof that you (and not someone with your info) actually opened the account and passed the bad checks... or drop the matter with respect to affecting you. Such a law should cover all businesses that use SSNs in any way, shape, or form. Of course, then banks will have to cover their ass and require fingerprints and photos to open an account.
A 25 year minimum mandatory prison sentence for conviction of identity infringement would help put a stop to this.
Then we still need to deal with the sloppy businesses that let identity infringers do this. Triple corrective costs, plus legal expenses, plus punitive to a million dollars, would send a clear message to such businesses... as clean as driving an ice pick in their eyes.
Slashdot Mirror
Excuse me?
How does it get the zombie's email address in order to send it spam? Maybe what you meant to say is that IBM DoS's the zombie? Or maybe IBM sends spam to the forged sender email address?
But I do think IBM would deserve the RBL listing if they go forward with the brain-dead idea.
The original project proposed C/R be sent to the forged sender email address ... under the conditions where it appears to be spoofed. What this does is mostly eliminate C/R for legitimate mail (that's fine) but it imposes C/R for spoofed sender spam (this is bad, very bad). Sending anything to a spoofed email address is wrong. It needs to be verified before any email can be sent. More than 70% of email traffic is now spam, and probably 50% of email traffic (most of the spam) has spoofed sender. What FairUCE's "C/R only if apparently spoofed" will do is add 50% more to the email traffic, annoy millions of people who about mail they never sent, and get the users of FairUCE blacklisted for backscatter.
If the sender email has NOT been verified, the challenge must NOT be sent.
If the sender email has been verified, the challenge is not needed.
There is a gray area in that where the spoofed email is actually on the same provider as the spammer's zombie. It may appear to be valid, but isn't.
It is registered by the author who wrote this article and published it on the IBM alphaWorks site. And spam has not lost the battle at all. In fact FairUCE actually gives spammers a new tool to do DDoS attacks. The logic of FairUCE is all wrong. And the code does not appear to be free open source. Networks that send C/R will still get blacklisted.
That will get the user of FairUCE blacklisted. It's called backscatter. The email address provided in the SMTP transaction, or the message headers, should ABSOLUTELY NOT be considered valid unless, and until, the IP is verified as designated by the domain of the RHS of that email address. And then even that won't work very well if spammers start forging addresses within the same domain as the zombied machine. Don't forget that spammers do have a list of lots of email addresses within all the major domains. They only need to pick one at random that has @comcast.net as the RHS for the zombies running on comcast.net.
Many businesses already have. To send them feedback or ask for more info, they don't provide you with an email address; they make you fill out a web form. But I guess they didn't do it right because when I give them my own web feedback form for "email address" it rejects it. It even rejects their own, so I guess it is broken.
I do a redirection of http://CALLSIGN.ham.org/ to a ham radio operator's web site. I used 302 because I wanted this to be a means for the ham operator to move their site. Google indexed it under http://CALLSIGN.ham.org/ and that has made at least one site operator angry (at me, because he thought I stole his content). Google should not present it as content belonging to http://CALLSIGN.ham.org/ but rather to the redirected to site, but with a notation of where to find the site if it moves (e.g. the ham.org URL the redirection came from).
Of course this is exploitable to some extent. People can flood Google's indexing with copy-cat sites, without actually doing the copying. That's not good, but it's really a Google issue; it doesn't otherwise break the referenced site ... unless visitors are not properly redirected.
I saw this months ago. I run a redirect site for ham radio callsigns as a hostname in the domain "ham.org". I had chosen to use "302 found" initially. This ran like this for a couple years. Finally a got a complaint from a ham operator complaining that his web site was showing under the ham.org URL in a google search. He was right, it was. I subsequently changed the redirect to "301 moved". But I still feel that "302 found" would be more appropriate. But having "ham.org" URLs show up in Google with other site's content was not the intent. I reported this to Google and all they would say was to use "301 moved", so they clearly are aware of it. I replied back that this would be a way for someone to exploit Google, but they dismissed the notion. IMHO, if the browser changes the displayed URL when visiting, then search engines should show that same redirect target URL. And this applies to both 301 and 302.
Colocation within the CO does happen for DSL and you can get the IP of the ISP, not the telco. But that's not the case 100% as many "ISPs" are just resellers of the telco's own DSL service. Both business models exist. The big question with FiOS is whether both business models will exist there, as well. The fact that Verizon is offering this willingly suggests the possibility it is a re-sell model. I've seen no clarification either way.
There is "end run around" taking place. Wireless is one example. Power companies are trying BPL ([B]andwidth [P]ermanently [L]ow) which I believe will fail in a few years anyway.
Then maybe you can answer the question I have beeing trying to get answered (and no one knows). Will getting FiOS via another ISP mean the other ISP is just re-selling Verizon IP layer service (e.g. I get a Verizon IP address) or will this literally go through the other ISP network and I get the other ISP's IP address (or multiple addresses as the case may be)?
You wouldn't have to worry about retaining your email address if you had your own domain name or used a freemail service. With a domain, you are in control over where it is hosted. If you're using someone else's domain, they are in control.
In order to gain access to publish, require the authors to participate (no pay) in the peer review process much like moderators on Slashdot (but more formalized). Then have a meta peer review process to back that up. You get free peer reviewing by requiring authors to do some of that to continue to publish. But unlike Slashdot, the mod points would go to verified degreed people in academic or other research areas who would be selected first early access to do the reviews. When an article is submitted, distribute it to randonly selected reviewers. Then if it's not completely shot down, follow up with more review cycles until the reviewer sample size gives a good ranking.
Do the actual distribution via BitTorrent, with the article in the clear, but cryptographically signed by the prestigious journal. The journal's web site would have the abstracts, links, and public key.
It's not totally paid for this way, but the cost of distribution gets covered, and peer reviewers come free.
The answer is already on Slashdot here.
What would that have done if everyone peeked? Cancel the whole year?
It's really silly to go ahead and prepare an acceptance letter that you're going to retract. Maybe in paper that might be needed, but not electronically since a template derived from a database is all that is really needed. It might be different if one were to see that they are close, but not quite close enough to get in, through statistics. But those would be figures that aren't supposed to be known to the applicants, at least not yet. So I just don't buy this. My respect for HBS just dropped another notch (it's rather low already).
I'm not gonna to take it anymore. I'm gonna toss the damned boob tube out the window.
I didn't care about spyware. Since I use Linux and Firefox, what do I need to worry about. So I didn't really worry. Let the Windows lusers have their popups and misdirected browsers. I didn't really care. Besides, I've been getting $500 a pop for coming in and re-installing people's Windows machines for them (after extracting their important data they never backed up). So why should I have cared about making this illegal.
But once these people go so far as to have lawyers make threats against people exercising the right of free speech to reveal the truth that in many cases the big media will completely miss (look how often they are led to their stories now due to a blog), now I'm pissed off. So now I fully favor the law being passed against spyware. I just hope they don't screw it up like they did with the law against spam.
But I also favor the idea of creating a SLAPP/CE blacklist. Or maybe there is one already I don't know about. In any case, the idea is to block the bastards right at the router. Obviously the first places to block are their web sites and mail servers found in DNS. But being spyware, it most likely is trying to communicate with home base in other ways, too, and may be doing it without the use of DNS. In such cases, the only way to block it is to put in an access-list or null route it. If it is being directed to do things from home base (once it knows you are infected), then null routing may not be enough and an access-list is needed (either deny or use route maps to redirect the traffic). These people need to be cut off at the jugular.
BTW, the biggest reason I want to see this practice be illegal is so in future cases where they try a SLAPP lawsuit, their lawyers can be taken down with them for failure to properly advise their clients. Getting lawyers disbarred, or even jailed, is one of my favorite hobbies I don't get to enjoy anywhere near enough.
What part of "support" did you not understand? Sure, the boot loader read the paper tape. But it did NOT provide a read function for the code that was loaded from paper tape. The boot loader was way too small, anyway (about 12 CPU instructions) to provide for a general purpose read function. So the code loaded from the paper tape reader was on its own. Fortunately, they didn't make I/O devices so complicated back then, so a simple fetch from the paper tape reader's I/O port memory address would get the next piece of data. So even the code loaded in could do I/O relatively easily on its own.
The early BIOS was there to provide basic I/O support ... hence the name. but not all machines in the day had such a thing. This really came about from the fact that microprocessors were also being utilized in embedded applications involving firmware. So it was natural to think of having a firmware do common parts, like low level hardware support. But big computers, such as IBM mainframes, had no such thing. And they didn't need it. And a PC doesn't need it, either ... especially an I/O API part.
What is really needed to get an operating system started? Really, just a boot loader. The first computer I used was a PDP-8 minicomputer. It had a front panel where you could set switches to define data and address, and store the results into core memory. There was a boot loader program we would manually toggle into core memory when we needed to (core memory, BTW, retained its contents when powered off). That boot loader would then read the paper tape reader and load the operating system. But there was no I/O support from the boot loader. There was no firmware. The OS being loaded was self contained.
The next computer I worked on was an IBM mainframe (several of them, actually). Early models (360 series), did what was call IPL (initial program load) by triggering a single CPU instruction to perform a single channel I/O operation to read from a specified device (selected numerically by dials on the front panel). The first read operation loaded in just enough additional instructions to start more read operations to bring in enough of a boot loader to load the entire OS image. Then it branched to the OS and things took off. Again, there was no firmware I/O support other than these machines did have separate "I/O channel processors". The OS had to do whatever it would do on it's own.
Fast forward to the emergence of BSD and Linux on PC. The BIOS is used to load the boot loader which loads the OS. The boot loaders generally do use the BIOS API, but in theory, they should not have to. The OS (32 bit and 64 bit versions now) don't need, and generally can't use, the BIOS API.
So I say, get rid of it. Let's not have an I/O API in the BIOS anymore. Then let's quit calling it a BIOS (because it won't be that anymore).
That leaves 2 functions which what we now call a BIOS does already, which we still need to do. One is to configure the hardware. This is one of the hard parts because it has to be tailored to the chipset and maybe even CPU involved. The other is to load the operating system.
The hardware configuration could be handled in a different way. By adding on a 2nd smaller (maybe 16-bit) CPU, it can run a firmware program separate from the OS (the host CPU) that not only configures the hardware, but can also constantly monitor it while the OS is running. It could even be networked for those 10,000 machine server farms.
This same extra CPU could also do the boot loading. But it wouldn't need to do much device I/O. It should have the ability to read a few basic devices (serial port, USB, Firewire, floppy, CDROM, ethernet, and IDE/SATA hard drives) sequentially from a specified starting point and load blocks into RAM or into flash memory (or flash to RAM). Put it in a loop and it can do this with megabytes of OS images directly (this serving as the full boot loader). Flash memory of 4MB to 16MB would be plenty (for now).
I doubt we'll ever get a totally non-proprietary machine. But at least by having no more OS to firmware interfacing, we can eliminate some of the issues. And the extra control processor (something the later IBM mainframes already have many of anyway) will enhance the hardware support as well.
If you can't find them, then you aren't looking very hard. Put the URL to your current job openings in your Slashdot signature and you could start to get them. But drop the CS requirement. While more good programmers have gone through such programs, there are lots of good ones that have not (look at their experience to see). BTW, one of the best programmers I ever had working for me was before that job working as a mechanic at a Pep Boys (he was good at that, too), with barely half a year of college course work done. So don't get into that snobish degree requirement bit. A degree tells you some things about a person, but the lack of one doesn't tell you what they can't do.
And I just blew my money on a new 100 GB hard drive to hold the digital theater version of it.
Financial institutions, such as banks, credit agencies, and payroll processors, should learn something from this aspect of the motion picture industry. Data about people should be treated as just as valuable (because really, it is).
Sloppy ... AND incompetent. I've even found more evidence of their incompetency (but I won't be posting that here).
Using an SSN as an ID is just fine. As the grandparent comment points out, however, the issue is in authentication. In theory, if I have your SSN, I should be able to do no more than refer to you. Sure, I might be able to get information about you with that information. What should never be allowed to happen is to pretend to be you. But if I want into a bank and produce some faked ID and give your SSN I can open an account in your name (with my fake of your signature on the signature card) and put in $250. Then when the checks arrive, I can write a whole bunch at once all over town, for small amounts ($100 here, $200 there) totalling thousands, and disappear with the goods, leaving you to clean up the mess in some town 1000 miles away from where you really live that you've never even been to. The fact that the bank ass-u-me-s I was really you is the flaw in the system.
There should at least be a law that says if you deny being the person who opened the above account, then that bank must produce proof that you (and not someone with your info) actually opened the account and passed the bad checks ... or drop the matter with respect to affecting you. Such a law should cover all businesses that use SSNs in any way, shape, or form. Of course, then banks will have to cover their ass and require fingerprints and photos to open an account.
A 25 year minimum mandatory prison sentence for conviction of identity infringement would help put a stop to this.
Then we still need to deal with the sloppy businesses that let identity infringers do this. Triple corrective costs, plus legal expenses, plus punitive to a million dollars, would send a clear message to such businesses ... as clean as driving an ice pick in their eyes.
So this won't apply to stolen PCs?