262611 - Loads remote images into RSS messages when "Block remote images" option is on

Status: RESOLVED DUPLICATE of bug 245361

(MailNews Core :: Feed Reader, defect)

Description

[Chris Beck]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

In the Privacy section of my Options, I have selected "Block loading of remote
images in mail messages".  The only way to get hyperlinks in RSS entries is to
choose "View" | "Message Body As" | "Original HTML".  This view also loads
remote images.

Reproducible: Always
Steps to Reproduce:
1. Add http://slashdot.org/index.rss as an RSS feed
2. Select the "Block loading of remote images in mail messages" Privacy option 
3. Select "View" | "Message Body As" | "Original HTML"
4. Read a Slashdot entry

Actual Results:  
Lots of images (including ads) are loaded.

Expected Results:  
No remote images should be loaded.

Comment 1

[Ivan Ičin]

I encounter similar bug, but I don't know whether it is separate bug. Do you see
this behaviour in normal e-mail messages?

Comment 2

[Chris Beck]

Nope, with normal emails everything is fine

Comment 3

[Mike Cowperthwaite]

This is because the web page is loaded within an <iframe> in the RSS msg.  
Blocking only applies to the actual text of the message, not the text of the 
content being loaded indirectly.  By definition, you're going to see the images 
on the web page.

Comment 4

[Mike Cowperthwaite]

(In reply to comment #3)
> This is because the web page is loaded within an <iframe> in the RSS msg.  
> Blocking only applies to the actual text of the message, not the text of the 
> content being loaded indirectly.  By definition, you're going to see the
> images on the web page.

I was mistaken about this.  Images shown within an <iframe> do get blocked, but 
there is deliberate code in the blocking routine to make an exception for the 
RSS feed.  A comment in nsMsgContentPolicy::ShouldLoad() reads: 
"special case RSS urls, always allow them to load remote images since the user 
explicitly subscribed to the feed."  [nsMsgContentPolicy.cpp]

Therefore, marking this bug Invalid.

Note that in current nightlies, an <iframe> with a 'src' attribute pointing to 
an external entity will also be blocked, apparently due to the patch checked in 
for bug 28327; however, RSS is still unaffected by this.

Comment 5

[Chris Beck]

Umm, just because I subscribed to the RSS feed doesn't mean I want the images
too.  I can subscribe to a mailing list but refuse those images.  I don't see
the logic at all.

Comment 6

[Kenneth Qvarfordt]

(In reply to comment #5)
> Umm, just because I subscribed to the RSS feed doesn't mean I want the images
> too.  I can subscribe to a mailing list but refuse those images.  I don't see
> the logic at all.

I agree with you on this. I fail to see the logic here as well.
Blocking images should be up the user.

Comment 7

[true.wizmaster]

(In reply to comment #5)
> Umm, just because I subscribed to the RSS feed doesn't mean I want the images
> too.  I can subscribe to a mailing list but refuse those images.  I don't see
> the logic at all.

I agree too. RSS feeds should honor the "Block loading of remote images"
setting. Maybe with a list of restriction akin to the "Allow remote images if
..." setting too.

Comment 8

[Rich Heimlich]

(In reply to comment #5)
> Umm, just because I subscribed to the RSS feed doesn't mean I want the images
> too.  I can subscribe to a mailing list but refuse those images.  I don't see
> the logic at all.

Add me to the list. I really assumed TB just called a Firefox module to render
the web pages in TB and thus, it would end up using the same code. I was shocked
to find unwanted ads in the RSS feature, which I just started using, and LOVE.
They're so much better here than in Firefox except that I have more control in
Firefox. 

Mike, your comment makes no sense. Users explicitly add bookmarks for URL's they
like that have all sorts of ads removed by Adblock. How is this any different? I
want the RSS feed. I do not want the ads.

Furthermore, so far, no one has posted the viewpoint of wanted to retain those
images. 

If you're concerned about it, how about a simple toggle controlled in the
Options to either allow it to work or not allow it to work. Then all can be happy.

Comment 9

[Jamie]

(In reply to comment #5)
> Umm, just because I subscribed to the RSS feed doesn't mean I want the images
> too.  I can subscribe to a mailing list but refuse those images.  I don't see
> the logic at all.

I agree wholeheartedly.. just because it says the following:

"special case RSS urls, always allow them to load remote images since the user 
explicitly subscribed to the feed."  [nsMsgContentPolicy.cpp]

I'm also subscribed to the slashdot rss feed, and you know what? I don't want to
see the ads either. If I'm viewing an RSS or regular email <HTML> markup in a
message it doesn't matter, I want control to block remote images if I want! 

This seems to parallel the feature in Thunderbird whereby you can check to
"Allow remote images if the sender is in my: Addressbook", and I'm guessing that
whoever coded it reasoned that if you add a subscription to an RSS url then you
want everything (images, etc) that comes with it.  

I don't think that this is a fair assumption to make.. you should leave it up to
the user. 

Can you re-open this bug please or if there is a duplicate that will resolve
this 'feature' post the bug link?  

Many thanks,
Jamie

Comment 10

[Jesse Ruderman]

See also bug 296258.

Comment 11

[John Navas]

*** Bug 296258 has been marked as a duplicate of this bug. ***

Comment 12

[John Navas]

Please reconsider and reopen this bug. This is a significant issue.

Comment 13

[Jesse Ruderman]

I reopened bug 296258 as a request for a separate pref, leaving this bug as a
request to change the default.

Comment 14

[Chris Beck]

*** This bug has been confirmed by popular vote. ***

Comment 15

[Chris Beck]

I am not quite sure what comment #14 means:
*** This bug has been confirmed by popular vote. ***

I did not create that comment, and the status of the bug has not changed from RESOLVED/WONTFIX.

Does anyone know when votes are tallied and how many votes are needed on an issue before someone actually pays attention?

Comment 16

[Chris Beck]

Does anyone know how many votes it takes to get a bug re-opened?

Comment 17

[Chris Beck]

It seems to me that since bug 245361
https://bugzilla.mozilla.org/show_bug.cgi?id=245361
 isn't marked as "won't fix" and has 43 votes for it I'll just re-opne this and mark it as a dupe.

Comment 18

[Chris Beck]

*** This bug has been marked as a duplicate of 245361 ***