From: David Edmondson <dme@dme.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
notmuch mailing list <notmuch@notmuchmail.org>
Subject: Re: privacy problem: text/html parts pull in network resources
Date: Fri, 30 Jan 2015 12:12:52 +0000 [thread overview]
Message-ID: <cuntwz8eabf.fsf@fenchurch.hh.sledj.net> (raw)
In-Reply-To: <87wq45cvls.fsf@alice.fifthhorseman.net>
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.
prev parent reply other threads:[~2015-01-30 12:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 21:00 privacy problem: text/html parts pull in network resources Daniel Kahn Gillmor
2015-01-21 21:14 ` Austin Clements
2015-01-21 21:36 ` Daniel Kahn Gillmor
2015-01-21 22:39 ` Austin Clements
2015-01-21 21:46 ` David Bremner
2015-01-22 7:25 ` Tomi Ollila
2015-01-25 17:51 ` David Bremner
2015-01-28 3:47 ` Daniel Kahn Gillmor
2015-01-28 4:44 ` Jinwoo Lee
2015-01-28 23:57 ` Jinwoo Lee
2015-01-29 18:03 ` Daniel Kahn Gillmor
2015-01-29 18:14 ` Jinwoo Lee
2015-01-30 12:12 ` David Edmondson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cuntwz8eabf.fsf@fenchurch.hh.sledj.net \
--to=dme@dme.org \
--cc=dkg@fifthhorseman.net \
--cc=notmuch@notmuchmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).