Burn the ISO, boot to the CD, then wait a *really* fucking long time for it to scamblefuck the drive. (You can also use a floppy disk...but nowawayd why use something that a magnet could possibly fuck?)
(I have no idea whether or not this is military-grade. Can anyone comment? And if not, provide something *better*?)
Not that I advocate insulting "policemen, firemen, or military officers"...
...but I'd say that the difference is that these people are on the "front lines", so to speak. I'd rather have an IT job where I can surf/. on my spare time rather than have to investigate shootings, put out fires, or make strategy decisions that could potentially costs millions of lives.
A distributed system could, in theory, hedge against that. By submitting your name, you agree that it was unsolicited. If you mistakenly say it was unsolicited, all the spammer has to do is say, "Look, our log says that Mr(s) So-and-So requested this e-mail" (at which point the "spammer" turns into a not-spammer).
In my ideal world, the burden of proof would be on the spammer to show that the bulk e-mail was solicited in the first place. I refuse to believe that gazillions of people willingly sign up for penis enlargement e-mails each day.
How long until there will be a major ISP whose plans include discounts for spam-fighters? (Help us to sue every spammer than sent mail to you and get $9.95 disount on your next bill:) )"
Although this was said in semi-jest, I think it is a good idea.
Imagine if they had some sort of centralized spam-reporting system. Everytime you got spam, you registered it (much like CloudMark's model). Come lawsuit time, you (depending on how much spam you registered) get a chance to cash in on all the spam they sent you.
What about focusing on files that are routinely replaced with trojans, rootkits, etc.?
I'm not saying NOT to do the rest of the files, just that these (I'd think) would be the files that you'd want to check FIRST before the rest of the system.
Perhaps a separate section featuring these targeted areas?
I'm not a programmer.....but I have played with Tripwire on Windows.
I thought it would work much the same way: you'd compare the DB hash with the actual hash of the file to determine its integrity (without regard to its source code).
Burn the ISO, boot to the CD, then wait a *really* fucking long time for it to scamblefuck the drive. (You can also use a floppy disk...but nowawayd why use something that a magnet could possibly fuck?)
(I have no idea whether or not this is military-grade. Can anyone comment? And if not, provide something *better*?)
I'm hitting that on days when I'm busy.
On a side note:
2003-01-09 09:20:20 Symantec's Security Central (articles,news) (rejected)
(I'm not bitter!)
"The secret to flying is to throw yourself at the ground, and miss." - Douglas Adams.
Nice...
Because even if you recreate one with the same name, it's NOT the same account....
A distributed system could, in theory, hedge against that. By submitting your name, you agree that it was unsolicited. If you mistakenly say it was unsolicited, all the spammer has to do is say, "Look, our log says that Mr(s) So-and-So requested this e-mail" (at which point the "spammer" turns into a not-spammer).
In my ideal world, the burden of proof would be on the spammer to show that the bulk e-mail was solicited in the first place. I refuse to believe that gazillions of people willingly sign up for penis enlargement e-mails each day.
Although this was said in semi-jest, I think it is a good idea.
Imagine if they had some sort of centralized spam-reporting system. Everytime you got spam, you registered it (much like CloudMark's model). Come lawsuit time, you (depending on how much spam you registered) get a chance to cash in on all the spam they sent you.
Very streamlined.
Less crap.
Easily customized.
While I don't really know how its search results compare, let's hope that this trend catches on!
(You can look at it online if you want)
Perhaps some sort of rating system?
What about focusing on files that are routinely replaced with trojans, rootkits, etc.?
I'm not saying NOT to do the rest of the files, just that these (I'd think) would be the files that you'd want to check FIRST before the rest of the system.
Perhaps a separate section featuring these targeted areas?
I thought it would work much the same way: you'd compare the DB hash with the actual hash of the file to determine its integrity (without regard to its source code).
How does this not affect Windows?
Considering its history of vulnerabilities, I'd think that this would be pretty important...
D rainage
A ppendage
Can sharks wear this laser watch?