New E-Mail Vulnerability - Trust Your Neighbor?

Anonymous Coward writes: "According to this article in The New York Times (free registration required), a trick enables someone to essentially bug an e-mail message so that the spy would be privy to any comments that a recipient might add as the message is forwarded to others or sent back and forth. The vulnerability could facilitate the harvesting of e-mail addresses. Widely used e-mail programs that are vulnerable to the exploit (because they enable JavaScript) include Microsoft Outlook, Outlook Express and Netscape 6." A snippet from the article: "The potential for such e-mail spying was first discovered by Carl Voth, an engineer in British Columbia. 'What bothers me is that in this case, my vulnerability is a function of what you do,' Mr. Voth said. 'I can be careful, I can take every precaution, I can turn off JavaScript, and it doesn't matter. If my neighbor isn't diligent and I send him an e-mail, I'm still vulnerable.'" "The Privacy Foundation, an educational and research organization based in Denver, plans to publicize and demonstrate the technique today."

Comments

Wrong!

[www.sorehands.com]

SPAMMERS have been using html in emails. They setup an cgi script to pick up an email address from the message. That part of the caller passes the sent email to a script back on the server through an image call.

It's a way to confirm the reading of a message.

How about "Plain Text" mode in Eudora (and equiv)

[The_Laughing_God]

In 20+ years of emailing, I have only come across one situation where I was even tempted to send or recieve anything remotely resembling HTML e-mail (namely 'rich text' color to clarify or emphasize variables or passages buried in group code) and even then I prefer MIME attachments.

Further, my primary mail program (Eudora 4.22) is set to "send plain text only" and "don't ask". If I reply to or forward an HTML e-mail, all HTML is stripped out *before* sending (I tested it with an array of HTML spam "from the wild")

This setting should be basic netiquette (for email programs so equipped - and the feature should be *expected* for e-mail programs) Alas, in a world where even the carriage return is considered a nicety, I don't hold out much hope.

If you don't can't send javascript, the recipient can't carelessly mishandle it.

{I welcome any INFORMED, TESTED observations on the deficiencies of this method. One can never be too paranoid)

Don't forget to disable HTML viewing of e-mail (Warning: often the provided check-box alone is not sufficient), and be stingy about what programs are permitted to access the usual HTTP ports. These are virtually painless security procedures. I can't recall ever being particularly inconvenienced by them.

Re:Another reason to stick to the RFC

[teeth]

I agree with the idea that, generally speaking, email should be plain text with formatting only existing in terms of the usual text formatting technqiues, such as newlines, *emphasis* and so on

There are already mail clients (Gnus for one) which parse informal markup - _underlining_, *bold*, /italic/ - delimited sigs and URLs in plain text messages without any of the bandwidth or security implications.

You can have your cake and eat it :)

Re:Minor Nitpick

[roca]

That's a rather tough assessment of Javascript. It certainly has its flaws, but on the other hand, it has made a lot of interactive Web-based applications possible that wouldn't have been doable otherwise.

Javascript has been standardised by ECMA for some time. There have been many security issues, but it's not clear that alternative technologies for doing the same things would have been safer.

Why plain text and copy are best

[WillSeattle]

As you no doubt know, the no registration version of the article is here.

That said, just as with web gnats/bugs, invisible GIFs, and suchlike, there are many ways to avoid this:

1. Use PINE. Who needs graphics anyway?
2. Turn off all Java, Javascript, etc and view all emails as Text. Then use the Copy and Paste functions to forward only the From:, Subject:, and Date: fields in the email along with the body of the text.
3. If you want to forward pictures or attachments, save them to a file, and convert any DOC or other embedded files to a non-embedded format such as ASCII Text. Then create an email and attach those new files instead.
4. Hunt down and launch boycotts and similar actions against the creators of these things. Show no mercy.
5. Send a copy of all such spam to all your legislators - municipal, county, state, federal, president/etc. Send it with the attachments and javascript. Include your name and adress in the forward so the spam software on their end will not put it in the spam box, and ask them what they will do about it. And send a copy to uce@ftc.gov for fun.

Security models?

[gattaca]

Surely the problem is not with HTML or Javascript in emails at all - its more to do with the fact that email browsers have a poor (if any) security model.

One of the good things about client-side Java (rather than Javascript) is that it runs in a sandbox with a well defined security model that doesn't allow, for instance, content to be uploaded from the client machine unless you specifically say that that's OK by jumping through various hoops.

The post refers to two problems: firstly, Javascript making a connection from a client machine when the client user doesn't want that to happen, and secondly, mailreaders allow modifications (such as adding content) to an HTML document, but do not distinguishing between the original copy and the modified one. (By warning of embedded Javascript, or content stripping, or whatever).

The problem is more to do with client browsers having a crap security model rather than the idea of having HTML or Javascript in an email in itself.
I guess that most people who read or post to slashdot are happy with being able to use markups in their posts so they can italicise or embolden things or add links. HTML in text is a Good Thing here, are emails that different?

Active content is another step along the way, but I can't see that it is a Bad Thing, if the security model is good. I don't know enough about Javascript to comment about whether this is possible. Any comments?

Re:Security models?

[PigleT]

"Surely the problem is not with HTML or Javascript in emails at all - its more to do with the fact that email browsers have a poor (if any) security model."

Surely the problem is with your "neighbour" who can forward anything he likes to whosoever he likes, not with the "technology" at all?

This is what GPG is about: you have a trust model that you can use to pin folks down more responsibly to what they send where, and when you no longer trust someone as much as before, you have the means to say so - making the incentive for them not to do nasty things to your private mails. In that regard, this is nothing new - pass on, nothing to see here.
~Tim
--
.|` Clouds cross the black moonlight,

Re:Security models?

[gattaca]

Yup. The problem is with people not implementing active-content enabled browsers properly. I'm simply saying that in this case we should shoot the messenger, not the message.

Re:Security models?

[gattaca]

Surely the problem is with your "neighbour" who can forward anything he likes to whosoever he likes, not with the "technology" at all?
Yeees, except that the Internet's a dangerous place and you have to accept that horrible people will try to do horrible things. So, trying to enforce accountability and honesty is a good thing, but you also have to protect yourself with appropriate software.

Re:Another reason to stick to the RFC

[boing boing]

I do believe that I agree with you that everyone should stick to non-HTML mail, but one HTML capability should be in all mail forms, and that is HTML links. I can't tell you how many relatives that I have that couldn't possibly figure out how to copy and paste something into their browser. Links are a necessity, but lets get rid of javascript and images right now.

Re:Minor Nitpick

[roca]

The DOM APIs are not "totally nonstandardized". In fact they have been standardized by the W3C. The APIs supported by Mozilla/Netscape6 are basicallly just a little less and a little more than W3C DOM2. Konqueror is catching up fast. Opera is lagging behind a bit but is basically on the same path.

Only Microsoft, and WinIE in particular, are deliberately avoiding proper support for the standard DOM. But the subset of the W3C DOM that works in IE 5.5 is actually quite large and very useful.

Simple Fix: Edit sendmail.cf...

[BigBlockMopar]

Here's a simple fix. Edit sendmail.cf.

Make a filter:

Any e-mail that comes to you with X-Mailer: Microsoft Outlook Express 5.50.4133.2400 or similar in the headers, gets relayed to /dev/null.

Soon, the Windows proles will realize that sending to you is fruitless and will eventually go away.

Okay, fine, it's not practical, but it would still be fun to do.

Or, you could use Outlook's many vulnerabilities to break into your boss's computer and change his Windows startup tune to this in order to prove the point.

He doesn't use Outcast any more. I consider that to be a victory.

we're always at the mercy of neighbours

[CarrotLord]

no matter if everyone used pine for email, we would still be vulnerable to our friends' email stupidity -- for eg, I often get forwarded chain letters from friends who include my address along with the "CC this email to spammer@spamcity.com to win your prize" address... the biggest bugs in out email systems are people...

rr

Another reason to stick to the RFC

[Masem]

A few weeks back we had a discussion here about a new email client for Linux that was 'compatible' with LookOut, including support for HTML email. I posted a small rant on why that's not a feature, but a bug, and a few called me a ludite.

*THIS* type of vunerability is exactly one of the reasons that you should not be using HTML for email, particular with the email clients that use an embedded browser window to display the information. Because not only do you as a malicious email sender gain access to the bugs that arise from the email client itself (eg the ability to email everyone in the address book from a script), but bugs inherit from the browser.

The email RFC says to stick to plain text for all messages, and if you do that, the only bugs that you will encounter will be those that are from the mailers, and it will be very hard to trigger security problems such as this. You might complain about losing formatting and such, but that's also why the Rich Text format was developed; it carries enough of the HTML formatting that some need to emphasis email but none of the deadweight that can trigger security and privacy violations. Unfortunately, RTF wasn't highly accepted and after MS did a nice 'embrace and extend' of it, it was pretty much worthless.

Re:Another reason to stick to the RFC

[YU Nicks NE Way]

So, let me get this straight...there's an exploit based on an element of the RFC (read and return receipts) and an element of the display code (DOM/CSS support). From this, you immediately conclude that the DOM/CSS/HTML support is the problem. I suggest that you're showing the typical NIH attitude of unix-geeks: if we didn't create it, it's wrong. I'd like to advance the notion that the novel idea might be fine, and that the original RFC is clearly wrong.

Why do you, the sender, need to know that I read your e-mail, much less be able to insert an arbitrary message body into that read receipt? You don't! It's not HTML/DOM/CSS support that's a problem here, it's the original designers that put a clear invasion of privacy into their mail protocol. E-mail was designed to mimic memoranda, and the parallel is pretty good -- but it isn't perfect. For my part, I'd rather that e-mail clients didn't ever send rr's; that would have been better design. If I want you to know that I read your mail, I'll respond, thank you very much.

HTML e-mail is pervasive because the bulk of users find it useful. Just because you and I don't doesn't make it less useful to them.

Re:Another reason to stick to the RFC

[mpe]

*THIS* type of vunerability is exactly one of the reasons that you should not be using HTML for email, particular with the email clients that use an embedded browser window to display the information .The problem is in feeding whatever is in the email directly to a web browser. It's a cheap hack probably the reason why someone came up with HTML for email in the first place.

The email RFC says to stick to plain text for all messages, and if you do that, the only bugs that you will encounter will be those that are from the mailers, and it will be very hard to trigger security problems such as this. You might complain about losing formatting and such, but that's also why the Rich Text format was developed .

Alternativly there is markup of the human readable kind. e.g. *bold* _underline*, etc. Which an hald decent program can understand.

Re:Another reason to stick to the RFC

[Masem]

Here's where you need to be careful.

Let's say, in my HTML email with your client, I sent: <IMG SRC="mysecret.server.com/cgi/tracker.pl" HEIGHT=1 WIDTH=1> Where in the tracker.pl script, I just query the HTTP environment variables to tell what host the request came from and another other juicy details I might get, then return a 1x1 GIF image. There's no Javascript, and I don't need you to click on anything -- I just need you to open it and I can get information.

HTML email is still very dangerous, and should be avoided.

Re:Another reason to stick to the RFC

[MikeTheYak]

I don't think there is, other than hogging up space. The problem with images is in HTML mail is that they are often served remotely.

Re:Another reason to stick to the RFC

[MemRaven]

Netscape does this. I can tell it to use JavaScript for web pages, but to disable it for mail/news, which is precisely what I've done. I'm not sure which client you're using, but mine works just fine.

Re:Another reason to stick to the RFC

[Masem]

MIME encoded attachments aren't the same as HTML email -- first, I've yet to see a mail client open these by default, and surprisingly a large number of 'newbies' know well enough not to open an attachment from an unknown source thanks to things like Melissa and ILOVEYOU. HTML email rarely gives you that option, or at least, the embedded browser window that is used to view the email, and will open everything without question. Second, MIME headers are standard text formats, so I with mutt or pine can figure out that you sent me a picture using LookOut or Eudora, and can save that attactment to a file. I've yet to see any specific standard for HTML email -- do you send it as an attachment? as the message? with the plain text version of message? Generally if you and your sender are using the same client, that's not a problem, but even two html-award email clients may view HTML differently, and the message will be garbled at one end. If you have to send something else besides text, MIME attachments are the right and RFC'd way to go.

Re:Another reason to stick to the RFC

[Greyfox]

I can't think of any reasonable use of HTML in E-Mail. If you want someone to look at your HTML, send him your fucking URL already.

Perhaps all us text based mail people should start enclosing our mails in HTML flash tags...

Re:Another reason to stick to the RFC

[roca]

MIME is not just about attachments.

> I've yet to see any specific standard for HTML
> email.

Then reread the MIME RFCs.

> do you send it as an attachment? as the message?
> with the plain text version of message?

MIME allows all three. Sending your intended message body as an attachment would be confusing and I don't know why you'd want to do that. That leaves you with the choice of whether you want to send HTML only, or whether you want to send in both formats and let the recipient choose. For the former, you use "Content-Type: text/html" for the message body, and for the latter you use "Content-Type: multipart/alternative" with "text/html" and "text/plain" subparts.

> even two html-award email clients may view HTML
> differently

This is a feature. The HTML should be rendered according to the recipient's preferences. This is actually a great feature of HTML --- I'm sick of reading email wrapped to the sender's screen width instead of my screen width.

> If you have to send something else besides text,
> MIME attachments are the right and RFC'd way to
> go.

You seem to be unaware that MIME lets you choose types for the body of the message too, including options such as "multipart/alternative" that let you provide the same content in different formats. Better reread the RFCs.

Re:Another reason to stick to the RFC

[MikeTheYak]

Maybe because you don't have your own web site? What I don't get is why HTML mail can't simply be sandboxed - no scripting, no initiation of HTTP requests, etc. There's no reason I can think of that HTML couldn't be used for text formatting.

Re:Another reason to stick to the RFC

[Ed Avis]

It's a reason not to implement JavaScript or other scripting languages; it's a reason not to automatically fetch from the Web images and other objects embedded in messages. It's a reason not to do anything network-based just because of what you've received from an untrusted sender.

But to blame this on HTML is mistaken. HTML is just a language allowing you to mark up paragraphs, headings, lists and so on. The problem comes from those who are implementing HTML readers and making them automatically execute fragments of code and automatically download images which are linked to.

Re:Another reason to stick to the RFC

[roca]

The RFCs do NOT say to "stick to plain text for all messages". There are a number of MIME RFCs that are explicitly designed to make it possible to send anything you want in email.

HTML email may or may not be a good idea, but don't try invoking the RFCs to stamp it out, because they're not on your side.

Enable Javascript for Mail and News

[Phaid]

There's an option in Netscape to specifically turn off Javascript support for mail and news - under the Preferences->Advanced tab.

I've been using that as long as I can remember, mainly to prevent Usenet spam posts from launching browser windows and such. I guess now there's an even better reason for it.

Of course, for mail I use pine and tkrat in console and X respectively, so I dont really care much about this.

Re:Enable Javascript for Mail and News

[sulli]

I never, ever turn it on. Of course it should not even be supported - I mean, come on, what do you need it for in an email?!?!? - but keeping it turned off is the best medicine.

The annoying thing is that you have to jump through lots of hoops to do so (set Outlook as "Restricted Sites Zone", disable everything - don't forget that awful ActiveX - and then not turn on defaults again). Whoever designed this stuff should be permanently barred from the industry.

Re:Enable Javascript for Mail and News

[iceT]

That is true, but as soon as you give your email address to ANYONE, you're at the identical risk you are pointing out. Ever been to Bluemountain.com, or hallmark.com? Someone you know decides to send you a 'free' card, and voila, your email is compromised.

There are certain risks with your information, and as soon as you give that information to ANYONE, you are subject to their sensiblities.

An email address that no one knows is nothing...

Re:That's Why.....

[dattaway]

You live in a dull grey world.

I enjoy the soft glow of phosphorescent dots building the font's character.

I suspect you'd be happy in pre-reform Russia, where there was none of that annoying advertising or any bright colors on the street.

I suspect you live in Redmond, where Bill and his partners would never advertise you with any bright colors or loud music.

The Linux command prompt is a hairshirt of denial.

Whatever cranks your tractor.

Re:Minor Nitpick

[roca]

It was the marketers. The engineers originally called it Livescript but the marketers wanted to capitalize on the Java hype.

No free reg

[Yoshi Have Big Tail]

Here is the login-free URL

Re:That's Why.....

[BigBlockMopar]

That's why I can't see any HTML email. Oh sure, you could just ignore everyone that uses it, sorta like buying a Beta VCR and ignoring all those movies that come out on VHS.

Bah.

I use Pine on my Linux boxen and Eudora on my Windows boxen.

My main (and favorite) VCR is a Sony SL-HF500 Beta Hi-Fi.

I rent the new movies on DVD. If I like 'em, I toss a new cassette into the Beta, and hit record. ('Course, they're for personal use only, they may get two viewings before they hit the bulk-eraser.)

Cool thing about Beta, to liken it to e-mail clients, is that it's immune to video virii like Macrovision.

Security

[mheckaman]

That is the unfortunate truth to security; things are only as secure as the weakest link. I would argue that until the current state of email clients, usages, and so forth changes; we should have zero expectation of privacy in email. I would love to think [P]GP[G] will change the world in email privacy, but I suspect that Joe User will just get their key stolen through a javascript hole in their web browser (AKA mail client).

Matt

Re:Security

[jovlinger]

This is why PGP has the option to mark a message as decryptable to screen only. While you are [always] completely hosed if your recipient is malicious, this sort of annotation will make it harder for recipients downstream to compromise you if they are merely lacking in clue.

The lesson is that active documents are a bad idea, unless they have extremely well thought out security infrastructures. Does anyone have pointers to such infrastructures?

Let me also ask my standard question that I've been asking since I first heard of web-bugs: how come there isn't a standard for sending out self contained html document clusters -- several linked pages, with all the graphics and files they need to be viewed? You could then use the standard "you are about to view and insecure page" when you click on any external links they might have.

ASCII Ribbon Campaign - Say NO to HTML in email

[Pac]

/"\
\ /
X ASCII Ribbon Campaign - Say NO to HTML in email
/ \

Originally created in Brazil by Tony de Marco
Better viewed in plain text :)

Re:AOL not affected?

[Keel]

AOL's email client is not OE. It has inferior capabilities. Although many in this discussion apparently think that is a good thing.

Re:That's Why.....

[DeadSea]

Hotmail is said to not be vulnerable. I belive that hotmail (and many other web based email providers) strip out all but some allowed subset of html (sort of like slashdots allowed html in comments.) I use Eudora and when I send a forwarded message it asks me if I want to send it plain or styled. I always select plain.

I believe that any email that passes through webmail, or has html stripped by some email program like Eudora will be innoculated.

Add this to the list of things that web mail programs will have to check for though....

Text/Enriched

[Arker]

The few features of HTML which are actually useful in email are properly used by selecting the Text/Enriched MIME format, see RFC1896.

Some mail gateways discard HTML before forwarding messages - more of them should.

Careful, you may be commiting a Felony [dmca]

[Convergence]

[RE: the no-reg-required link for nytimes]

Does the DMCA not currently state that by violating an access control measure, or publishing information to violate an access control measure that you are commiting a felony and may be subject to jail time and large fines?

You might want to be careful about being so helpful in the future. Let this be a lesson to all of us. Do not use such links for in doing them, you may commit a crime.

-- This batch of insanity brought to you from the letter C and your favorite federal government.

Re:Careful, you may be commiting a Felony [dmca]

[WillSeattle]

They'll take my free speech rights when they pry them from my cold dead clone's body ...

Information must be Free - Knowledge comes at a price, that of eternal vigilance, plus a quarter for a phone call.

This much has always been true...

[somethingwicked]

If my neighbor isn't diligent and I send him an e-mail, I'm still vulnerable.

This much has always been true in ANY private communication. The point of failure will always be what steps the recipient takes/doesn't take to protect that information. In order to communicate with another humna being, this risk is inherent.

Singing "Paranoia may destroy yaaa..."

Dancing Babies and other Trojan Horses...

[SnapShot]

You don't need some technological trick to harvest emails. Just up a web page with an inane joke, animated gif, etc. and include a button that says, "Email to a Friend!". Voila! You've just harvested the email addresses of everyone who received an email from anyone who though the web page was even faintly amusing.

The only defence, until people start treating other peoples emails with more respect, is to keep two accounts. I personally only give out my work address, except to close and technically aware friends, at least then I get paid to read spam...

Active Content Has Its Uses

[amnesty]

I think that HTML has its place in the email world, whether we like it or not. At work our help desk has to respond to emails from other internal departments where they are having trouble with something. And anyone who's tried to help out a friend who doesn't know too much about computers should realize that its incredibly hard to use the phone or even a text email to convey how to do things.

Even the syntax Start -> Settings -> Control Panel -> Display Properties confuses most of them. So the solution that works is to put screenshots to illustrate how to do it. There really isn't any more elegant way short of physically finding the caller and working at his/her desk.

So agreed, we open up the security can of worms when we allow HTML. Perhaps there are solutions... non-HTML ways? Or only allowing internal email html to access resources (images) on the internal network? But many workplaces have important uses for the extra features with HTML, so instead of choosing the easy way out, (abolish HTML) perhaps we can find a better solution, if only out of necessity.

Re:Active Content Has Its Uses

[Alien54]

I think that HTML has its place in the email world, whether we like it or not. At work our help desk has to respond to emails from other internal departments where they are having trouble with something. And anyone who's tried to help out a friend who doesn't know too much about computers should realize that its incredibly hard to use the phone or even a text email to convey how to do things.

The uses I can think of are SPAM - and teenage entertainment.

As far as advertising goes, it would be better so send a person to the legitimate company webpage. Then we can contact the service provider, and get their account cancelled.

As far as teenage entertainment, I suppose there is no accounting for tastes, and I can tolerate occasional emails with fluttering hearts and excessive cuteness from my little sister. (it's family after all)

In a business context, there is a need to get sales types more clued in. I have heard more war stories of sales types getting sent full fize presentation files as attachments in email while on the road on a flaky dial-up, never mind the clients that receive a flash website in their email. There has to be a better solution for that kind of stuff.

Educate your users!

[ghibli]

In our company, we get our users involved in the decision-making process instead of making and trying to enforce blanket security policies without explanation. We regularly educate our users about various e-mail formats and attachment types, their benefits and dangers, as well as other network security issues. By focusing on education instead of enforcing rules, my team has been able to get high levels of user co-operation and posivite feedback.

As you acknowledge, "a great deal of the HTML features are utterly useless in a E-mail." So why not educate others of this fact, instead of chopping it down to a black-and-white issue of all HTML or none at all.

Most users are not stupid, merely ignorant of some details. There is a difference, and much of this ignorance is due to techies that can't clearly express themselves.

Re:Minor Nitpick

[Tackhead]

> And why we continue to use this mistaken nomenclature is beyond me. The associations are common but the technologies are only superficially related. Javascript has a heinous, disorganized API, is weakly typed, etc. ECMAScript is a standardization of the base Javascript API and syntax.

Absolutely correct. But the point is that they both blow goats when implemented in email clients. As Beavis and Butthead point out - "You can't polish a turd."

Actually, they both blow goats in web sites too, but that's not relevant to the bit about turd-polishing or lusers who don't know the difference between a web browser and an email client ;)

RFC1896

[Arker]

A few weeks back we had a discussion here about a new email client for Linux that was 'compatible' with LookOut, including support for HTML email. I posted a small rant on why that's not a feature, but a bug, and a few called me a ludite.

I agree with you this is a bug not a feature, however, if you were not prepared to offer a non-buggy way to make the users who expect this happy, that might legitimately have earned you such an epithet.

Face it, the typical e-mail user these days does expect some formatting capabilities. There is a way to do this without diving into html-hell. See this. The Text/Enriched MIME format was designed to provide formatting capabilities that many users desire without the never-ending problems entailed by using HTML out of place. The makers of Pegasus Mail have taken a very usable approach to satisfy users desires with the minimal messiness on the other end - HTML messages incoming can be parsed internally with a minimal module that only understand the most commonly used and innocous tags, handed off to an external browser for parsing, or simply stripped to text. Formatted messages are normally sent using Text/Enriched, RTF is also available as an option (very useful if you know the recipient to be on a windows box.) So the pmail users can receive these annoying things and read them fine, but when they forward/reply they don't perpetuate the madness.

Re:Failure of non-HTML text formatting...

[mpe]

It would be a great idea of someone would write up a subset of HTML as an RFC that could be used simply for text formatting (STRONG, BLOCKQUOTE, etc. - maybe even TABLE) for email use (and I would image there are many other uses, as well).

A Primary design criteria is that the results should be human readable. e.g. formatting with hard returns and short tags...

Possible solution

[JCCyC]

Sneakemail. Although you'll have to obliterate every email address you currently use, establish a new one and never ever EVER give it to anyone. You only give away aliases created by Sneakemail. The moment one of them is used to send you spam, you delete it.

I'm seriously plan to start using it Real Soon Now(TM), but getting rid of the current ones (and redoing all the subscriptions etc etc) will be a PITA. Yeah, I'm lazy. Sue me.

Re:It's going to get worse

[yoz]

Can you supply any more details?

Re:Wrong! RTFA!

[Jerf]

Last month, I received an email out of the blue from Carl Voth, of British Columbia. Expanding on my research, Carl had discovered an interesting "feature" in certain popular brands of email readers. Using a little bit of JavaScript code embedded in an email message, he found that not only could the sender of a message be notified when an email is opened, but the sender could capture the text of messages when the email is forwarded.

Who labelled the parent of this message insightful? RTFA!

Easy fix...

[thechink]

I use Outlook Express (flame me later), I have disabled all scripting AND only reply or forward in plain text (OE can be setup to do this by default). This way there is no forwarding of any scripts. I'm sure Outlook can be configured the same.

Old News

[vattervi]

Although I am too lazy to go find the article, I remember Slashdot reporting on this several months ago. If I remember correctly, ssn1 (formerly HackerNewsNetwork) first publicized the story. And excellent FAQ on Web Bugs is available at:

http://www.privacyfoundation.org/education/webbug. html

Delete the Javascript in your reply

[scruffy]

I can be careful, I can take every precaution, I can turn off JavaScript, and it doesn't matter. If my neighbor isn't diligent and I send him an e-mail, I'm still vulnerable.

I don't quite understand this comment. Can't you protect yourself by just deleting the Javascript in your reply? Is this nontrivial to do in these HTML mail programs?

Your neighbor could, of course, copy your message into another message with the Javascript.

Re:Delete the Javascript in your reply

[roca]

I think you're right. The mail client should be configurable not just to ignore Javascript in HTML email, but actually strip it out completely before forwarding/replying/etc.

Someone should hack this into Mozilla right away.

Trust Your Neigbor?

[operagost]

Trust your spellchecker?

Minor Nitpick

[Carnage4Life]

But you're only safe if everyone else uses Pine, and everything they know uses, etc. Just need one java-enabled mail program in the link and everything's compromised

Javascript isn't Java, they aren't even related in any way. Java is the architecture-neutral, object-oriented, portable, distributed, robust and secure programming language created by Sun Microsystems that can be used to create applets or standalone applications. Javascript is a scripting language originally designed for embedding in browsers which was created by Netscape in a braindead attempt to win the browser wars which instead fragmented the HTML and brought major insecurity to the web.

Finally I doubt that any email clients are actually Java enabled (i.e. can launch applets, etc).

Grabel's Law

Re:Minor Nitpick

[Fnkmaster]

And why we continue to use this mistaken nomenclature is beyond me. The associations are common but the technologies are only superficially related. Javascript has a heinous, disorganized API, is weakly typed, etc. ECMAScript is a standardization of the base Javascript API and syntax. Javascript embedded in the browser lets you access the in-browser document via some level of DOM-alike API (although these are totally nonstandardized, as we all know - this is generally known by the also-misused nomenclature DHTML, which just means using CSS and layer-type things with Javascript as the active event control structure.

Java may be used in the applet framework, and that may have been part of the early vision of Java but that's now just a sideline to server-side Java, where the ability to build large scale apps without the syntactic complexity of C++ lets you push out business logic with fewer worries about internals.

In general though, the languages are often perceived as a combination of syntax, general usage characteristics, and standardized/available APIs. Java is incredibly different from JavaScript in all of these ways, and the association with "the web" is an artifact of one particular use of Java.

Re:Minor Nitpick

[Fnkmaster]

You misread my comment. I realize that the W3C DOM spec is a standard API. However the only browser as you point out that comes very close to supporting this API is Netscape6/Mozilla/other Gecko based browsers which represent in total no more than a few percent of the browser market right now. I was commenting on the Netscape 4.x and IE 4.x/5.x document.layers and document.all Javascript objects which allow, in very nonstandard ways, access to most of the DOM functionality. Those are the pseudo-DOM/DOM-alike APIs I was referring to.

The point is that a standard that you can't assume support for is a fairly ineffective standard - within a year of so, I think the standard will be pretty much accepted, or at least I hope so. Better to make people download an up-to-date, standards-compliant browser than to have to code 4 different versions of your site.

Of course, the problem is that e-commerce sites can't afford to take that kind of approach. But non-profit sites, general interest sites, etc. can. If they stick to standards compliance, they will drive most people to use standards compliant browsers. And once the market-share of DOM compliant browsers approaches 80% or so, people will stop coding shit for those old nasty browsers.

Re:Minor Nitpick

[joto]

Javascript isn't Java, they aren't even related in any way. Yes, they are. Both contains the word Java in their name (with the possible exception of ECMAScript). Both are associated with the web. Both can be run on the client side. Their syntax looks somewhat superficially similar.

But of course, these are about the only similarites involved. Not too surprising, that is enough to confuse most people.

I hate netscape engineers (or was it marketers) for coming up with the name javascript, if they had called it anything else, most people wouldn't have this problem.

Email tracking

[delmoi]

forward this message to all your frends! Microsoft corp is going is conducting a test of email tracking software, will pay you $2500 for every message you forward. Intel, AOL, ICQ, and Disney corp are also somehow involved!

Heh, this I find interesting. I remember swareing up and down that getting a virus through email was imposible once, to.

So, does this means.....

[carlos_benj]

...that Bill Gates can track how many people I forwarded that email to now? Gosh! I'm sure my check must be in the mail already.

Re:That's Why.....

[nomadic]

But you're only safe if everyone else uses Pine, and everything they know uses, etc. Just need one java-enabled mail program in the link and everything's compromised.
--

Java isn't Javascript

[Carnage4Life]

All I have to say is that if you think Java is insecure

Java is rather secure as can be seen by reading any of the numerous articles on the web about it. Javascript on the other hand is a disaster which was foisted on us by Netscape and excarberated by Microsoft.

PS: You do realize that the NY Times article is discussing a Javascript exploit and not a Java one, right?

Grabel's Law

Failure of non-HTML text formatting...

[singularity]

Eudora used to include the ability to generate formatted, but non-HTML, text. It included everything you mention, and did not include any networking-specific code. It failed (no one else started to use it, so it was Eudora-specific, and HTML mail became all the rage). It would be a great idea of someone would write up a subset of HTML as an RFC that could be used simply for text formatting (STRONG, BLOCKQUOTE, etc. - maybe even TABLE) for email use (and I would image there are many other uses, as well).

Text/enriched seems to cover this (RFC 1896), but that is Eudora's failed attempt.

I would look for most mailers to move to where they get rid of image-fetching and JavaScript.

Re:Failure of non-HTML text formatting...

[roca]

There is XHTML Basic, which is a little subset of XHTML suitable for text messaging. I haven't checked to see if it includes inline images or scripting.

Re:That's Why.....

[larien]

Bzzzt! There was a buffer overflow in pine a while back which was potentially exploitable. In short, you could send a message with a sufficiently long Subject: line and overflow an unchecked buffer.

In true open source style, the bug was fixed pretty quickly and recent versions are, AFAIK, safe.
--

Re:That's Why.....

[iapetus]

I tend to find PINE preferable to most graphical e-mail clients anyway, of course. It's fast and easy to use, I can access it from anywhere, and it isn't prone to all these nasty e-mail viruses. And if I want to view that ugly 'enhanced' content that only spammers seem to send, a tap of the return key loads it into Lynx. :^)

Our organization

[AntiPasto]

relies heavility on Pine on BSD....... is it safe to say we're pretty resilient to any kind of email malay?

----

Re:Our organization

[roman_mir]

If your organization only uses email for internal communications then yes. If there are external contacts you make via your email, then no. Basically it does not matter what you do, it matters what other people you email to do, and probably the people who communicate with the people that you communicate with do, etc.etc.etc. Basically this means we are all screwed.

"I can be careful, I'm still vulnerable."

[MoNickels]

Another reason HTML email is bad, besides: wasted bandwith and storage space, slow loading times, cruddy appearance in text interfaces, interference of ads in personal messages, tracking users' habits by matching email address to cookie, bad cross-platform compatibility, necessity of being connected to view it as intended, being filtered or bounced by no-HTML mail lists, etc., etc. It's not really that much of a surprise.

Active vs passive content in emails

[sharkticon]

This is going to further fuel the debate over whether or not email and news posting should consist of active (JavaScript, DHTML and so on) or passive (plain text, HTML) content. I suppose really it depends on what sort of person you are.

Whilst technically you can convey whatever information you want through the use of plain text (maybe using some *emphasis*) and attachments, for many this is a solution which is less convenient for them - it requires more clicks or keypresses to access, and doesn't present the information in quite such an integrated manner. And in the business world the phrase "time equals money" has been given the status of a law, with companies paying out huge sums of cash to time management consultants and the like. These people don't want any extra time or hassle in their emails, not when they're receiving well over a hundred every day.

For business types active content and embedded files mean more productivity and an easier email experiance. They're not concerned about privacy issues, and if they are then well, it's the job of the IT guys, right? So this sort of bug is inevitable - either you cripple active content - somthing that's too late to do - or you try and provide rock solid security - a challenge people seem only too willing to take on.

It all depends on a) your willingness to expose yourself to risk, and b) your desire for presentation and convenience. Seeing as the web has moved from text-based to graphics-based in the majority, I think the future of email is going to be the same, whether we like it or not.

Desensitized

[tethal91]

I think that I should be worried or annoyed by this but I (we) are so used to security holes, lack of privacy online, and spam that the general level of interest I can come up with is pretty minimal. On the one hand, its pretty sad that there is so much of this stuff that we are desensitized to it; on the other hand, the Internet is still like the Wild West in a sense - its a frontier with the requisite frontier mentality. I'm sure this has been said elsewhere better than I am saying it, but I think that the dynamic of those pushing the boundaries with advances versus those who try to expolit those boundaries versus those that try and stop them creates a better future world. Those of us on the fringes may be the occasional casuality, but maybe, just maybe, its for the greater good...

the point

[www.sorehands.com]

The point I was trying to make is that even with javascript turned off, the information is sent. The original piece gives the impression that if everyone turned off javascript, you'd be safe.

Re:Old News - October 5, 1998

[jij]

Here's a link to the page:

http://www.geocities.com/ResearchTriangle/Facility /8332/reaper-exploit-release.html

Re:That's Why.....

[gowen]

Thats why its imperative that people get back into the habit of *trimming their messages* instead of quoting absolutely everything they recieved.

Re:That's Why.....

[dattaway]

There was a buffer overflow in pine a while back which was potentially exploitable.

I use pine. You have my email address. Now try it.