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