On Mon, Jul 29 2013, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> hm.  there are some pretty serious consequences to feeding arbitrary
> html to your web browser via a file:/// URL.  In particular, your
> browser might execute arbitrary javascript (which itself can interact
> with the rest of your web browsing history and/or logged-in sessions),
> and might fetch data from outside sources (leaking at least information
> about when and from where you read your e-mail, and potentially other
> things).

How is this any different than feeding arbitrary html to your browser
via an http:// URL?  In both cases it might execute arbitrary javascript
and interact with the rest of your browsing history.  Obviously it's not
any different.  I would certainly prefer to interact only with
authenticated content, but that's not a reasonable requirement at the
moment.  Until the entire web is https and all emails are signed I will
continue to need to view, with discretion, some unauthenticated html
content.

I should also point out that the notmuch emacs client processes html
parts directly in the emacs session, which of course faces the same
issues.

> One other approach that would address some of these other issues might
> be to open the html in a separate, temporary profile for your web
> browser, one that doesn't directly interact with your main web browsing
> profile (or any other browser profile).  This would also have the
> advantage of not terminating until the browser profile is closed.
>
> I know that chromium offers as --temp-profile argument that behaves this
> way.  I'm not sure how to do it with iceweasel -- you could do it
> manually, with a combination of -ProfileManager and -no-remote, then
> create a new profile, and then when done clean it up afterwards
> manually, but that sounds like a real pain.

This is a somewhat useful solution, but it faces the same problems of
using multiple sessions when browsing the web.

But none of this is really addressing the underlying issue, which is
that temporary files provided to external viewers are being deleted
prematurely when the viewer opens them in the background.  A more
general solution is still desired.

jamie.