From: Jameson Graef Rollins <jrollins@finestructure.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: problems viewing attachments in emacs ui
In-Reply-To: <51F68366.5070900@fifthhorseman.net>
References: <87hafe4ox6.fsf@servo.finestructure.net>
	<87ehai4ns3.fsf@servo.finestructure.net>
	<87ob9lipz5.fsf@zancas.localnet>
	<51F68366.5070900@fifthhorseman.net>
User-Agent: Notmuch/0.15.2+223~g3484372 (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-pc-linux-gnu)
Date: Mon, 29 Jul 2013 08:33:13 -0700
Message-ID: <8738qx4c06.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha256; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Type: text/plain

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.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJR9os5AAoJEO00zqvie6q80TMP/RVteKm2ah6pguYMp5UjLdUB
dhrFxozYu+vZxkSLA9f2ESgs8E2j/Sqgw4u/KqX/Sy85fo4cHGuc6l6IxGRY79K1
+8MbYlzRlNrg6pftGSfs3juPsl+h48idqWFLBOeY2HpjdKFmjBgftkEXGjWtHco8
gK1CwLS1c5TC5cU/D1kM2lXKRjI++Nexm4DSq/8RJFnRjZDaKWM4UT6qVnhBqsyv
A9d2SqQy32SylnC5GoQLx4UQEzDoJHb59lNnP+bi2bvypxoOK/B0OPG2l/IHjJz1
o0wbQbcrboAZZehlnnG6+r1weAq7yoPV1XIAHnDKeaC8OVpvah6VPhjGPT3CDnbf
8qlU5Nf+ByccPknY8Zex8ZM3Jm4K6DgW814Ss5CgINzv189pw/GkKEG3BoCaMMuZ
aaslourrzaIESlFVMLw1sSvfll6yFJpGZbqHRJn6As3PrduZ2CsMxSrgCafZcKIC
GOVuWDrFByvXQop6e9uBREkJSg8fv9A5bWVzXev7zVpNY2k12C6AG3lhhU+KAvLj
gOWCrx43iK+4j5tkdB3ubdgcj0eBcTjAjsov5TShR5lRtloJPIAFMko5qqRxTOMI
XP93remEVuB9NK9+0K7Muhq9in20c1dK9+q+sED91tFGcH51+5ufdgTWTho87snK
96fwRNnSquQkj6HliGf5
=71as
-----END PGP SIGNATURE-----
--=-=-=--