It's not bullshit. Get over it. Interestingly, there are very few people who know of this issue, but knowledge is spreading.
There are tens of thousands of data centers in operation in the United States, and likely an order of magnitude above that worldwide.
In each, often hundreds (or even thousands) of computers are consolidated in one room.
You simply cannot convince me that this is a real problem that we need to worry about. Yes, OBVIOUSLY you don't start pouring out bags of metal filings into your ventilation system. We already KNEW that. But not buying anything made from zinc? No way. We'd have data centers shutting down all over the place, if as Rich Hill says, "Metal on floor panels and even in computer cases can secrete zinc crystals over time."
The state said, "The outages... highlight why the state's various websites should be brought under one authority." Huh? What? The answer is that they needed some excuse, they found Data Clean, and they got it. I would bet top dollar that if an indepdendent team were brought in, an entirely unrelated cause would be found.
There is nothing special or unique about the computers in that particular office.
It's just a completely normal office. They are blaming their computer problems on some esoteric, invented problem rather than what's really causing them.
The person they interviewed, from Data Clean, specializes in building "clean rooms." Never in the history of computers have we needed a clean room to operate a computer. Obviously Rich Hill just wants some extra contract work.
Does anyone else find it somewhat offputting that they include links to both validate their XHTML and validate their CSS on the bottom of their homepage, yet both return a number of errors stating that their page is neither valid XHTML nor uses valid CSS?
Even more oddly, for a brief instant when I went to their homepage, I got a default Apache index listing, rather than their homepage. It included links to things such as their PHP MyAdmin directory, a number of PHP files, and three zipfiles named Bruce-someversionnumbers.zip.
Thus, it only tries to install stuff the first time (because thereafter it works) and it does this without actually running any wares to track usage.
Yes, but consider that the mere existence of the application shows whether or not the album has been played on your PC. This is only a small step away from the RIAA subpoenaing your hard drive and proving that not only have you played the CD, but that you have no proof of having ever bought it, and thus are infringing a copyright. The slope gets slippery quickly. I'll agree that the software wasn't likely written with the intention of tracking your habits, but to say outright that it doesn't, or can't, is a lie.
Macrovision does NOT install any spyware, shareware, malware or any self-replicating code of any kind onto a user's PC.... When playing a (Macrovision CDS-200) copy-protected CD for the first time, playback software components may be installed, if needed.
If the software behaves differently when the CD is played for the first time then indeed it is altering the user's computer, to track how many times the CD has been played (zero, or more than zero for example). That's tracking the user's habits, thus spyware. And, by the fact that it is not made clear to the user that software is being installed on their PC, that's malware in my book.
I haven't seen the software myself, nor yet found a detailed technical analysis, so I can only speculate beyond that point. But from the descriptions I've seen, I would not doubt that it continues running, even when the CD is not actually playing, using some amount of memory and some small number of CPU cycles. Can you imagine if every audio CD you own installed its own little software in this manner? Personally, I own around 300 CDs, which is not nearly as many as some of my friends. I surely wouldn't want 300 such applications intalled on my system!
You seem to have missed my point entirely, I'm afraid.
You're talking about envelopes. Like I said, email is not like mail in envelopes.
Email is like postcards. It's sent as plain text that anyone along the way can read. Having a "law" that says people can or cannot read it doesn't change the technical reality.
If you want to do the equivalent of putting your email in an envelope, you've got to encrypt it.
Simple as that. And if you do it properly, neither your ISP nor your government can read it.
Out of curiousity, does your "click here" blurb trip SpamAssassin's click-through tests?
Indeed, the message ends up with a negative score in SpamAssassin, because it has proper "In-Reply-To" and "References" headers and such. And since it quotes the text of the original message, at the bottom, it gets through any Bayesian filters and such they have as well, unless their message was very spammy in the first place. (In which cast it's their own fault, not mine.)
More words:... Imagine the widespread mail-reading that is now determined -at least in the mentioned juridstictions- to be legal.
More words: If you don't want people reading your mail, you use an envelope. If you don't want people reading your email, you use encryption. Simple as that. It's always been that way, from the days of ARPANET. Nothing's changed.
I respond to those all the time. I politely send a "please don't auto-reply to forged spam" message. It's not my fault that your anti-spam solution is stupid enough to re-define an email reply to mean that you should accept forged mail.
I'm sure I'm not the only one who has just one word to say in response to that... Huh?
Seriously, if you would "reply" to the confirmation autoreply, you'd just get another email back saying, again, I don't know who you are, and I get a lot of spam, so please click this link if you want your message (this time, your "reply") to be delivered. Your "reply" would not get through, nor would the original (forged) message be released for delivery by you "replying" to the message.
Yes, I would definitely like to make this stuff publicly available; I know a lot of people would be interested. I need to find a good way to do it. I'm a bit worried about drawing needless attention to myself by releasing such a thing--for example, the system is NOT foolproof, so I could certainly see myself becoming a target for attacks and such.
Hopefully I'll find some free time later this summer (two big big programming projects I'm working on now are ending next month) and I'll see if I can take a weekend and put a site together. I'll submit it as a story to Slashdot (and if it doesn't make it, post it in my signature and leave comments about it everytime someone mentions spam here).
The unfortunate thing is that making this public will increase work for me, of course (people needing help with installations, or submitting patches, etc.), so I'd like to find a way to mitigate the work involved. I don't really know what's involved in setting up an open source project; perhaps I'll look into SourceForge and see what the deal is. Normally I write commercial software; I don't know whether or not something like this could be sold or not. Obviously, if people were paying for it, providing support and taking time away from paying projects wouldn't be as big a problem for me since I'd be compensated.:-)
Alternatively, I've also gotten suggestions that I should keep the software to myself, and offer a paid service where my servers are the MX (mail) hosts for people's domains, giving them POP and IMAP access. I've actually been doing exactly that for my friends over the past six months or so; it's worked out well (four domains for friends currently) but I'm not sure how much the system can scale before I start running out of resources (bandwidth, CPU time, etc.). I'd really have to calculate everything carefully and work out the economics in order to do something like that as a real commercial venture.
You have no idea how many legitimate messages you fail to get because the sender couldn't be bothered, or quite simply can't (i.e. automatic sender, but non-spam) click that link.
Yes, I'm pretty sure I do. Like I said, I've been using this email address for almost 15 years now, and have a pretty good idea of who I correspond with. Very rarely do I get messages on my primary address from completely random people who I've never met before. It's more for personal correspondence. The idea is that since I am (conveniently) a real person, and the people I correspond with are also (conveniently) real people, I also talk to these people in the real world. So there's a backup channel of communication, and I'd certainly know about missing messages.
I am very liberal in my whitelist for people I don't know well. For example, if I correspond with Jim Michael Stevens, jmstevens@carbonred.com, who I've just met, I will whitelist all of...
Stevens, Jim Jim Stevens Jim M. Stevens Jim Michael Stevens James M. Stevens James Michael Stevens Stevens, James jmstevens@carbonred.com
And I won't associate any particular IP addresses with those until I know him a bit better (I'll do 0.0.0.0/0). Once I know his patterns, I'll tighten the whitelist for him a bit (although I'm not really sure this is necessary, today, because I actually have a number of correspondents without any IP whitelists to go with their entries, and haven't had problems with spam making it through from them, but I'm sure eventually spammers will start being more selective in their "From" addresses).
Now, I don't post my primary email address in public places anymore. So the only way for a new person to get that address is for me, or someone I know, to give it to them. Normally, I'll give people I don't know a different, temporary address first that allows ANY messages to come through (I have a whole subset of these set aside ahead of time, so I can give them off the top of my head); I'll later whitelist that address just for them, once I get messages, and eventually start corresponding with them using my regular address (whitelisting them first). That also prevents the situation of a double-verification deadlock, if someone I write to is ALSO using a similar system. Since I initially always correspond with an "open" address, I am guaranteed to receive their verification request.
So that just leaves if someone I don't know gets my email address from someone I know. In that case, it seems unlikely that if they went to the trouble of writing me a message, that they wouldn't take the two seconds to click the link in the return message (which states politely that if they don't, there message will end up being deleted).
I've actually gotten messages from my friends' moms or grandparents... who have had NO problems figuring out the system and clicking on the links. So it can't be too complicated to use. And I'm not too worried about people running email software that can't handle hyperlinks directly (an old version of PINE for example), since anyone using such "obtuse" software these days will also be smart enough to know how to copy and paste.
A success rate of 95% really sucks when (like me) you get just over 2,500 spams a day. That'd still mean around 125 spams a day would be getting through. (I've had the same email address since the early 1990's, back when there was no reason to keep your email address "secret.")
Personally I do use SpamAssassin, but as an intermediate step.
First step: Check a whitelist of known senders. Deliver if the sender is on the list, AND the message originated from an IP subnet that I allow for them personally.
Second step: Scan with SpamAssassin. If the score is really high (above 20) throw it the hell out.
Third step: If the score is less than 20, and the person wasn't whitelisted, run the message through TMDA and politely tell the sender I'm not sure who they are, and I get a lot of spam, and could you please click this link to prove that you're a real person.
I've been using this three-step system for eighteen months now, and out of over one million messages that have come into my mailbox (really), exactly FOUR spam messages have made it all the way through. Apparently the spammers decided to go ahead and click on the little link, or they used a real person's return address, and when that person got they autoreply, they were too stupid to understand what was going on.
Even better, I have not received ANY indiciation that I've lost any messages; at least, no one has ever mentioned anything about an email that I didn't get.
I've got five other people at my domain using the same system, although for not quite as long (one for fifteen months, three for about a year, and one for just a month now); they have all had similar success.
So based on those numbers I'd estimate a success rate of 99.9997% for eliminating spam (which is, admittedly, COMPLETELY INSANE), and a false-positive (or at least "lost message") rate of 0% so far (fingers crossed). A few people have had to confirm their messages, of course, but I've whitelisted them as that happens.
I actually wrote all the connecting code in PHP, believe it or not, with a MySQL database as a backend. It's invoked using.qmail files. PHP is indeed good for things other than web pages; and was a little bit easier for me to maintain and deal with than Perl. The whole thing is less than 25KB of code. There is also a web backend which I use to configure it; that adds another 40KB.
The whole system took about twelve hours of programming to set up, on one Saturday.
Now, for correspondence to companies (such as Microsoft, or Amazon.com), I use a different scheme (although it's handled by the same PHP code). I create up a unique email address for each of them, which ONLY allows mail to or from that domain (for example "rptamazon@mydomain.com" only allows messages from amazon.com). Those addresses are also easily cancellable, individually, if the company starts to annoy me with spam. Basically, each email address can be assigned its own unique whitelist, and can be cancelled individually at any time, through the little web interface.
I also have a number of email addresses for things such as customer support for our company (I write computer software). I'm using the same system for those, also, but instead of checking whitelists based on the sender, I've found a simple way to do it is to check for ANY of our product names anywhere in the message body or subject. If the message doesn't mention any of them, it sends a simple autoreply back similar to that in (3) above, but mentioning that the message didn't seem to be about any of our products, but if it was, please click here, blah blah. We don't have a high volume of support messages (about one or two a day; we're a small company) but in the last year only three or four people have had to click through like that, and, honestly, their support requests were so f*cked up anyways that I'd rather it just dropped them on the floor.;-)
Priceless! I was trying to figure out how the hell this could possibly work, until I hit the last paragraph.... Somebody mark the parent as the best troll of the year!
Sorry I wasn't able to respond sooner (I really was asleep), but I didn't make that up.
Here are some links about it the hairdryer attack.
The RAM isn't less reliable because it is non-volatile, you idiot.
Not true. See this post for details on how having to refresh memory introduces errors. NVRAM is inherently stable because it doesn't need to be refreshed every few milliseconds, so you don't have the possibility of the refresh cycle introducing errors.
ECC RAM will pick up flipped bits and they are reported.
Right, that was exactly my point; there is no reason that we shouldn't all be using ECC RAM, yet there are still dumbasses out there who insist on saving $5 on their $1000 system by buying non-ECC RAM.
No, that's wrong. The truth is that errors in dynamic RAM can be introduced on each refresh. As you said yourself, dynamic RAM needs to be refreshed every few milliseconds--read and rewritten. Each time that happens, it's possible for an error to be introduced. If the refresh circuitry reads the value incorrectly, you get an error. If it writes the value incorrectly, you get an error. The longer the RAM sits around, the more refresh cycles, so the greater the chance for errors. If the voltages aren't stable enough, for example, you'll find a "1" bit refreshed with slightly too low of a current so that when the next refresh comes around, it's read as a "0" as it's been discharging over time and falls just below the threshhold to be read as a "1".
As far as errors not being introduced when the memory is "idle," you're thinking of static RAM. Static RAM doesn't need to be refreshed, and thus actually CAN be idle. So it holds a huge advantage here. Without the refresh cycle, there's no place for errors to be introduced except during the actual reads and writes by the processor.
I'm saying it's a software bug when your code reads:
JNZ 112
when it was supposed to read:
JZ 112
If the programmer explicity wrote it as "JZ 112", it's a bug in the software due to the fault of the programmer. If the machine randomly flips a bit and switches it, it's a bug in the software due to the fault of the memory.
Just because memory caused the bug in the software to appear doesn't mean it's not a software bug. Memory isn't any less capable of adding bugs to software than an incompetent programmer is.
I've done this before in some of the software I've written for hospitals and banks; it's been a design requirement for the software to detect when there is a failure, and to correct if possible.
And, yes, failures ARE detected, AND corrected.
The way it works is you divide memory up into blocks (for example, 512 bytes of 1KB). You do this for both your data and code. For each memory block, store the ECC data (usually, in a separate area of memory, so it's non-intrusive to the program design).
A thread runs in the background, often on a second CPU, continuously checking the program's data and code to ensure that the ECC data is valid. When an error is detected, it is logged and corrected if possible.
When modifying data, a flag is set for that memory block that it has been altered; a new ECC value is calculated as soon thereafter as possible. (This is done automatically by setting the CPU to generate an exception when writing to a particular segment. It's a feature built into Intel processors and available through high-level calls in both Windows and Linux.)
I'm sure you remember the Java exploit from a couple of years back, where the security model was bypassed completely by blowing a hairdryer on the RAM until a byte code error was induced in very-carefully-constructed code. Software ECC is the kind of thing you need to do to mitigate those types of attacks.
Now if I'd use my computer to control a nuclear power plant or medical equipment, I'd certainly use ECC-RAM only. But then, I'd probably use more reliable components all over the place.
Well, I do use my PC for software development, and I surely don't want to be shipping buggy software to customers because I saved $2 buying non-ECC RAM. Really--$2. That's all the price difference is these days. Check out Crucial or NewEgg. There's no reason to go non-ECC. ECC isn't any slower (paranoid folks will tell you it is; not true--266 MHz is 266 MHz, and CAS 2 is CAS 2), and the reliability is tops.
It's funny you mention things like a "corrupt file system" being a larger risk--most modern operating systems (including Windows and Linux) use a large amount (often most, if you have a lot) of your RAM as a disk cache. If a bit flips in one of those areas, you are very likely to end up with corrupt data on your drive, such as a corrupt inode. Where do you think such errors come from? They don't come from the drives themselves, which rely extensively on Reed Solomon ECC.
You described a harware bug (last time I checked RAM was still considered hardware)..... I was talking about a software bug.
Every time a bit flips in a code segment, what do you think happens? More likely than not, a bug is introduced into the software at that address. A JZ instruction turned into a JNZ, for example (0x74 into 0x75). Memory errors do indeed cause software bugs.
They ran a six-hour memory test 54 times--and found that with 512MB of RAM, after each six hour test there were an average of four bits that had flipped! That means there is a memory error on a 512MB PC--on average--every 90 minutes!
If that error occurs in a code segment in a driver, you may get a system crash. In a Windows DLL, perhaps some system instability. In an application, perhaps an application crash. If it's in a data segment, your important manuscript may suddenly lose a paragraph or skip a couple pages as a linked list pointer jumps to the wrong spot, or you may find a bunch of junk replacing normal text.
Memory errors are a serious problem that very few people acknowledge. Why people still buy non-ECC RAM is beyond me. (Of course, even with ECC RAM, there are still various places inside the PC where failure can occur--along the various buses for exmaple, which don't all have ECC. So this is only part of the solution.)
More reliable RAM would definitely be a step in the right direction.
Although I can see how someone might think the parent post was a troll, it does present a somewhat reasonable strategy, from a game theory point of view, for Cisco... basically a Grim Trigger strategy. Cisco threatens the Canadian government that they'll pull out of their market entirely if they don't cooperate with them. Cisco doesn't have much to lose, but Canada has a LOT to lose.
Slashdot Mirror
In each, often hundreds (or even thousands) of computers are consolidated in one room.
You simply cannot convince me that this is a real problem that we need to worry about. Yes, OBVIOUSLY you don't start pouring out bags of metal filings into your ventilation system. We already KNEW that. But not buying anything made from zinc? No way. We'd have data centers shutting down all over the place, if as Rich Hill says, "Metal on floor panels and even in computer cases can secrete zinc crystals over time."
The state said, "The outages
I read the article, and I call bullshit. And FUD.
There is nothing special or unique about the computers in that particular office.
It's just a completely normal office. They are blaming their computer problems on some esoteric, invented problem rather than what's really causing them.
The person they interviewed, from Data Clean, specializes in building "clean rooms." Never in the history of computers have we needed a clean room to operate a computer. Obviously Rich Hill just wants some extra contract work.
Does anyone else find it somewhat offputting that they include links to both validate their XHTML and validate their CSS on the bottom of their homepage, yet both return a number of errors stating that their page is neither valid XHTML nor uses valid CSS?
Even more oddly, for a brief instant when I went to their homepage, I got a default Apache index listing, rather than their homepage. It included links to things such as their PHP MyAdmin directory, a number of PHP files, and three zipfiles named Bruce-someversionnumbers.zip.
I haven't seen the software myself, nor yet found a detailed technical analysis, so I can only speculate beyond that point. But from the descriptions I've seen, I would not doubt that it continues running, even when the CD is not actually playing, using some amount of memory and some small number of CPU cycles. Can you imagine if every audio CD you own installed its own little software in this manner? Personally, I own around 300 CDs, which is not nearly as many as some of my friends. I surely wouldn't want 300 such applications intalled on my system!
You seem to have missed my point entirely, I'm afraid.
You're talking about envelopes. Like I said, email is not like mail in envelopes.
Email is like postcards. It's sent as plain text that anyone along the way can read. Having a "law" that says people can or cannot read it doesn't change the technical reality.
If you want to do the equivalent of putting your email in an envelope, you've got to encrypt it.
Simple as that. And if you do it properly, neither your ISP nor your government can read it.
Out of curiousity, does your "click here" blurb trip SpamAssassin's click-through tests?
Indeed, the message ends up with a negative score in SpamAssassin, because it has proper "In-Reply-To" and "References" headers and such. And since it quotes the text of the original message, at the bottom, it gets through any Bayesian filters and such they have as well, unless their message was very spammy in the first place. (In which cast it's their own fault, not mine.)
I respond to those all the time. I politely send a "please don't auto-reply to forged spam" message. It's not my fault that your anti-spam solution is stupid enough to re-define an email reply to mean that you should accept forged mail.
... Huh?
I'm sure I'm not the only one who has just one word to say in response to that
Seriously, if you would "reply" to the confirmation autoreply, you'd just get another email back saying, again, I don't know who you are, and I get a lot of spam, so please click this link if you want your message (this time, your "reply") to be delivered. Your "reply" would not get through, nor would the original (forged) message be released for delivery by you "replying" to the message.
Yes, I would definitely like to make this stuff publicly available; I know a lot of people would be interested. I need to find a good way to do it. I'm a bit worried about drawing needless attention to myself by releasing such a thing--for example, the system is NOT foolproof, so I could certainly see myself becoming a target for attacks and such.
:-)
Hopefully I'll find some free time later this summer (two big big programming projects I'm working on now are ending next month) and I'll see if I can take a weekend and put a site together. I'll submit it as a story to Slashdot (and if it doesn't make it, post it in my signature and leave comments about it everytime someone mentions spam here).
The unfortunate thing is that making this public will increase work for me, of course (people needing help with installations, or submitting patches, etc.), so I'd like to find a way to mitigate the work involved. I don't really know what's involved in setting up an open source project; perhaps I'll look into SourceForge and see what the deal is. Normally I write commercial software; I don't know whether or not something like this could be sold or not. Obviously, if people were paying for it, providing support and taking time away from paying projects wouldn't be as big a problem for me since I'd be compensated.
Alternatively, I've also gotten suggestions that I should keep the software to myself, and offer a paid service where my servers are the MX (mail) hosts for people's domains, giving them POP and IMAP access. I've actually been doing exactly that for my friends over the past six months or so; it's worked out well (four domains for friends currently) but I'm not sure how much the system can scale before I start running out of resources (bandwidth, CPU time, etc.). I'd really have to calculate everything carefully and work out the economics in order to do something like that as a real commercial venture.
You have no idea how many legitimate messages you fail to get because the sender couldn't be bothered, or quite simply can't (i.e. automatic sender, but non-spam) click that link.
...
... who have had NO problems figuring out the system and clicking on the links. So it can't be too complicated to use. And I'm not too worried about people running email software that can't handle hyperlinks directly (an old version of PINE for example), since anyone using such "obtuse" software these days will also be smart enough to know how to copy and paste.
Yes, I'm pretty sure I do. Like I said, I've been using this email address for almost 15 years now, and have a pretty good idea of who I correspond with. Very rarely do I get messages on my primary address from completely random people who I've never met before. It's more for personal correspondence. The idea is that since I am (conveniently) a real person, and the people I correspond with are also (conveniently) real people, I also talk to these people in the real world. So there's a backup channel of communication, and I'd certainly know about missing messages.
I am very liberal in my whitelist for people I don't know well. For example, if I correspond with Jim Michael Stevens, jmstevens@carbonred.com, who I've just met, I will whitelist all of
Stevens, Jim
Jim Stevens
Jim M. Stevens
Jim Michael Stevens
James M. Stevens
James Michael Stevens
Stevens, James
jmstevens@carbonred.com
And I won't associate any particular IP addresses with those until I know him a bit better (I'll do 0.0.0.0/0). Once I know his patterns, I'll tighten the whitelist for him a bit (although I'm not really sure this is necessary, today, because I actually have a number of correspondents without any IP whitelists to go with their entries, and haven't had problems with spam making it through from them, but I'm sure eventually spammers will start being more selective in their "From" addresses).
Now, I don't post my primary email address in public places anymore. So the only way for a new person to get that address is for me, or someone I know, to give it to them. Normally, I'll give people I don't know a different, temporary address first that allows ANY messages to come through (I have a whole subset of these set aside ahead of time, so I can give them off the top of my head); I'll later whitelist that address just for them, once I get messages, and eventually start corresponding with them using my regular address (whitelisting them first). That also prevents the situation of a double-verification deadlock, if someone I write to is ALSO using a similar system. Since I initially always correspond with an "open" address, I am guaranteed to receive their verification request.
So that just leaves if someone I don't know gets my email address from someone I know. In that case, it seems unlikely that if they went to the trouble of writing me a message, that they wouldn't take the two seconds to click the link in the return message (which states politely that if they don't, there message will end up being deleted).
I've actually gotten messages from my friends' moms or grandparents
A success rate of 95% really sucks when (like me) you get just over 2,500 spams a day. That'd still mean around 125 spams a day would be getting through. (I've had the same email address since the early 1990's, back when there was no reason to keep your email address "secret.")
.qmail files. PHP is indeed good for things other than web pages; and was a little bit easier for me to maintain and deal with than Perl. The whole thing is less than 25KB of code. There is also a web backend which I use to configure it; that adds another 40KB.
;-)
Personally I do use SpamAssassin, but as an intermediate step.
First step: Check a whitelist of known senders. Deliver if the sender is on the list, AND the message originated from an IP subnet that I allow for them personally.
Second step: Scan with SpamAssassin. If the score is really high (above 20) throw it the hell out.
Third step: If the score is less than 20, and the person wasn't whitelisted, run the message through TMDA and politely tell the sender I'm not sure who they are, and I get a lot of spam, and could you please click this link to prove that you're a real person.
I've been using this three-step system for eighteen months now, and out of over one million messages that have come into my mailbox (really), exactly FOUR spam messages have made it all the way through. Apparently the spammers decided to go ahead and click on the little link, or they used a real person's return address, and when that person got they autoreply, they were too stupid to understand what was going on.
Even better, I have not received ANY indiciation that I've lost any messages; at least, no one has ever mentioned anything about an email that I didn't get.
I've got five other people at my domain using the same system, although for not quite as long (one for fifteen months, three for about a year, and one for just a month now); they have all had similar success.
So based on those numbers I'd estimate a success rate of 99.9997% for eliminating spam (which is, admittedly, COMPLETELY INSANE), and a false-positive (or at least "lost message") rate of 0% so far (fingers crossed). A few people have had to confirm their messages, of course, but I've whitelisted them as that happens.
I actually wrote all the connecting code in PHP, believe it or not, with a MySQL database as a backend. It's invoked using
The whole system took about twelve hours of programming to set up, on one Saturday.
Now, for correspondence to companies (such as Microsoft, or Amazon.com), I use a different scheme (although it's handled by the same PHP code). I create up a unique email address for each of them, which ONLY allows mail to or from that domain (for example "rptamazon@mydomain.com" only allows messages from amazon.com). Those addresses are also easily cancellable, individually, if the company starts to annoy me with spam. Basically, each email address can be assigned its own unique whitelist, and can be cancelled individually at any time, through the little web interface.
I also have a number of email addresses for things such as customer support for our company (I write computer software). I'm using the same system for those, also, but instead of checking whitelists based on the sender, I've found a simple way to do it is to check for ANY of our product names anywhere in the message body or subject. If the message doesn't mention any of them, it sends a simple autoreply back similar to that in (3) above, but mentioning that the message didn't seem to be about any of our products, but if it was, please click here, blah blah. We don't have a high volume of support messages (about one or two a day; we're a small company) but in the last year only three or four people have had to click through like that, and, honestly, their support requests were so f*cked up anyways that I'd rather it just dropped them on the floor.
Then, as a very last ste
Wow.
You really don't understand what a "bug" is, do you? You should pick up a nice technology dictionary some day when you get a chance.
Well, that and perhaps get a bit of an additude adjustment.... Bugs can come from many places other than the original programmers.
Priceless! I was trying to figure out how the hell this could possibly work, until I hit the last paragraph.... Somebody mark the parent as the best troll of the year!
Sorry I wasn't able to respond sooner (I really was asleep), but I didn't make that up.
Here are some links about it the hairdryer attack.
CNet News
Some professor's lecture notes (Google Cache)
It's quite real. If you deny that such attacks exist, you're living in a fantasy world.
Sorry--that should have read "512 bytes or 1KB" ... not "512 bytes of 1KB." Too many typos means it's time for me to head to bed....
The RAM isn't less reliable because it is non-volatile, you idiot.
Not true. See this post for details on how having to refresh memory introduces errors. NVRAM is inherently stable because it doesn't need to be refreshed every few milliseconds, so you don't have the possibility of the refresh cycle introducing errors.
ECC RAM will pick up flipped bits and they are reported.
Right, that was exactly my point; there is no reason that we shouldn't all be using ECC RAM, yet there are still dumbasses out there who insist on saving $5 on their $1000 system by buying non-ECC RAM.
No, that's wrong. The truth is that errors in dynamic RAM can be introduced on each refresh. As you said yourself, dynamic RAM needs to be refreshed every few milliseconds--read and rewritten. Each time that happens, it's possible for an error to be introduced. If the refresh circuitry reads the value incorrectly, you get an error. If it writes the value incorrectly, you get an error. The longer the RAM sits around, the more refresh cycles, so the greater the chance for errors. If the voltages aren't stable enough, for example, you'll find a "1" bit refreshed with slightly too low of a current so that when the next refresh comes around, it's read as a "0" as it's been discharging over time and falls just below the threshhold to be read as a "1".
As far as errors not being introduced when the memory is "idle," you're thinking of static RAM. Static RAM doesn't need to be refreshed, and thus actually CAN be idle. So it holds a huge advantage here. Without the refresh cycle, there's no place for errors to be introduced except during the actual reads and writes by the processor.
No. Why would you say that?
I'm saying it's a software bug when your code reads:
JNZ 112
when it was supposed to read:
JZ 112
If the programmer explicity wrote it as "JZ 112", it's a bug in the software due to the fault of the programmer. If the machine randomly flips a bit and switches it, it's a bug in the software due to the fault of the memory.
Just because memory caused the bug in the software to appear doesn't mean it's not a software bug. Memory isn't any less capable of adding bugs to software than an incompetent programmer is.
And how exactly is one expected to code against this?
It's not difficult.
Just add ECC in software.
I've done this before in some of the software I've written for hospitals and banks; it's been a design requirement for the software to detect when there is a failure, and to correct if possible.
And, yes, failures ARE detected, AND corrected.
The way it works is you divide memory up into blocks (for example, 512 bytes of 1KB). You do this for both your data and code. For each memory block, store the ECC data (usually, in a separate area of memory, so it's non-intrusive to the program design).
A thread runs in the background, often on a second CPU, continuously checking the program's data and code to ensure that the ECC data is valid. When an error is detected, it is logged and corrected if possible.
When modifying data, a flag is set for that memory block that it has been altered; a new ECC value is calculated as soon thereafter as possible. (This is done automatically by setting the CPU to generate an exception when writing to a particular segment. It's a feature built into Intel processors and available through high-level calls in both Windows and Linux.)
I'm sure you remember the Java exploit from a couple of years back, where the security model was bypassed completely by blowing a hairdryer on the RAM until a byte code error was induced in very-carefully-constructed code. Software ECC is the kind of thing you need to do to mitigate those types of attacks.
Now if I'd use my computer to control a nuclear power plant or medical equipment, I'd certainly use ECC-RAM only. But then, I'd probably use more reliable components all over the place.
Well, I do use my PC for software development, and I surely don't want to be shipping buggy software to customers because I saved $2 buying non-ECC RAM. Really--$2. That's all the price difference is these days. Check out Crucial or NewEgg. There's no reason to go non-ECC. ECC isn't any slower (paranoid folks will tell you it is; not true--266 MHz is 266 MHz, and CAS 2 is CAS 2), and the reliability is tops.
It's funny you mention things like a "corrupt file system" being a larger risk--most modern operating systems (including Windows and Linux) use a large amount (often most, if you have a lot) of your RAM as a disk cache. If a bit flips in one of those areas, you are very likely to end up with corrupt data on your drive, such as a corrupt inode. Where do you think such errors come from? They don't come from the drives themselves, which rely extensively on Reed Solomon ECC.
You described a harware bug (last time I checked RAM was still considered hardware)..... I was talking about a software bug.
Every time a bit flips in a code segment, what do you think happens? More likely than not, a bug is introduced into the software at that address. A JZ instruction turned into a JNZ, for example (0x74 into 0x75). Memory errors do indeed cause software bugs.
There are very little volatile-memory related software bugs.....
Oh, are you SURE about that? You should research such statements first, my friend, rather than assuming.
Take a look at this review from last year of power supplies by Anandtech.
They ran a six-hour memory test 54 times--and found that with 512MB of RAM, after each six hour test there were an average of four bits that had flipped! That means there is a memory error on a 512MB PC--on average--every 90 minutes!
If that error occurs in a code segment in a driver, you may get a system crash. In a Windows DLL, perhaps some system instability. In an application, perhaps an application crash. If it's in a data segment, your important manuscript may suddenly lose a paragraph or skip a couple pages as a linked list pointer jumps to the wrong spot, or you may find a bunch of junk replacing normal text.
Memory errors are a serious problem that very few people acknowledge. Why people still buy non-ECC RAM is beyond me. (Of course, even with ECC RAM, there are still various places inside the PC where failure can occur--along the various buses for exmaple, which don't all have ECC. So this is only part of the solution.)
More reliable RAM would definitely be a step in the right direction.
Although I can see how someone might think the parent post was a troll, it does present a somewhat reasonable strategy, from a game theory point of view, for Cisco ... basically a Grim Trigger strategy. Cisco threatens the Canadian government that they'll pull out of their market entirely if they don't cooperate with them. Cisco doesn't have much to lose, but Canada has a LOT to lose.