On 2/3/02 8:02 AM Michael Collette wrote: > be7a wrote: > >> Michael Collette wrote: >>> Normally this buggy behavior doesn't occur, but a recent virus called >>> BadTrans attempts via HTML to launch a still attached virii. >> >> I have several comments: >> >> 1) I don't understand how HTML has the capability to launch /anything/. > > I once looked over the HTML with BadTrans briefly. It was doing something > clever with <iframe> tags trying to embed the executable attachment into > the web page, thus trying to get that bugger to launch. I imagine the > effect here is to get that certain percentage of the population that > doesn't read dialog boxes to click on something.
I just looked at a few web sites to see how BadTrans works. It relies on the user to save and /run/ the attachment. All email viruses I've seen take advantage of the ease with which a careless user can run an attachment. I /still/ don't understand how HTML can launch anything. > > Seems that most of the virii infections I've personally dealt with resulted > from a user trying to go through their mail quickly. Speed facilitates the > accidental clicking on "Yes" rather than the wiser "No" answer. > I agree. Mozilla should warn the user in a popup, *only* when s/he saves anything besides obviously safe file types (like .txt) to disk. This could eventually become a list of file types configured under the "advanced" preferences section. > > Might be a tough sell. The bulk of the public has some notion that E-Mail > propogates virii. That same bulk of folks don't have a clue about the > mechanics of these things. I only base this opinion on the notion that if > they did, we wouldn't have problems with virii! > With a simple warning popup message, Mozilla could help dispell the FUD[1] Micro$oft has perpetuated (because they want to allow things to be executed easily from within their products). A pop-up warning in Mozilla could even include a link to an "email viruses explained" page that discusses this topic in very understandable language. > > Telling folks that they should check everything but E-Mail folders flies in > the face of what they've been getting told up to the point. I'm not saying > that your approach to AV settings is wrong, just that I don't think it > would be understood. > <HalfSerious> You should start a business that caters to newbies. You could develop an SMTP server that removes viruses /as they are received/. Neophytes might pay you a lot of money if you can convince them that this is the only way to be truly safe! </HalfSerious> One could take this even further and develop separate mechanisms for email and file transfers. I don't believe this is useful; nor do I believe Mozilla has to detach the attachments automatically on receipt. I believe Mozilla should have a /simple/ OS boundary where the user requests a file to be attached (encoded) and detached (decoded). PERIOD. Everything else should stay MIME encoded in a standard email format using standard protocols. Always converting attachments to local files to get around user ignorance about viruses is just not a useful way to combat FUD: it perpetuates it further. > > If the concern is disk space, then decoding them attachments on the way in > actually saves quite a bit. Uuencoding tends to bulk up the file size > somewhere from 10-20% (shooting from the hip here) of the original file. > Without testing it personally, I'd guess that double or triple embedding > makes matters worse on actual disk space used. > I agree that uuencoded and base64 attachments use more space, but there are several useful ways to deal with it. One of the great things about IMAP is that you can leave attachments on the server until the user decides what to do with them. Mozilla could use no disk space at all to delete an unwanted attachment. Another neat feature to add to Mozilla someday would be transparent compression. That would /significantly/ speed the sending, transit, and receiving times for many kinds of large files. If Mozilla had this feature, the attachment would often take up less space in its encoded form than the unencoded file uses! > > Anyone who actually reads release notes probably doesn't have much in the > way of virus problems in the first place. It's them folks that don't read > documentation that are the concern, and I'd guess that them folks are > probably in the vast majority. > I agree: people don't pay attention, or they don't understand. Perhaps an ominous popup message would do the trick. Another point to ponder: who is the intended audience for Mozilla? Will AOL ever make Mozilla/Netscape the standard email client for their less-savvy users? The present audience is people who /will/ read the release notes and /are/ willing to take risks with new software. This leads me to propose a two-phased approach. In the first phase (i.e., /now/), when Mozilla has near-zero market share, just document the problem in the release notes. In the second phase, when Mozilla/Netscape gains a larger market share, implement a more sophisticated mechanism that warns the user when they're saving or launching a script or executable file. This might help Mozilla/Netscape /gain/ market share because it's /safer/ than the alternatives! ---- [1] Fear Uncertainty and Doubt -- 6e77a 70 6e 6e7a! Remove the _no_spam_ from my email address to reach me.
