Closed Bug 456481 Opened 11 years ago Closed Last year

RSS display-content mode usability impaired by lack of JS support (for feed article summary)


(Thunderbird :: General, defect, major)

Windows XP
Not set


(Not tracked)



(Reporter: JoeS1, Unassigned)




(2 files)

Any feed that relies on javascript to call content is now broken.

Given that today's world revolves around media content, I doubt if new users would limit their feed usage to feeds that have no swf content.

All Youtube feeds (for one) require JS to initiate content rendering.
Marking "major" due to the popularity of such content.
Besides the "Bob & Carol & Ted & Alice" scenario (Wiretap)
I'd like to name another movie title: "What about Bob"

Bob likes to use RSS feeds to view his "opt-in" RSS content.
And many new users of TB would say that feeds in TB just don't work.
For instance: for simple images.

Does bug 458883 constitute due diligence against the specially crafted, and malicious RSS feed that wants to know where my profile is located on my HD.

If so, can we move forward on making feeds actually work for common usage.
Depends on: 453928
Flags: wanted-thunderbird3?
No, no change to what properties we have CAPS check for will affect the fact that quickstubs mean CAPS may not get called at all.
Worth keeping in mind is that there are two feed reading modes in Thunderbird, one that displays the feed itself, and one that displays the page that the feed claims to represent.  The user selects which one to use on a per-feed basis at the time of subscription (though this can be changed, non-retroactively, later).  The default mode is currently "display the linked-to content".  My understanding is that most feed readers do not have such a mode at all.  I think we do want to keep such a mode; it's especially useful for webforums in my estimation.  I'm unsure whether it's the correct default mode, however.

Given that feeds themselves generally don't contain JavaScript, it's only the "display linked-to content" mode that currently appears broken.
Summary: RSS feeds usability severely limited → RSS display-content mode usability impaired by lack of JS support
Loading content isn't quite unheard of (RSS Bandit will do it, but only for feeds with *no* description, not for ones where it suspects the description is lame), though making it possible to open the web page in a separate browser tab within the feed reader app is vastly more common.

The problem is we're uniquely positioned to be screwed: a typical client app doesn't have to worry about privilege escalation, because it isn't implemented in JS (though they still have to worry about local zone issues and leakage in combined views, so many still do disable all script and plugins), and even if they did have to worry about privilege escalation, they would have vastly less to lose than we do, while an online reader has to prevent all script but can just open web pages in the browser, because hey, it's the same program. Then there's the email integration: I suppose it's possible that there's a feed reader somewhere that does both "load this web page" and "email this web page" but if there is, they certainly aren't going to feel responsible for any wiretap, while we're responsible from end to end.
email#feeds#newsgroups. So why should we attempt to apply common rules.
Though you can't control the content of your inbox, the user specifically subscribes to feeds and news.

How difficult would it be to break out a separate pref for JS in feeds and news.

Hidden would be fine, those that want it would find it.
Just a comment from an end user: I agree that this makes news feeds less useful than they could be. I subscribe to several feeds that include content that I cannot see and unless they specifically mention in the text that there is content, then I don't know I am missing it unless I click on the link to open it in a separate window.

If you could get this working, it would be great. I love the news feed feature in Thunderbird; it has really lessened the time I need to spend using my browser to get info about my interests. I just process it all as incoming mail. :-)
Didn't we change this, and feeds can now use JavaScript?
I am using 3.0b3 and video content in my feeds still doesn't show up.
(In reply to comment #7)
> Didn't we change this, and feeds can now use JavaScript?

For the feed:
I get the noscript message.(although most of the content displays after that)

See also bug 504965
Ah yes it's only enabled when showing it in the web page mode.
Flags: wanted-thunderbird3? → wanted-thunderbird3-
(In reply to comment #10)
> Ah yes it's only enabled when showing it in the web page mode.

Seems like sometimes yes, and sometimes no.
Viewing in web page mode shows the noscript alert.
(In reply to comment #11)
> (In reply to comment #10)
> > Ah yes it's only enabled when showing it in the web page mode.
> Seems like sometimes yes, and sometimes no.
> Viewing in web page mode shows the
> noscript alert.

I've just looked at that feed, the docshell for the rss web page is flagged as being allowed to load javascript but for some reason that isn't happening. However from bug 504965 it looks like we can load javascript in some instances at least.

So can I suggest we morph this bug into a 'javascript doesn't always work on web pages viewed in rss feeds' bug? Or is there something else this is trying to cover as well (if so, can we clarify that and file a new bug for the web page issue).
We could morph it, I suppose, though as soon as bug 504965 gets fixed, we'll have to morph it back.
(In reply to Joe Sabash from comment #11)
> (In reply to comment #10)
> > Ah yes it's only enabled when showing it in the web page mode.
> Seems like sometimes yes, and sometimes no.
> Viewing in web page mode shows
> the noscript alert.

The noscript problem in web page mode is due to a slipup in how content policy sets js allowed.  There is a fix in bug 662907 pending tests.
JS runs in http content in messagepane, which feed web pages are.
This patch allows for running javacript in feed summary messages in messagepane.  IMO the feed reader is enormously degraded without this functionality.  Embedded scribd documents will finally work, for one.

The policy is: if a mailbox:// message 
1) is in a server.type=rss account subfolder OR
2) has the nsMsgMessageFlags::FeedMsg set (enabled since Tb15) AND
3) the pref allow_javascript_feeds pref is true (false by default)

then js is allowed. It may be nice to add a button (only visible if it's a feed message) or UI for this as well.

This policy only affects messagepane content and there continues to be no wiretapping in compose mode when forwarding a feed message.
Flags: needinfo?(mbanner)
Assignee: nobody → alta88
What's the use cases for allowing javascript in the summaries? Do other web browsers/RSS clients allow it?
Flags: needinfo?(mbanner)
Attached file FeedSummaryContent
The use case is to allow common embedded content (eg youtube video or scribd documents) to be displayed in the summary, and for parity with other standalone readers.  This is not much different than content policy to automatically allow remote images, from a pull source of the user's own selection.

I would encourage you to put the 3 messages (from a music blog, a financial blog, and a...'competitor') in the attached mbox into a folder in a feed account and compare usability before and after the patch.

Regarding browser/cloud based readers: as you know, Firefox UX specifically removed the enable/disable JS UI in order to prevent even accidental breaking of web content.  Making sure the web worked was viewed as more important than user preference or security; that's a pretty strong policy statement.

As for standalone readers, the actively maintained ones (a diminishing species) support embedded content.  Liferea is best in class for rich content; RSSOwl does some things, as examples.  Evolution has a plugin that purports to enable Java, JavaScript, and Cookies for feeds but this seems buggy/unsupported.  Live Mail doesn't do anything other than images.  Regardless, non functionality in other software isn't something Tb should use as a benchmark.

The feedback requested is this:
1. Will enabling embedded content in feed summaries be blocked or supported?
2. Is the attached patch a reasonable way to accomplish enabling display of embedded content for feeds?

Finally, I would add that Tb is not just an email client; that ship sailed long ago with the inclusion of nntp, then feeds, and recently chat.  Each of those deserve to be first class products otherwise what's the point of hauling around code that is a degraded product?
Attachment #8373459 - Flags: feedback?(mconley)
Attachment #8373459 - Flags: feedback?(mbanner)
Attachment #8373459 - Flags: feedback?(ludovic)
Attachment #8373459 - Flags: feedback?(Pidgeot18)
Comment on attachment 8373459 [details]

Speaking as someone who will refuse to review a patch touching content security policies:

I agree, in principle, that RSS need not require the same strict measures that mail has. That said, I feel that is more important that there be no way for a mail message to escape the mail sandboxing. Balancing these two requirements may ultimately require sending RSS feed summaries down different code paths than mail at levels beyond just content policy.

Another thing to keep in mind is that the Mozilla brand is in part built upon stronger privacy commitments than most of our competitors. Enabling something that can trigger external resource loads based on attacker-controlled logic (and thus communicate data) is to me unacceptable without sufficient measures in place to prevent the communication of sensitive data (a category which includes base URLs of messages at present).
Attachment #8373459 - Flags: feedback?(Pidgeot18)
Comment on attachment 8373459 [details]

I think I'm in vague alignment with Joshua. My specific concerns would be:

- The general notion of displaying as a summary, or simple view, is perceived by a lot of folks as a "safe" way of displaying items within Thunderbird. The more complex displays are for the full functionality that the sender intended.

- It is unclear from the rss spec if the description is really meant to be a rich field, it seems html is allowed, but it is unclear about anything else.

- The security implications would warrant further thinking and investigation, especially with how this relates to other messages, and I think I'd want a security review at a minimum.

The first item is really the biggest issue for me. Whilst I can understand the desire to allow as much as possible, I think there's a pre-existing expectation here from the user.
Attachment #8373459 - Flags: feedback?(standard8) → feedback-
Attachment #8373459 - Flags: feedback?(ludovic)
Comment on attachment 8373459 [details]

I don't think I have anything useful to add to Standard8 or jcranmer's feedback.
Attachment #8373459 - Flags: feedback?(mconley)
Assignee: alta88 → nobody
We've recently had security bugs where this subject may have been discussed.  Do they put this bug in a new light, and is this bug perhaps a duplicate?
Flags: needinfo?(mkmelin+mozilla)
I don't think it's a duplicate, but I wouldn't enable JavaScript in the summary content. It would be a stepping stone to doing bad things with other mailbox:// content.
Closed: Last year
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WONTFIX
Summary: RSS display-content mode usability impaired by lack of JS support → RSS display-content mode usability impaired by lack of JS support (for feed article summary)
You need to log in before you can comment on or make changes to this bug.