On Tue, Dec 11, 2012 at 12:06:03PM -0600, Derek Martin wrote:
> HTML provides all of the features [...]
HTML also provides all of the bugs.
"Nothin's free." (c.f. "Crossfire", Stevie Ray Vaughan, 1989)
Several points (and these aren't exhaustive, merely illustrative):
1. It is very difficult to conduct a technical exploit against a plaintext
MUA. Not impossible, of course, but very difficult. Adding all the
complexity of an HTML engine vastly increases the attack surface.
And at a time when the Internet-wide state of security is best described
as "horrific and getting worse" one of the very last things anyone
should want/advocate is an increase in aggregate vulnerability.
This clearly gets still worse if users utilize a full-blown web browser,
and yet worse if that browser incorporates Java, Javascript, Flash, etc.
And it probably (but not certainly; jury still out) gets worse again
once HTML5 is widely deployed.
2. HTML email is a spammer/phisher's best friend:
<a href="http://notyourbank.example.com";>YourBank</a>
Add a million variations using scripting and redirectors and
shorteners and typosquatting and everything else. It works all day,
every day, and I think by now we can safely conclude that no amount
of end-user education will ever stop it from working. (See Marcus Ranum's
brilliant essay-rant, "The Six Dumbest Ideas in Computer Security",
and note #5.)
3. HTML enables web bugs, an excellent means to invade the privacy of
users...and worse. Consider, among many scenarios: what happens when all
the data accrued by an entity using these is acquired by a third party,
either because they hacked it or because it was accidentally disclosed or
because it was sold over or under the table? You might trust YourBank
with this information -- although you shouldn't -- but how do you feel
about having all of it handed over to random third parties? Especially
ones that have already demonstrated hostile intent? How do you feel about
The Bad People having every IP address you've ever used to read mail
from YourBank, the MUA/browser versions/extensions you've used, the
timestamps, etc.? [1]
Anyway, my point is that a huge amount of data is being gleaned
from web bugs all day, every day. Given the size of that corpus
and the number of collectors, it's absurd to suggest that it'll
all stay put. Of course it won't. As you're reading this, some
junior server engineer at Example Corp. is writing all the 2008-2012
web bug logs in compressed form onto a 32G USB stick and getting ready
to walk out the door with them at 6 o'clock. Tax-free holiday bonus
for him/her, too bad for you and a bazillion other people.
4. HTML markup in email is uniformly awful. Really. Go look at
some of it. Feed it to htmltidy. Feed it to the W3C validator.
Feed it whatever tool you like. It's not uncommon for the ratio
of errors/line to exceed unity.
This has many consequences, security and otherwise, but one of the more
obvious things that it means is that the HTML-marked-up email message
which looks glorious to the sender may end up being unintelligible rubbish
to the receiver -- depending on which HTML engine both are using.
5. HTML markup in email bloats it. Horribly. I've seen messages expanded
by 2000%. This has impacts all along the way: more bandwidth eaten
at every step. More storage. More CPU chewed up sending, receiving,
scanning, etc.
Do you really think a message marked up with HTML communicates 480%
or 820% or 1750% better than one in plaintext? I don't.
6. Of course point #5 gets still worse when user A responds to user B's
HTML-marked-up message, and user A's MUA tries to mark *that* up, not
recognizing that it was already, and then... There is a military term
for this, and it rhymes with busterduck. I've watched in mute (okay,
and not-so-mute) horror as email exchanges consisting of 1 or 2 lines
each mushroomed into 300K messages. This makes a mere 2000% look
desirable by comparison.
Mobile carriers love all this, of course: makes the cash registers ring
and ring and ring with bandwidth charges.
But in terms of providing efficient, usable, cheap, etc. communication,
it's a disaster. 300K for a "me too" reply? Really?!
7. There are some people (and I think it's fair to say there will
be more) who encrypt their email for various social, economic, personal,
political, etc. reasons.
What's a crytographer's best friend when they're trying to crack
a message or messages?
Known plaintext.
What do HTML markup engines in MUA's insert?
Known plaintext.
Lots of it.
Oops.
I'm going to stop this laundry-list and move on to the following point,
but only because this message is already long enough. So please note:
there are many more issues with HTML email than I've covered here.
8. Let's use your message, the one I'm replying to here, as an example.
It's literate. It's articulate. It clearly communicates. EXACTLY how
would that message be improved by HTML markup? And is that marginal
improvement worth the enormous cost in decreased security, increased
attack surface, message bloat, and everything else?
I don't think so. Not even remotely close.
Now go find some other message by some other person -- 1 that reeds
lik dis u no? -- how, EXACTLY, is that illiterate tripe going to
be improved by HTML markup? (Unless it's redacted by overstrikes,
which would be welcome relief.)
I'm not suggesting, by the way, that all human communication can
be handled by plain text. I'm suggesting that there are numerous
compelling reasons why *email* should be so and that when we find
ourselves faced with those (relatively infrequent) occasions where
that solution is inadequate, HTML markup is not the answer, because
the cost/benefit ratio is hideous.
---rsk
[1] Let's not pretend that YourBank will adequately safeguard this
information. Why should they? It's not *their* data. And the
consequences for losing it are negligible: nobody gets fired, nobody
misses a bonus. And well, good security costs money, money that could
instead be corporate or personal profit. Besides, if it leaks, they
can hold a press conference and use the favorite phrase of organizations
which have just leaked data they should never have had: "nobody could have
foreseen" and the press will dutifully play their role as stenographers
and report that...despite the fact that lots of people foresaw it years
ago and said so.
