fd/c309a162dd30530ddf2819cbcb349e3c08fa34

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