Re: privacy problem: text/html parts pull in network resources
authorDavid Edmondson <dme@dme.org>
Fri, 30 Jan 2015 12:12:52 +0000 (12:12 +0000)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:47:56 +0000 (14:47 -0700)
fd/c309a162dd30530ddf2819cbcb349e3c08fa34 [new file with mode: 0644]

diff --git a/fd/c309a162dd30530ddf2819cbcb349e3c08fa34 b/fd/c309a162dd30530ddf2819cbcb349e3c08fa34
new file mode 100644 (file)
index 0000000..18c49ea
--- /dev/null
@@ -0,0 +1,117 @@
+Return-Path: <dme@dme.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 50620431FBC\r
+       for <notmuch@notmuchmail.org>; Fri, 30 Jan 2015 04:13:01 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.739\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.739 tagged_above=-999 required=5\r
+       tests=[DNS_FROM_AHBL_RHSBL=2.438, RCVD_IN_DNSWL_LOW=-0.7,\r
+       UNPARSEABLE_RELAY=0.001] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id V5Xp7bzYA6na for <notmuch@notmuchmail.org>;\r
+       Fri, 30 Jan 2015 04:12:58 -0800 (PST)\r
+Received: from mail-we0-f173.google.com (mail-we0-f173.google.com\r
+       [74.125.82.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id DEEE8431FAE\r
+       for <notmuch@notmuchmail.org>; Fri, 30 Jan 2015 04:12:57 -0800 (PST)\r
+Received: by mail-we0-f173.google.com with SMTP id w62so26787623wes.4\r
+       for <notmuch@notmuchmail.org>; Fri, 30 Jan 2015 04:12:56 -0800 (PST)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=1e100.net; s=20130820;\r
+       h=x-gm-message-state:to:subject:in-reply-to:references:user-agent\r
+       :from:date:message-id:mime-version:content-type;\r
+       bh=nJjy3IanWYwz7kvr8lsOKVX+TBgEiVkH1983C7n8kRc=;\r
+       b=BfvZEEqnYXqnTVwWyd4xeWgQln/ajIXbKKS6OS8Z4KtRSi4NxptL2BiVALYm02yRzI\r
+       EAnzzInG8E83k/1yxs/EhNAibPpiOzwlQHzZgeX602NGgWiJdeD4eFN7U1Ot1KGdl/3m\r
+       LlZXw/iv4tqT9B35K91fRpE5kUBUFatOZagrlLc8fKICBtbWVEzZNH9fU7Qh18JQX3wc\r
+       1jrAX7EtqYtrrRV+eZskUxVzUw6/dTI1lO99R3ztClEzII65IieO0/iMzBPkDSVlzxUx\r
+       yZoj4MapoHADuSflg7RB0UVjZ56zCMms34OZnOKgbpv0WDGUginyVzSzhe4jPiSm1P1X\r
+       DEiw==\r
+X-Gm-Message-State:\r
+ ALoCoQlln+y8+yjCFj9Gxl5GErq1y9jgLR0bJYyqEpltk03ktAbs5SlzIvVLzxnYC81kyuwV+mPV\r
+X-Received: by 10.180.90.206 with SMTP id by14mr4340673wib.0.1422619975559;\r
+       Fri, 30 Jan 2015 04:12:55 -0800 (PST)\r
+Received: from disaster-area.hh.sledj.net\r
+       ([2a01:348:1a2:1:ea39:35ff:fe2c:a227])\r
+       by mx.google.com with ESMTPSA id ud4sm6694477wib.0.2015.01.30.04.12.54\r
+       (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
+       Fri, 30 Jan 2015 04:12:54 -0800 (PST)\r
+Received: from localhost (30000@localhost [local]);\r
+       by localhost (OpenSMTPD) with ESMTPA id 7d366dab;\r
+       Fri, 30 Jan 2015 12:12:53 +0000 (UTC)\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
+       notmuch mailing list <notmuch@notmuchmail.org>\r
+Subject: Re: privacy problem: text/html parts pull in network resources\r
+In-Reply-To: <87wq45cvls.fsf@alice.fifthhorseman.net>\r
+References: <87ppa7q25w.fsf@alice.fifthhorseman.net>\r
+       <87fvay3g0g.fsf@maritornes.cs.unb.ca>\r
+       <871tmfin1k.fsf@alice.fifthhorseman.net>\r
+       <yq65h9vbtsyt.fsf@jinwoo-macbookair.roam.corp.google.com>\r
+       <yq65386uqx0a.fsf@jinwoo-macbookair.roam.corp.google.com>\r
+       <87wq45cvls.fsf@alice.fifthhorseman.net>\r
+User-Agent: none\r
+From: David Edmondson <dme@dme.org>\r
+Date: Fri, 30 Jan 2015 12:12:52 +0000\r
+Message-ID: <cuntwz8eabf.fsf@fenchurch.hh.sledj.net>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Fri, 30 Jan 2015 12:13:01 -0000\r
+\r
+On Thu, Jan 29 2015, Daniel Kahn Gillmor wrote:\r
+> On Wed 2015-01-28 18:57:25 -0500, Jinwoo Lee wrote:\r
+>> Do you mind if I add a boolean defcustom, which determines whether to\r
+>> block remote images?  Its default value will be T (block), but people\r
+>> who want to see remote images can customize it.\r
+>\r
+> I have no objection to this kind of knob in an already fiddly config\r
+> space.  In the other thread, i see the discussion of whether this should\r
+> expose something fancier than a boolean, but given the number of\r
+> possible rendering backends, i don't know how well we can support any of\r
+> these options reliably.\r
+>\r
+> What should notmuch do when the customization variable is set to t\r
+> (block remote images) but the html rendering backend doesn't support\r
+> blocking remote images?\r
+>\r
+> It seems dangerous/disingenuous to offer the option to the user but not\r
+> be able to enforce it in this case.  Should having this set to t\r
+> restrict the range of html renderers to only those that we can force to\r
+> respect it?\r
+\r
+Given that shr is built in to newer emacs, we could restrict notmuch to\r
+only use shr for rendering HTML in those versions. That would cause\r
+problems for someone using an older version of emacs, of course. There\r
+are some things possible with emacs-w3m that are not currently supported\r
+in shr (the proxy support is much more flexible, for example), but that\r
+can be addressed over time.\r
+\r
+For versions where shr is not included, it seems like a difficult\r
+problem. The user can control which renderer is used for HTML, which\r
+makes it impossible for us to ensure that all renderers will obey any\r
+setting that notmuch chooses to use as a default for `block-images' (or\r
+the more complex alternatives).\r
+\r
+We could decide that we will "support" only emacs-w3m on pre-shr\r
+versions of emacs. That would probably involve ensuring that only\r
+emacs-w3m or shr can be selected by the auto-detection mechanism used to\r
+choose a renderer. Of course, if the user configures a particular\r
+renderer by hand, they need to be aware that the `block-images'\r
+restriction may not apply.\r