privacy problem: text/html parts pull in network resources

[David Edmondson]

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.

Re: privacy problem: text/html parts pull in network resources

[David Edmondson]

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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

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?

--dkg

Re: privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Thu, Jan 29, 2015 at 10:03 AM, 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?

I'm not very knowledgeable in the notmuch codebase, but I think I agree
with your concern about this customization variable being dangerous or
misleading users.

+1 to restricting renderers.

>
> --dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Thu, Jan 29, 2015 at 10:03 AM, 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?

I'm not very knowledgeable in the notmuch codebase, but I think I agree
with your concern about this customization variable being dangerous or
misleading users.

+1 to restricting renderers.

>
> --dkg
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

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?

--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Tue, Jan 27, 2015 at 08:44 PM, Jinwoo Lee  wrote:
> On Tue, Jan 27, 2015 at 07:47 PM, Daniel Kahn Gillmor 
>  wrote:
>> On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
>>> Daniel Kahn Gillmor  writes:
>>>
 If i send a message with a text/html part (either it's only text/html,
 or all parts are rendered, or it's multipart/alternative with only a
 text/html subpart) and that HTML has >>> src="http://example.org/test.png"/> in it, then notmuch will make a
 network request for that image.

 This is a privacy disaster, because it enables an e-mail sender to use
 "web bugs" to tell when a given notmuch user has opened their e-mail.
>>>
>>> I've just pushed Austin's shr related series to master, so this problem
>>> should be fixed as of commit b74ed1c. One tradeoff that we should at
>>> least remark in NEWS, if not actually fix, is that I think there is now
>>> no way to view such images in notmuch.  I don't know offhand what other
>>> html renderers will do.
>>
>> thanks for this, David and Austin!
>>
>> Other html-rendering mail clients that are privacy-conscious will often
>> provide a button or mechanism to indicate that some remote resources
>> were requested by the page but weren't fetched (e.g. a button saying
>> something like [Load Remote Images...]).  I have no idea who actually
>> clicks on those buttons (or why), though, and even if we wanted them,
>> we'd only want to add a button on an image that actually had remote
>> network resources to load, and i don't know how we'd get that
>> information propagated back up the rendering stack to make such a
>> display decision.   So i'm fine with leaving it this way for now.
>
> Well, most promotional emails contain remote images and their contents
> are incomprehensible without those images.  I ignore most of them but I
> do read a few of those promotional emails.  It would be great to have a
> UI for loading remote resources.

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.

>
>>
>> --dkg
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Tue, Jan 27, 2015 at 08:44 PM, Jinwoo Lee  wrote:
> On Tue, Jan 27, 2015 at 07:47 PM, Daniel Kahn Gillmor  fifthhorseman.net> wrote:
>> On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
>>> Daniel Kahn Gillmor  writes:
>>>
 If i send a message with a text/html part (either it's only text/html,
 or all parts are rendered, or it's multipart/alternative with only a
 text/html subpart) and that HTML has >>> src="http://example.org/test.png"/> in it, then notmuch will make a
 network request for that image.

 This is a privacy disaster, because it enables an e-mail sender to use
 "web bugs" to tell when a given notmuch user has opened their e-mail.
>>>
>>> I've just pushed Austin's shr related series to master, so this problem
>>> should be fixed as of commit b74ed1c. One tradeoff that we should at
>>> least remark in NEWS, if not actually fix, is that I think there is now
>>> no way to view such images in notmuch.  I don't know offhand what other
>>> html renderers will do.
>>
>> thanks for this, David and Austin!
>>
>> Other html-rendering mail clients that are privacy-conscious will often
>> provide a button or mechanism to indicate that some remote resources
>> were requested by the page but weren't fetched (e.g. a button saying
>> something like [Load Remote Images...]).  I have no idea who actually
>> clicks on those buttons (or why), though, and even if we wanted them,
>> we'd only want to add a button on an image that actually had remote
>> network resources to load, and i don't know how we'd get that
>> information propagated back up the rendering stack to make such a
>> display decision.   So i'm fine with leaving it this way for now.
>
> Well, most promotional emails contain remote images and their contents
> are incomprehensible without those images.  I ignore most of them but I
> do read a few of those promotional emails.  It would be great to have a
> UI for loading remote resources.

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.

>
>>
>> --dkg
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
> Daniel Kahn Gillmor  writes:
>
>> If i send a message with a text/html part (either it's only text/html,
>> or all parts are rendered, or it's multipart/alternative with only a
>> text/html subpart) and that HTML has > src="http://example.org/test.png"/> in it, then notmuch will make a
>> network request for that image.
>>
>> This is a privacy disaster, because it enables an e-mail sender to use
>> "web bugs" to tell when a given notmuch user has opened their e-mail.
>
> I've just pushed Austin's shr related series to master, so this problem
> should be fixed as of commit b74ed1c. One tradeoff that we should at
> least remark in NEWS, if not actually fix, is that I think there is now
> no way to view such images in notmuch.  I don't know offhand what other
> html renderers will do.

thanks for this, David and Austin!

Other html-rendering mail clients that are privacy-conscious will often
provide a button or mechanism to indicate that some remote resources
were requested by the page but weren't fetched (e.g. a button saying
something like [Load Remote Images...]).  I have no idea who actually
clicks on those buttons (or why), though, and even if we wanted them,
we'd only want to add a button on an image that actually had remote
network resources to load, and i don't know how we'd get that
information propagated back up the rendering stack to make such a
display decision.   So i'm fine with leaving it this way for now.

--dkg

Re: privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Tue, Jan 27, 2015 at 07:47 PM, Daniel Kahn Gillmor  
wrote:
> On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
>> Daniel Kahn Gillmor  writes:
>>
>>> If i send a message with a text/html part (either it's only text/html,
>>> or all parts are rendered, or it's multipart/alternative with only a
>>> text/html subpart) and that HTML has >> src="http://example.org/test.png"/> in it, then notmuch will make a
>>> network request for that image.
>>>
>>> This is a privacy disaster, because it enables an e-mail sender to use
>>> "web bugs" to tell when a given notmuch user has opened their e-mail.
>>
>> I've just pushed Austin's shr related series to master, so this problem
>> should be fixed as of commit b74ed1c. One tradeoff that we should at
>> least remark in NEWS, if not actually fix, is that I think there is now
>> no way to view such images in notmuch.  I don't know offhand what other
>> html renderers will do.
>
> thanks for this, David and Austin!
>
> Other html-rendering mail clients that are privacy-conscious will often
> provide a button or mechanism to indicate that some remote resources
> were requested by the page but weren't fetched (e.g. a button saying
> something like [Load Remote Images...]).  I have no idea who actually
> clicks on those buttons (or why), though, and even if we wanted them,
> we'd only want to add a button on an image that actually had remote
> network resources to load, and i don't know how we'd get that
> information propagated back up the rendering stack to make such a
> display decision.   So i'm fine with leaving it this way for now.

Well, most promotional emails contain remote images and their contents
are incomprehensible without those images.  I ignore most of them but I
do read a few of those promotional emails.  It would be great to have a
UI for loading remote resources.

>
> --dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Jinwoo Lee]

On Tue, Jan 27, 2015 at 07:47 PM, Daniel Kahn Gillmor  wrote:
> On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
>> Daniel Kahn Gillmor  writes:
>>
>>> If i send a message with a text/html part (either it's only text/html,
>>> or all parts are rendered, or it's multipart/alternative with only a
>>> text/html subpart) and that HTML has >> src="http://example.org/test.png"/> in it, then notmuch will make a
>>> network request for that image.
>>>
>>> This is a privacy disaster, because it enables an e-mail sender to use
>>> "web bugs" to tell when a given notmuch user has opened their e-mail.
>>
>> I've just pushed Austin's shr related series to master, so this problem
>> should be fixed as of commit b74ed1c. One tradeoff that we should at
>> least remark in NEWS, if not actually fix, is that I think there is now
>> no way to view such images in notmuch.  I don't know offhand what other
>> html renderers will do.
>
> thanks for this, David and Austin!
>
> Other html-rendering mail clients that are privacy-conscious will often
> provide a button or mechanism to indicate that some remote resources
> were requested by the page but weren't fetched (e.g. a button saying
> something like [Load Remote Images...]).  I have no idea who actually
> clicks on those buttons (or why), though, and even if we wanted them,
> we'd only want to add a button on an image that actually had remote
> network resources to load, and i don't know how we'd get that
> information propagated back up the rendering stack to make such a
> display decision.   So i'm fine with leaving it this way for now.

Well, most promotional emails contain remote images and their contents
are incomprehensible without those images.  I ignore most of them but I
do read a few of those promotional emails.  It would be great to have a
UI for loading remote resources.

>
> --dkg
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

On Sun 2015-01-25 12:51:43 -0500, David Bremner wrote:
> Daniel Kahn Gillmor  writes:
>
>> If i send a message with a text/html part (either it's only text/html,
>> or all parts are rendered, or it's multipart/alternative with only a
>> text/html subpart) and that HTML has > src="http://example.org/test.png"/> in it, then notmuch will make a
>> network request for that image.
>>
>> This is a privacy disaster, because it enables an e-mail sender to use
>> "web bugs" to tell when a given notmuch user has opened their e-mail.
>
> I've just pushed Austin's shr related series to master, so this problem
> should be fixed as of commit b74ed1c. One tradeoff that we should at
> least remark in NEWS, if not actually fix, is that I think there is now
> no way to view such images in notmuch.  I don't know offhand what other
> html renderers will do.

thanks for this, David and Austin!

Other html-rendering mail clients that are privacy-conscious will often
provide a button or mechanism to indicate that some remote resources
were requested by the page but weren't fetched (e.g. a button saying
something like [Load Remote Images...]).  I have no idea who actually
clicks on those buttons (or why), though, and even if we wanted them,
we'd only want to add a button on an image that actually had remote
network resources to load, and i don't know how we'd get that
information propagated back up the rendering stack to make such a
display decision.   So i'm fine with leaving it this way for now.

--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[David Bremner]

Daniel Kahn Gillmor  writes:

> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.
>
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.

I've just pushed Austin's shr related series to master, so this problem
should be fixed as of commit b74ed1c. One tradeoff that we should at
least remark in NEWS, if not actually fix, is that I think there is now
no way to view such images in notmuch.  I don't know offhand what other
html renderers will do.

d

Re: privacy problem: text/html parts pull in network resources

[David Bremner]

Daniel Kahn Gillmor  writes:

> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.
>
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.

I've just pushed Austin's shr related series to master, so this problem
should be fixed as of commit b74ed1c. One tradeoff that we should at
least remark in NEWS, if not actually fix, is that I think there is now
no way to view such images in notmuch.  I don't know offhand what other
html renderers will do.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Tomi Ollila]

On Wed, Jan 21 2015, Daniel Kahn Gillmor  wrote:

> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.

I noticed the same a few days ago and first test to avoid that was 

(defun open-network-stream (&rest) nil)

(but then I tried to send email and that failed ;/)

next was M-x debug-on-entry RER open-network-stream RET

... but I don,t remember how to manipulate how that continues.

Latest I've been thinking defadvice around open-network-stream which
asks whether to proceed to it or just return nil.

I'd like to have buffer-local defadvices... ;) .. but there one could
probably store original open-network-stream location and then flet (or
was it letf) it there...

Anyway, if there is better, more robust alternative I am (also) very
interested of it...

Tomi


>
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.
>
> It's also a bit of a consistency/storage/indexing disaster because it
> means that what you see when you open a given message will change
> depending on the network environment you're in when you open it.
>
> It's also potentially a security problem because it means that anyone in
> control of the remote server (or the network between you and the remote
> server if the image isn't sourced over https) can feed arbitrary data
> into whatever emacs image rendering library is being used.  (granted,
> this is not a unique problem because this can already be done by the
> original message sender with a multipart/mixed message, but it's an
> additional exposure of attack surface)
>
> I just raised this on #notmuch, and i don't have the time or the
> knowledge to look into it now, but i think the defaults here need to be
> to avoid network access entirely unless the user explicitly requests it.
>
>--dkg
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Tomi Ollila]

On Wed, Jan 21 2015, Daniel Kahn Gillmor  wrote:

> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.

I noticed the same a few days ago and first test to avoid that was 

(defun open-network-stream (&rest) nil)

(but then I tried to send email and that failed ;/)

next was M-x debug-on-entry RER open-network-stream RET

... but I don,t remember how to manipulate how that continues.

Latest I've been thinking defadvice around open-network-stream which
asks whether to proceed to it or just return nil.

I'd like to have buffer-local defadvices... ;) .. but there one could
probably store original open-network-stream location and then flet (or
was it letf) it there...

Anyway, if there is better, more robust alternative I am (also) very
interested of it...

Tomi


>
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.
>
> It's also a bit of a consistency/storage/indexing disaster because it
> means that what you see when you open a given message will change
> depending on the network environment you're in when you open it.
>
> It's also potentially a security problem because it means that anyone in
> control of the remote server (or the network between you and the remote
> server if the image isn't sourced over https) can feed arbitrary data
> into whatever emacs image rendering library is being used.  (granted,
> this is not a unique problem because this can already be done by the
> original message sender with a multipart/mixed message, but it's an
> additional exposure of attack surface)
>
> I just raised this on #notmuch, and i don't have the time or the
> knowledge to look into it now, but i think the defaults here need to be
> to avoid network access entirely unless the user explicitly requests it.
>
>--dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[David Bremner]

Austin Clements  writes:

> I have a fix for this on shr buried deep in an old patch series that I
> never got back to: id:1398105468-14317-12-git-send-email-amdragon at mit.edu
>
> For shr, the key is to set shr-blocked-images to ".".  However, IIRC,
> in the current notmuch message rendering pipeline, mm overrides this
> variable with something computed from gnus-blocked-images.  That said,
> I'm not sure why gnus-blocked-images isn't *already* taking care of
> this, but that's probably the place to start digging.
>


My particular maze of twisty configuration ends up in mm-shr, which
seems to ignore shr-blocked-images, but rather pay attention to
gnus-blocked-images and gnus-inhibit-images (does this seem like a bug
to anyone else?)

At least in emacs 24.4 the default value of gnus-blocked-images is set
to a function gnus-block-private-groups, which is probably unhelpful for
us.

Customizing gnus-blocked-images to a regex does seem to have some
effect. Also, setting gnus-inhibit-images to non-nil value.

privacy problem: text/html parts pull in network resources

[Austin Clements]

Quoth Daniel Kahn Gillmor on Jan 21 at  4:36 pm:
> On Wed 2015-01-21 16:14:07 -0500, Austin Clements wrote:
> > I have a fix for this on shr buried deep in an old patch series that I
> > never got back to: id:1398105468-14317-12-git-send-email-amdragon at mit.edu
> >
> > For shr, the key is to set shr-blocked-images to ".".
> 
> I've just done this, but it doesn't seem to help.
> 
> > However, IIRC, in the current notmuch message rendering pipeline, mm
> > overrides this variable with something computed from
> > gnus-blocked-images.  That said, I'm not sure why gnus-blocked-images
> > isn't *already* taking care of this, but that's probably the place to
> > start digging.
> 
> gnus-blocked-images is set for me to the function
> gnus-block-private-groups, but i don't know what that is (the function
> is undocumented afaict).  Setting gnus-blocked-images to a regexp of "."
> seems to work for me, though.

In notmuch, mm will wind up calling (gnus-block-private-groups nil).
Unfortunately, gnus apparently considers nil to be a news group rather
than a "private group" (gnus speak for email, I think), so
gnus-block-private-groups returns nil (meaning *don't* block images)
rather than ".".

Probably notmuch should override the gnus-blocked-images variable,
since the default value is simply wrong for notmuch.  Maybe something
along the lines of the following should go around our text/html
handler?

  (let ((gnus-blocked-images
 (if (eq gnus-blocked-images 'gnus-block-private-groups)
 ;; mm uses gnus-blocked-images to control image loading.
 ;; However, the default value of gnus-blocked-images
 ;; doesn't work for notmuch because
 ;; gnus-block-private-groups depends on gnus variables we
 ;; don't set.  Override it to disallow network image
 ;; loading.
 "."
   ;; Use the user's customized value.
   gnus-blocked-images)))
...)

Long live abstraction!

privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

On Wed 2015-01-21 16:14:07 -0500, Austin Clements wrote:
> I have a fix for this on shr buried deep in an old patch series that I
> never got back to: id:1398105468-14317-12-git-send-email-amdragon at mit.edu
>
> For shr, the key is to set shr-blocked-images to ".".

I've just done this, but it doesn't seem to help.

> However, IIRC, in the current notmuch message rendering pipeline, mm
> overrides this variable with something computed from
> gnus-blocked-images.  That said, I'm not sure why gnus-blocked-images
> isn't *already* taking care of this, but that's probably the place to
> start digging.

gnus-blocked-images is set for me to the function
gnus-block-private-groups, but i don't know what that is (the function
is undocumented afaict).  Setting gnus-blocked-images to a regexp of "."
seems to work for me, though.

   --dkg

privacy problem: text/html parts pull in network resources

[Austin Clements]

I have a fix for this on shr buried deep in an old patch series that I
never got back to: id:1398105468-14317-12-git-send-email-amdragon at mit.edu

For shr, the key is to set shr-blocked-images to ".".  However, IIRC,
in the current notmuch message rendering pipeline, mm overrides this
variable with something computed from gnus-blocked-images.  That said,
I'm not sure why gnus-blocked-images isn't *already* taking care of
this, but that's probably the place to start digging.

Quoth Daniel Kahn Gillmor on Jan 21 at  4:00 pm:
> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.
> 
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.
> 
> It's also a bit of a consistency/storage/indexing disaster because it
> means that what you see when you open a given message will change
> depending on the network environment you're in when you open it.
> 
> It's also potentially a security problem because it means that anyone in
> control of the remote server (or the network between you and the remote
> server if the image isn't sourced over https) can feed arbitrary data
> into whatever emacs image rendering library is being used.  (granted,
> this is not a unique problem because this can already be done by the
> original message sender with a multipart/mixed message, but it's an
> additional exposure of attack surface)
> 
> I just raised this on #notmuch, and i don't have the time or the
> knowledge to look into it now, but i think the defaults here need to be
> to avoid network access entirely unless the user explicitly requests it.
> 
>--dkg



> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

If i send a message with a text/html part (either it's only text/html,
or all parts are rendered, or it's multipart/alternative with only a
text/html subpart) and that HTML has http://example.org/test.png"/> in it, then notmuch will make a
network request for that image.

This is a privacy disaster, because it enables an e-mail sender to use
"web bugs" to tell when a given notmuch user has opened their e-mail.

It's also a bit of a consistency/storage/indexing disaster because it
means that what you see when you open a given message will change
depending on the network environment you're in when you open it.

It's also potentially a security problem because it means that anyone in
control of the remote server (or the network between you and the remote
server if the image isn't sourced over https) can feed arbitrary data
into whatever emacs image rendering library is being used.  (granted,
this is not a unique problem because this can already be done by the
original message sender with a multipart/mixed message, but it's an
additional exposure of attack surface)

I just raised this on #notmuch, and i don't have the time or the
knowledge to look into it now, but i think the defaults here need to be
to avoid network access entirely unless the user explicitly requests it.

   --dkg
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: 

Re: privacy problem: text/html parts pull in network resources

[Austin Clements]

Quoth Daniel Kahn Gillmor on Jan 21 at  4:36 pm:
> On Wed 2015-01-21 16:14:07 -0500, Austin Clements wrote:
> > I have a fix for this on shr buried deep in an old patch series that I
> > never got back to: id:1398105468-14317-12-git-send-email-amdra...@mit.edu
> >
> > For shr, the key is to set shr-blocked-images to ".".
> 
> I've just done this, but it doesn't seem to help.
> 
> > However, IIRC, in the current notmuch message rendering pipeline, mm
> > overrides this variable with something computed from
> > gnus-blocked-images.  That said, I'm not sure why gnus-blocked-images
> > isn't *already* taking care of this, but that's probably the place to
> > start digging.
> 
> gnus-blocked-images is set for me to the function
> gnus-block-private-groups, but i don't know what that is (the function
> is undocumented afaict).  Setting gnus-blocked-images to a regexp of "."
> seems to work for me, though.

In notmuch, mm will wind up calling (gnus-block-private-groups nil).
Unfortunately, gnus apparently considers nil to be a news group rather
than a "private group" (gnus speak for email, I think), so
gnus-block-private-groups returns nil (meaning *don't* block images)
rather than ".".

Probably notmuch should override the gnus-blocked-images variable,
since the default value is simply wrong for notmuch.  Maybe something
along the lines of the following should go around our text/html
handler?

  (let ((gnus-blocked-images
 (if (eq gnus-blocked-images 'gnus-block-private-groups)
 ;; mm uses gnus-blocked-images to control image loading.
 ;; However, the default value of gnus-blocked-images
 ;; doesn't work for notmuch because
 ;; gnus-block-private-groups depends on gnus variables we
 ;; don't set.  Override it to disallow network image
 ;; loading.
 "."
   ;; Use the user's customized value.
   gnus-blocked-images)))
...)

Long live abstraction!
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[David Bremner]

Austin Clements  writes:

> I have a fix for this on shr buried deep in an old patch series that I
> never got back to: id:1398105468-14317-12-git-send-email-amdra...@mit.edu
>
> For shr, the key is to set shr-blocked-images to ".".  However, IIRC,
> in the current notmuch message rendering pipeline, mm overrides this
> variable with something computed from gnus-blocked-images.  That said,
> I'm not sure why gnus-blocked-images isn't *already* taking care of
> this, but that's probably the place to start digging.
>


My particular maze of twisty configuration ends up in mm-shr, which
seems to ignore shr-blocked-images, but rather pay attention to
gnus-blocked-images and gnus-inhibit-images (does this seem like a bug
to anyone else?)

At least in emacs 24.4 the default value of gnus-blocked-images is set
to a function gnus-block-private-groups, which is probably unhelpful for
us.

Customizing gnus-blocked-images to a regex does seem to have some
effect. Also, setting gnus-inhibit-images to non-nil value.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

On Wed 2015-01-21 16:14:07 -0500, Austin Clements wrote:
> I have a fix for this on shr buried deep in an old patch series that I
> never got back to: id:1398105468-14317-12-git-send-email-amdra...@mit.edu
>
> For shr, the key is to set shr-blocked-images to ".".

I've just done this, but it doesn't seem to help.

> However, IIRC, in the current notmuch message rendering pipeline, mm
> overrides this variable with something computed from
> gnus-blocked-images.  That said, I'm not sure why gnus-blocked-images
> isn't *already* taking care of this, but that's probably the place to
> start digging.

gnus-blocked-images is set for me to the function
gnus-block-private-groups, but i don't know what that is (the function
is undocumented afaict).  Setting gnus-blocked-images to a regexp of "."
seems to work for me, though.

   --dkg
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: privacy problem: text/html parts pull in network resources

[Austin Clements]

I have a fix for this on shr buried deep in an old patch series that I
never got back to: id:1398105468-14317-12-git-send-email-amdra...@mit.edu

For shr, the key is to set shr-blocked-images to ".".  However, IIRC,
in the current notmuch message rendering pipeline, mm overrides this
variable with something computed from gnus-blocked-images.  That said,
I'm not sure why gnus-blocked-images isn't *already* taking care of
this, but that's probably the place to start digging.

Quoth Daniel Kahn Gillmor on Jan 21 at  4:00 pm:
> If i send a message with a text/html part (either it's only text/html,
> or all parts are rendered, or it's multipart/alternative with only a
> text/html subpart) and that HTML has  src="http://example.org/test.png"/> in it, then notmuch will make a
> network request for that image.
> 
> This is a privacy disaster, because it enables an e-mail sender to use
> "web bugs" to tell when a given notmuch user has opened their e-mail.
> 
> It's also a bit of a consistency/storage/indexing disaster because it
> means that what you see when you open a given message will change
> depending on the network environment you're in when you open it.
> 
> It's also potentially a security problem because it means that anyone in
> control of the remote server (or the network between you and the remote
> server if the image isn't sourced over https) can feed arbitrary data
> into whatever emacs image rendering library is being used.  (granted,
> this is not a unique problem because this can already be done by the
> original message sender with a multipart/mixed message, but it's an
> additional exposure of attack surface)
> 
> I just raised this on #notmuch, and i don't have the time or the
> knowledge to look into it now, but i think the defaults here need to be
> to avoid network access entirely unless the user explicitly requests it.
> 
>--dkg



> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

privacy problem: text/html parts pull in network resources

[Daniel Kahn Gillmor]

If i send a message with a text/html part (either it's only text/html,
or all parts are rendered, or it's multipart/alternative with only a
text/html subpart) and that HTML has http://example.org/test.png"/> in it, then notmuch will make a
network request for that image.

This is a privacy disaster, because it enables an e-mail sender to use
"web bugs" to tell when a given notmuch user has opened their e-mail.

It's also a bit of a consistency/storage/indexing disaster because it
means that what you see when you open a given message will change
depending on the network environment you're in when you open it.

It's also potentially a security problem because it means that anyone in
control of the remote server (or the network between you and the remote
server if the image isn't sourced over https) can feed arbitrary data
into whatever emacs image rendering library is being used.  (granted,
this is not a unique problem because this can already be done by the
original message sender with a multipart/mixed message, but it's an
additional exposure of attack surface)

I just raised this on #notmuch, and i don't have the time or the
knowledge to look into it now, but i think the defaults here need to be
to avoid network access entirely unless the user explicitly requests it.

   --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch