To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
	notmuch mailing list <notmuch@notmuchmail.org>
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>
	<yq65h9vbtsyt.fsf@jinwoo-macbookair.roam.corp.google.com>
	<yq65386uqx0a.fsf@jinwoo-macbookair.roam.corp.google.com>
	<87wq45cvls.fsf@alice.fifthhorseman.net>
User-Agent: none
From: David Edmondson <dme@dme.org>
Date: Fri, 30 Jan 2015 12:12:52 +0000
Message-ID: <cuntwz8eabf.fsf@fenchurch.hh.sledj.net>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

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.