Have you ever seen a good textbook without "introductory" or "introduction to" in the title? Basically, in academic subjects, if it isn't "introductory", it's research. Anything that's been solved before is "trivial".
What did he expect really? That everybody should love him because he snooped around in their systems without permission?
He must have been living under a very large big rock for a long time, if he thought this kind of behaviour has ever been accepted by the authorities and most sysadmins.
And by the way, hacking systems without permission have never been white-hat. At best, I would call it grey-hat, although black-hat is certainly also fitting.
If we start judging people on intentions instead of what they do, I think most people will start complaining. "No, I was only trying to help the sysadmin, so I haven't done anything illegal", is about as stupid as "You thought about stealing that car, so you should go to jail for that".
As for the difference between 24 and 16 -- concert stuff? Thats a hard choice...if you are just going to throw it on the internet...16 IS the right choice as Joto says. I would still argue 24 bit because it gives you far greater headroom to deal with before clipping. it could mean the difference between a bad take and one thats easily salvagable.
That's a good point. With the unpredictable levels at a live recording situation, it is a good thing to have a few extra bits to discard later. I'm mostly used to my home-studio, and can always afford a few seconds to set the level straight, but with live, you usually have to just take your best guess:-)
Are there USB audio adapters that record at 96 KHz? Because I'm used to higher sampling rates than 44 KHz with my Delta 66 (4 track USB card) but it's not portable by any means.
Yes. Most professional soundcards are recording at 96kHz or higher. Some of them are probably portable. Ask your local music store.
Because I'm used to higher sampling rates than 44 KHz with my Delta 66 (4 track USB card) but it's not portable by any means.
So, because you are "used to" higher sampling rates, you think you need them? Why? Is your mics and other recording equipment of so high quality that you can actually hear the difference?
44KHz is fine for recording sine waves up to maybe 16 KHz but not any high frequency signal with harmonic content.
Ever noticed a fairly common consumer recording product called a CD? It uses 44.1kHz/16bit, and is accepted as quite good by both normal listeners and audiophiles. 44.1kHz is more than adequate for recording live concerts, where sound quality can never be premium anyways...
If you can actually hear the difference between 44kHz and 48kHz than you either have unusually good hearing, or you are blaming it on the wrong reasons. It is more likely that what you hear are the differences between cheap recording equipment (which usually only handles 44.1kHz) and more expensive recording equipment (which usually also offers 48kHz). And having the recording in 44.1kHz gives you better quality if you decide to burn to a CD (downsampling reduces quality in noticeable ways).
Seriously, unless you are mastering for a mix, there are almost no reasons to use anything but 44.1kHz/16bit. The main reason for offering higher sample-rates and bit-depth in professional recording gear, is because these recordings will later be subject to digital processing. There's no way any physical recording gear will give you quality good enough for 96kHz/24bit to make sense. The extra bits are there for the same simple reason we use extra digits for intermediate calculations before we round off to get the final result.
You see, tapes themselves are pretty robust, the thing that is most likely to fail is the tape drive - which can easily be replaced.
Ever used an exabyte on a sun? At least I wouldn't trust my data to it, if I didn't have a backup somewhere else... Even floppies are more reliable...
As all media, tapes and tapedrives come in different qualities. Just saying that it's "tape", doesn't mean it's secure.
If a HD fails, what are you going to do, transplant the platters onto a new spindle? *LOL*
And why should the HD fail? Most HD's doesn't fail after even 10 years. But yes, you can get burned, especially with cheaper disk-drives (the kind you are likely to use for backups). If you want to be absolutely safe, make multiple backups, and store them at several different locations, regardless of type of media used.
I 100% agree. If a "feature"'s function is a security hole, that feature should never be implemented. No matter how useful, no matter how many people want it.
So, tell me which planet do you live on? Here are some easily exploitable features:
Removable media
Networks
Internet
Programmable firmware
Compilers and interpreters
Knives and scissors
That is the difference between corporate design and that of open source projects. Open source has no motive to put things like mail scripting into an email app... they aren't subject to the demand of the market. A commercial entity only cares about it's bottom line.
So you think we should never give the user anything useful, right? While I understand what you are trying to say, I think you should think things through a little bit more. Software should emphasize security, and probably more than it does now, but that doesn't mean at all costs.
On top of that Netcraft says the site is running BSD and Apache.
Yeah, it makes sense to not run linux, doesn't it?
Acoording to the site's author,.NET will take over the world. So... Is there a BSD port of.NET now (joke)?
No, but there is an independent implementation called dotGNU. I would be very surprised to find that it doesn't run on *BSD, although I haven't really checked.
What is your boss going to think of you bring up something called "Xouvert?" He's going to think exactly what it sounds like--some sort of hacked-together amateur project.
Yeah. As if XFree86 sounds so fucking professional. If you want to sell it to a moron, call it XFree 2003 or XFree XP. But that won't attract more developers, and that's what's needed now.
If your boss sees something with an impressive, professional name, it's not goint to seal the deal but it's going to open his mind to it, because it shows that you care about that extra last bit of polish.
If that was what my boss though, I would find another boss. Even if it meant taking out the garbage instead. I would expect my boss to care about cost (and maintenance costs), stability, support, compatibility, etc.. Not about the name giving the "extra last bit of polish" (unless we should market it ourselves, but that would probably be as part of a greater package, and then nobody would care about the names of subpackages either way).
DVD Decrypter, Wordpad, Office, Lotus Notes, WinDVD
DeCSS, ed, OpenOffice, Lotus Notes, mplayer. And please don't tell me Lotus Notes is in any way an intuitive name. What is it supposed to be: a multimedia presentation about lotus flowers?
I've heard a few people say "G-nome" or "Guh-nome" for Gnome. Those people and the L-eye-nux people drive me up the wall.
Yeah, especially when we know linux is finnish, and should be spoken lee-nuchs. "eye" is just to make it simpler for you americans... But I agree that this gah-foo stuff gets on my nerves too, especially since they already are english words that have a reasonable english pronounciation:-)
You mean Apple actually has to accept returns of it's product, when it doesn't work? Like, if there was a warranty or something? This is a sad and black day for the software industry, maybe one day we will even have to act responsively...
The last one seems to be a way of getting around mail filters of some kind (maybe on the theory that new unknown words give the message a higher rating). The first one, I have no idea about.
This made me thinking. What does there exist of tools for automated OCR? Most paper copiers do an admirable job of removing staples, feeding one sheet at the time, copying double-sided, and finally stapling both the original and all the copies together. With a scanner inside instead of a copier, this should work just as well for scanning books. Only downside is that you would have to remove the spine, but I think amazon.com can afford that.
It also depends on your purpose of shooting, of course. For both military and terrorist operations, it is much more effective to damage your opponent than it is to kill him. In a battle situation, damaging one opponent, means at least two is out, because at least one other soldier will be needed to carry the wounded soldier away. And for terrorists, it creates a lot more fear in the victims having some of the victims bleeding and screaming, than simply being dead.
I think the answer to your question is quite clear to anyone of the many distinguished gentlemen who frequent this stimulating electronic forum we call slashdot.
SCO is a professional secure, and most importantly real unix, based on the original unix source code. Sometimes hobbyist projects such as fetchmail and linux can be used as cheaper alternatives to professional software, if you are a student or someone else with lots of time and no money. But for a succesfull american corporation, you will quickly find out that you need the real stuff if you are to succesfully compete in todays difficult marketplace.
Throughout the computer industry, SCO is commonly recognized as the best unix out there, and as the forthcoming lawsuit will show, probably the only legal. There are companies, such as IBM, Sun, SGI, and others, that have their own version of unix, but their unixes are nothing but cheap off-shoots from the original SCO source code, and their legality is certainly questionable. Some of these companies are even founded by famous hackers, such as Bill Joy.
Switching to linux may be the worst of all possible alternatives. While it is possible that other companies, such as IBM or Sun will be able to license the original unix source code, there seems to be no hope for the linux community to come up with the money needed for that. Among those with knowledge and an interest in the forthcoming SCO trial, there is no doubt that linux will probably become not just unavailable, but it will most likely be a federal offense. Betting on linux in these times, is as stupid as not accepting jesus and the lord as your savior.
I think that by betting on SCO, you are putting your money on a real winner! There is no doubt that SCO will continue to dominate the marketplace for as long as we can predict the future. Nevertheless, SCO is still pretty old technology. If you some day bring your kids to work, they will be frustrated by the lack of modern games on your server system. If this is a thought that bothers you, I would recommend upgrading to the industry-standard Windows 2000 system, surely a system for a new millenium!
While the "snippets" idea is a good one, it has never really succeded before, even though people have tried.
I suspect the reason for this, is that it simply is a too large scope to have "everything useful". Categorizing all this stuff, throwing away the 99% of junk code, it's just too much work for anyone to do. And making it into a blog isn't going to make it work better.
Sure, let the people who want to, have some fun with it. Follow the discussions, read the code posted, learn from it... But don't ever expect to ever find something you actually need there!
if you can remotely attempt to build an atomic bomb or an ICBM you possess the know-how to encrypt/decrypt data.
Hrmm, ehh, well. If you only worry about the peple capable of building nukes, than your point is valid. But there are plenty of others to worry about, people that could do damage, even if they don't have the resources available to create nukes.
The US, and other large governments, probably all have a few tricks up their sleeve that they don't want to tell the world. Problem is, these are already secret, and there is no way for me or anyone else without security clearances towering up to a mountain to "export" what we don't know. Elementary cryptography is not breathtakingly hard, however.
Hardware encryption I can understand, but software?
Huh, what's the difference? If you can do it in software, you can do it in hardware. If you can do it in hardware, you can do it in software (although possibly much slower). It's the methods that needs to be kept secret, not their particular implementation. There are two things that are stupid, the artificial difference between a software "device", and a method written on paper, and the attempt at hiding what is common knowledge, and can be gained by reading any textbook. But as the original poster already pointed out, this has already changed.
Well, most thermostats I've seen work more like this: "adjust dial randomly by trial and error until desired temperature seems to be somewhat stable". The digits on most room thermostats I've seen can be useful for reference later, but are in no way an indicator of desired room temperature.
I'd be pretty inclined to open up a file named "your_details.zip" from "sales@senao-usa.com", who I emailed 3 months ago but never got a response to, especially if the body of the message says "Here is the information you requested".
Exactly. And you certainly should, it's your job after all. What you shouldn't do is open the.exe file inside the zip-file. Any.exe file sent to you in email should be mentally thought of as could_contain_virus.exe. Most windows-users are not accustomed to thinking in that way. They should ask having the information sent again in a non-dangerous form, or in a corporate environment, contact their sysadm. If none of that works, waiting a few days before opening so the file, so the virus detector have been updated for any new email-viruses is a reasonable compromise.
There's no reason raw machine code needs to be dangerous at all. Modern computers (even PCs) have decent memory protection that'll stop user programs from having direct access to hardware and force them to go through the OS.
Yes, this was the first option I mentioned.
The OS can decide what the user program is allowed to do. Whether it's opening network connections, allocating more memory, writing to screen or file, it *already* goes through the OS anyway. So it's not much of a step to put a few security checks in there.
Putting some checks there is not hard. Making it useful is hard. At the level of system calls, it is very hard to say what a program should be allowed to do in a way that would be useful for an end-user. Let's take a simple example: if you grant it access to the windowing system, how would you limit it to e.g. not controlling other applications through synthetic button and key events?
There is a reason we don't have this kind of security today. It is very hard to get right. Only with a higher-level security architecture, such as java, is it possible to make useful checks about what a program is allowed to do, and what it is not allowed to do. If it is at all possible at the level of system calls, it would be very hard to control in an intuitive manner.
Raw machine code executables are bad because they aren't cross platform, but I don't see why they are necessarily a security issue under a secure OS
Trouble is, there is no such secure OSes that are anywhere close to usable. But there is a lot of research going on in this area. In 10 years, maybe someone will make one of those research OSes into something close to useful. Personally, I find it unlikely, however. There is always a tradeoff between speed, flexibility, and security. Raw binaries is one end of the spectrum, and I don't think they are going away. But there is nifty research going into things like typed assembly languages, etc, and I may be proven wrong (at least I hope so).
Only in the current climate of insecure operating systems. I *want* people to be able to send me cute little applications or games, or interactive data files. Why should we be limited in what we can do because people are so used to the inadequacies of current mass products when there isn't really a technical limitation at all?
Because, there really isn't any realistic alternatives. Any mainstream OS is as vulnerable to the same kind of attack. There are two reasons this doesn't happen however: First; writing effective email-viruses for other platforms than windows is harder, because everyone uses different setups, and different mailclients. Secondly; Their users are generally more knowledgeable. But none of these reasons is technical.
If you want to exchange cute games and toys, send them as java applets, or flash swf-files, or whatever you feel would be reasonably secure.
Ok, to bring another level to it. Why is running an unknown executable dangerous?
Because at some point, you need something that actually uses raw machine code, unless you want a very limited system. Not having this option, and having to run everything through a VM is not a very good option from either a performance or functionality standpoint.
I'm not saying I'm againt secure byte-code interpreted environments, such as Java. Actually, I am all for it, but sometimes you need to do things a bit more low-level than the Java API allows, and that means you'll have to allow executables.
Still, there is a lot that could potentially be done to limit the harm you can do with executables. You can sandbox them in various ways, from intercepting system-calls and let some access-level checker see if you have the right privileges (sometimes called capabilities), to running in a different VM (such as user-space linux), to full emulation (bochs). Whether such security measures should be on by default, and only "trusted" executables should be allowed to do what they do now, or special actions needs to be performed by users to run "untrusted" ones is of course up to debate.
My point is that the problem is only halfways technical. Adding additional security measures can never protect stupid users from doing stupid things. If the e-mail had said: "this app needs to be 'trusted' before you run it, please enable that before clicking on it", you can be sure some users would do that.
The problem, if anything, is more of a cultural issue than a technical one. In windows, users have become accustomed to run random binaries from unknown sources, and the environment has as a result been set up to make it easy. Under unix, you would generally be skeptical of running a binary from someone you don't know or trust, and the environment has generally been set up to make it somewhat harder. Unfortunately, the trend seems to go in windows direction (even on unix). End-users are rarely supportive of security features that make their job harder, even if it is more secure.
Running an unknown executable is always a bad idea. People need to be trained to only open safe file-types they get from untrusted sources.
Slashdot Mirror
Have you ever seen a good textbook without "introductory" or "introduction to" in the title? Basically, in academic subjects, if it isn't "introductory", it's research. Anything that's been solved before is "trivial".
He must have been living under a very large big rock for a long time, if he thought this kind of behaviour has ever been accepted by the authorities and most sysadmins.
And by the way, hacking systems without permission have never been white-hat. At best, I would call it grey-hat, although black-hat is certainly also fitting.
If we start judging people on intentions instead of what they do, I think most people will start complaining. "No, I was only trying to help the sysadmin, so I haven't done anything illegal", is about as stupid as "You thought about stealing that car, so you should go to jail for that".
That's a good point. With the unpredictable levels at a live recording situation, it is a good thing to have a few extra bits to discard later. I'm mostly used to my home-studio, and can always afford a few seconds to set the level straight, but with live, you usually have to just take your best guess :-)
Yes. Most professional soundcards are recording at 96kHz or higher. Some of them are probably portable. Ask your local music store.
Because I'm used to higher sampling rates than 44 KHz with my Delta 66 (4 track USB card) but it's not portable by any means.
So, because you are "used to" higher sampling rates, you think you need them? Why? Is your mics and other recording equipment of so high quality that you can actually hear the difference?
44KHz is fine for recording sine waves up to maybe 16 KHz but not any high frequency signal with harmonic content.
Ever noticed a fairly common consumer recording product called a CD? It uses 44.1kHz/16bit, and is accepted as quite good by both normal listeners and audiophiles. 44.1kHz is more than adequate for recording live concerts, where sound quality can never be premium anyways...
If you can actually hear the difference between 44kHz and 48kHz than you either have unusually good hearing, or you are blaming it on the wrong reasons. It is more likely that what you hear are the differences between cheap recording equipment (which usually only handles 44.1kHz) and more expensive recording equipment (which usually also offers 48kHz). And having the recording in 44.1kHz gives you better quality if you decide to burn to a CD (downsampling reduces quality in noticeable ways).
Seriously, unless you are mastering for a mix, there are almost no reasons to use anything but 44.1kHz/16bit. The main reason for offering higher sample-rates and bit-depth in professional recording gear, is because these recordings will later be subject to digital processing. There's no way any physical recording gear will give you quality good enough for 96kHz/24bit to make sense. The extra bits are there for the same simple reason we use extra digits for intermediate calculations before we round off to get the final result.
Ever used an exabyte on a sun? At least I wouldn't trust my data to it, if I didn't have a backup somewhere else... Even floppies are more reliable...
As all media, tapes and tapedrives come in different qualities. Just saying that it's "tape", doesn't mean it's secure.
If a HD fails, what are you going to do, transplant the platters onto a new spindle? *LOL*
And why should the HD fail? Most HD's doesn't fail after even 10 years. But yes, you can get burned, especially with cheaper disk-drives (the kind you are likely to use for backups). If you want to be absolutely safe, make multiple backups, and store them at several different locations, regardless of type of media used.
Yeah, well. And if you look closer, you will also see that the guy isn't more than half-serious.
So, tell me which planet do you live on? Here are some easily exploitable features:
- Removable media
- Networks
- Internet
- Programmable firmware
- Compilers and interpreters
- Knives and scissors
That is the difference between corporate design and that of open source projects. Open source has no motive to put things like mail scripting into an email app... they aren't subject to the demand of the market. A commercial entity only cares about it's bottom line.So you think we should never give the user anything useful, right? While I understand what you are trying to say, I think you should think things through a little bit more. Software should emphasize security, and probably more than it does now, but that doesn't mean at all costs.
Yeah, it makes sense to not run linux, doesn't it?
Acoording to the site's author, .NET will take over the world. So... Is there a BSD port of .NET now (joke)?
No, but there is an independent implementation called dotGNU. I would be very surprised to find that it doesn't run on *BSD, although I haven't really checked.
Yeah. As if XFree86 sounds so fucking professional. If you want to sell it to a moron, call it XFree 2003 or XFree XP. But that won't attract more developers, and that's what's needed now.
If your boss sees something with an impressive, professional name, it's not goint to seal the deal but it's going to open his mind to it, because it shows that you care about that extra last bit of polish.
If that was what my boss though, I would find another boss. Even if it meant taking out the garbage instead. I would expect my boss to care about cost (and maintenance costs), stability, support, compatibility, etc.. Not about the name giving the "extra last bit of polish" (unless we should market it ourselves, but that would probably be as part of a greater package, and then nobody would care about the names of subpackages either way).
Xine, tcsh, bash, XFree86, GNOME, KDE, Knoppix, pico, joe, Ximian
Quicktime, 4dos, cmd.exe, windows, windows, windows, windows, hackman, pfe32, windows.
DVD Decrypter, Wordpad, Office, Lotus Notes, WinDVD
DeCSS, ed, OpenOffice, Lotus Notes, mplayer. And please don't tell me Lotus Notes is in any way an intuitive name. What is it supposed to be: a multimedia presentation about lotus flowers?
Yeah, especially when we know linux is finnish, and should be spoken lee-nuchs. "eye" is just to make it simpler for you americans... But I agree that this gah-foo stuff gets on my nerves too, especially since they already are english words that have a reasonable english pronounciation :-)
You mean Apple actually has to accept returns of it's product, when it doesn't work? Like, if there was a warranty or something? This is a sad and black day for the software industry, maybe one day we will even have to act responsively...
This comment is really insightfull, and funny, and informative, and it's certainly underrated. You should really give me all your modpoints.
______________________
__R___V_______U____P__
__E___I___A___N____R__
__A___A___T___R____I__
__L___G_______E____C__
______R_______A____E__
______A_______L____S__
More Info Available Here
or
gcmmmtxw bq xqsu ow cwj pxiry gogx
The last one seems to be a way of getting around mail filters of some kind (maybe on the theory that new unknown words give the message a higher rating). The first one, I have no idea about.
Yes, but you would be better of using a meta-search engine to search google.
This made me thinking. What does there exist of tools for automated OCR? Most paper copiers do an admirable job of removing staples, feeding one sheet at the time, copying double-sided, and finally stapling both the original and all the copies together. With a scanner inside instead of a copier, this should work just as well for scanning books. Only downside is that you would have to remove the spine, but I think amazon.com can afford that.
And exactly how is that making things difficult?
Yes, of course. But why do you wonder about that?
It also depends on your purpose of shooting, of course. For both military and terrorist operations, it is much more effective to damage your opponent than it is to kill him. In a battle situation, damaging one opponent, means at least two is out, because at least one other soldier will be needed to carry the wounded soldier away. And for terrorists, it creates a lot more fear in the victims having some of the victims bleeding and screaming, than simply being dead.
SCO is a professional secure, and most importantly real unix, based on the original unix source code. Sometimes hobbyist projects such as fetchmail and linux can be used as cheaper alternatives to professional software, if you are a student or someone else with lots of time and no money. But for a succesfull american corporation, you will quickly find out that you need the real stuff if you are to succesfully compete in todays difficult marketplace.
Throughout the computer industry, SCO is commonly recognized as the best unix out there, and as the forthcoming lawsuit will show, probably the only legal. There are companies, such as IBM, Sun, SGI, and others, that have their own version of unix, but their unixes are nothing but cheap off-shoots from the original SCO source code, and their legality is certainly questionable. Some of these companies are even founded by famous hackers, such as Bill Joy.
Switching to linux may be the worst of all possible alternatives. While it is possible that other companies, such as IBM or Sun will be able to license the original unix source code, there seems to be no hope for the linux community to come up with the money needed for that. Among those with knowledge and an interest in the forthcoming SCO trial, there is no doubt that linux will probably become not just unavailable, but it will most likely be a federal offense. Betting on linux in these times, is as stupid as not accepting jesus and the lord as your savior.
I think that by betting on SCO, you are putting your money on a real winner! There is no doubt that SCO will continue to dominate the marketplace for as long as we can predict the future. Nevertheless, SCO is still pretty old technology. If you some day bring your kids to work, they will be frustrated by the lack of modern games on your server system. If this is a thought that bothers you, I would recommend upgrading to the industry-standard Windows 2000 system, surely a system for a new millenium!
I suspect the reason for this, is that it simply is a too large scope to have "everything useful". Categorizing all this stuff, throwing away the 99% of junk code, it's just too much work for anyone to do. And making it into a blog isn't going to make it work better.
Sure, let the people who want to, have some fun with it. Follow the discussions, read the code posted, learn from it... But don't ever expect to ever find something you actually need there!
Hrmm, ehh, well. If you only worry about the peple capable of building nukes, than your point is valid. But there are plenty of others to worry about, people that could do damage, even if they don't have the resources available to create nukes.
The US, and other large governments, probably all have a few tricks up their sleeve that they don't want to tell the world. Problem is, these are already secret, and there is no way for me or anyone else without security clearances towering up to a mountain to "export" what we don't know. Elementary cryptography is not breathtakingly hard, however.
Hardware encryption I can understand, but software?
Huh, what's the difference? If you can do it in software, you can do it in hardware. If you can do it in hardware, you can do it in software (although possibly much slower). It's the methods that needs to be kept secret, not their particular implementation. There are two things that are stupid, the artificial difference between a software "device", and a method written on paper, and the attempt at hiding what is common knowledge, and can be gained by reading any textbook. But as the original poster already pointed out, this has already changed.
Well, most thermostats I've seen work more like this: "adjust dial randomly by trial and error until desired temperature seems to be somewhat stable". The digits on most room thermostats I've seen can be useful for reference later, but are in no way an indicator of desired room temperature.
Sorry, just a digression :-)
Exactly. And you certainly should, it's your job after all. What you shouldn't do is open the .exe file inside the zip-file. Any .exe file sent to you in email should be mentally thought of as could_contain_virus.exe. Most windows-users are not accustomed to thinking in that way. They should ask having the information sent again in a non-dangerous form, or in a corporate environment, contact their sysadm. If none of that works, waiting a few days before opening so the file, so the virus detector have been updated for any new email-viruses is a reasonable compromise.
Yes, this was the first option I mentioned.
The OS can decide what the user program is allowed to do. Whether it's opening network connections, allocating more memory, writing to screen or file, it *already* goes through the OS anyway. So it's not much of a step to put a few security checks in there.
Putting some checks there is not hard. Making it useful is hard. At the level of system calls, it is very hard to say what a program should be allowed to do in a way that would be useful for an end-user. Let's take a simple example: if you grant it access to the windowing system, how would you limit it to e.g. not controlling other applications through synthetic button and key events?
There is a reason we don't have this kind of security today. It is very hard to get right. Only with a higher-level security architecture, such as java, is it possible to make useful checks about what a program is allowed to do, and what it is not allowed to do. If it is at all possible at the level of system calls, it would be very hard to control in an intuitive manner.
Raw machine code executables are bad because they aren't cross platform, but I don't see why they are necessarily a security issue under a secure OS
Trouble is, there is no such secure OSes that are anywhere close to usable. But there is a lot of research going on in this area. In 10 years, maybe someone will make one of those research OSes into something close to useful. Personally, I find it unlikely, however. There is always a tradeoff between speed, flexibility, and security. Raw binaries is one end of the spectrum, and I don't think they are going away. But there is nifty research going into things like typed assembly languages, etc, and I may be proven wrong (at least I hope so).
Only in the current climate of insecure operating systems. I *want* people to be able to send me cute little applications or games, or interactive data files. Why should we be limited in what we can do because people are so used to the inadequacies of current mass products when there isn't really a technical limitation at all?
Because, there really isn't any realistic alternatives. Any mainstream OS is as vulnerable to the same kind of attack. There are two reasons this doesn't happen however: First; writing effective email-viruses for other platforms than windows is harder, because everyone uses different setups, and different mailclients. Secondly; Their users are generally more knowledgeable. But none of these reasons is technical.
If you want to exchange cute games and toys, send them as java applets, or flash swf-files, or whatever you feel would be reasonably secure.
Because at some point, you need something that actually uses raw machine code, unless you want a very limited system. Not having this option, and having to run everything through a VM is not a very good option from either a performance or functionality standpoint.
I'm not saying I'm againt secure byte-code interpreted environments, such as Java. Actually, I am all for it, but sometimes you need to do things a bit more low-level than the Java API allows, and that means you'll have to allow executables.
Still, there is a lot that could potentially be done to limit the harm you can do with executables. You can sandbox them in various ways, from intercepting system-calls and let some access-level checker see if you have the right privileges (sometimes called capabilities), to running in a different VM (such as user-space linux), to full emulation (bochs). Whether such security measures should be on by default, and only "trusted" executables should be allowed to do what they do now, or special actions needs to be performed by users to run "untrusted" ones is of course up to debate.
My point is that the problem is only halfways technical. Adding additional security measures can never protect stupid users from doing stupid things. If the e-mail had said: "this app needs to be 'trusted' before you run it, please enable that before clicking on it", you can be sure some users would do that.
The problem, if anything, is more of a cultural issue than a technical one. In windows, users have become accustomed to run random binaries from unknown sources, and the environment has as a result been set up to make it easy. Under unix, you would generally be skeptical of running a binary from someone you don't know or trust, and the environment has generally been set up to make it somewhat harder. Unfortunately, the trend seems to go in windows direction (even on unix). End-users are rarely supportive of security features that make their job harder, even if it is more secure.
Running an unknown executable is always a bad idea. People need to be trained to only open safe file-types they get from untrusted sources.