From: Jameson Graef Rollins Date: Mon, 29 Jul 2013 15:33:13 +0000 (+1700) Subject: Re: problems viewing attachments in emacs ui X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=878b5fa6b9bc8ed656ee6e7a45a443299b493f9f;p=notmuch-archives.git Re: problems viewing attachments in emacs ui --- diff --git a/7c/51196fd64cf261754b6c6ecf3b69dda7ac71c4 b/7c/51196fd64cf261754b6c6ecf3b69dda7ac71c4 new file mode 100644 index 000000000..a0213f8b8 --- /dev/null +++ b/7c/51196fd64cf261754b6c6ecf3b69dda7ac71c4 @@ -0,0 +1,128 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 4C51A431FC3 + for ; Mon, 29 Jul 2013 08:33:34 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Yt9UDycsvy9F for ; + Mon, 29 Jul 2013 08:33:26 -0700 (PDT) +Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu + [131.215.239.19]) + by olra.theworths.org (Postfix) with ESMTP id 220BE431FBF + for ; Mon, 29 Jul 2013 08:33:26 -0700 (PDT) +Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1]) + by earth-doxen-postvirus (Postfix) with ESMTP id A4AB066E01C7; + Mon, 29 Jul 2013 08:33:23 -0700 (PDT) +X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new +Received: from finestructure.net (cpe-76-173-75-27.socal.res.rr.com + [76.173.75.27]) (Authenticated sender: jrollins) + by earth-doxen-submit (Postfix) with ESMTP id 9153266E01A1; + Mon, 29 Jul 2013 08:33:18 -0700 (PDT) +Received: by finestructure.net (Postfix, from userid 1000) + id 212F762289; Mon, 29 Jul 2013 08:33:17 -0700 (PDT) +From: Jameson Graef Rollins +To: Daniel Kahn Gillmor , + Notmuch Mail +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" +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Mon, 29 Jul 2013 15:33:34 -0000 + +--=-=-= +Content-Type: text/plain + +On Mon, Jul 29 2013, Daniel Kahn Gillmor 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----- +--=-=-=--