> WebExtensions are not sufficient to allow an Enigmail extension to run an installed binary

I don't know about the situation in thunderbird, but in firefox this isn't entirely true. It is possible to communicate with a native executable using a JSON protocol over IPC, if that native executable is registered using a manifest file (See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...). so it would be possible to use a wrapper executable that communicates with the extension using native messaging, and invokes gpg as needed. However, as I understand it, the native executable would need to be installed out-of-band (meaning it isn't part of the extension bundle itself).

Instead of trying to reimplement GPG, they could have added the necessary APIs to WebExtensions.

Not directly related, but maybe Thunderbird shouldn't use Gecko to render emails. A smaller renderer with limited features may be sufficient and more secure.

Or... disable any JS runtime in a webview/iframe for the message. I get using an HTML rendering engine, I don't get ever enabling JS.

Worst offense was when Outlook (and Express) used the IE rendering engine with JS in "local" (unrestricted) trust mode. Melissa/ILoveYou etc...

That's about the bare minimum. Does any modern client not do that? But I think an HTML renderer that doesn't even have support for Javascript, audio and video tags, perhaps parts of CSS, etc. has a smaller attack surface.

Automatic playing of audio or video, and no eval support in css would also be a good idea.

> Thunderbird renders untrusted HTML content and therefore is subject to a steady stream of CVEs and must stay absolutely up-to-date with Gecko

Thunderbird will prompt the user to decide whether they want to render remote content. I'm not sure if that's the default setting, but that's how it's worked for me for many years over multiple installations.

That's just for images. There could still be exploits in the HTML itself executing locally.

Is this the case if you have Thunderbird set to view message body as plain text?

Which version of HTML is used for email? No javascript for instance right? Possible to make a reduced parser for which it is easier to verify correctness?

Thunderbird renders HTML using the same rendering engine as Firefox, although the email doesn't use the HTML5 doctype (so it's quirks mode), and several features are disabled (e.g., JS, frames).

There's been a couple of working groups that have attempted to standardize HTML support in email, but they don't get very far on account of having almost no representation from anyone who actually works on email clients (on account of most of the interest being email marketers who want to complain about HTML support).

The actual support for HTML is probably these days mostly HTML5 (in terms of the actual parsing algorithm), with several elements unsupported, and the CSS support being very spotty. Many MUAs are using whitelists of elements to support (don't expect <video> to make it through, and especially not <iframe>), and scrubbing CSS themselves with whitelists. In effect, this means that virtually everything added in HTML5 probably won't work, so the support is more akin to HTML4 in that regard. Infamously, Outlook uses the same HTML rendering engine as Word, which is (was?) based on the IE 5.5 rendering engine.

There is no standard HTML version for email, the same way there is no standard HTML version for a website. The contents can reasonably be anything.

Follow up question: What parts of html do you need implement to render 99% of emails decently accurately?

For a very long time, the limit was Outlook on Windows, which used the Word 2003 parser. So, whatever was supported by Word 2003.

But, more recently, mail campaigns have instead targeted Gmail, so "whatever Gmail renders" (this is not everything a browser renders, but is close). It's not feasible to implement a subset for this and do parallel CVE fixes.

Unfortunately Outlook has a pretty big market share in corporate world and if you're serious about your emails, you still have to support it.

It's worse than IE6. And to help your sanity, use mjml.

Or just don't send weird shit in emails.

Email html rendering is a giant pile of steaming dino dung. No matter how you implement it, you will absolutely break emails.

Thunderbird has simplified html viewer, no css etc, works pretty well.