1131474 - Following HTML links on RSS preview should't sends feed URL as referer

Status: RESOLVED WONTFIX

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Christian Loos]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150125221831

Steps to reproduce:

When previewing a RSS feed in Firefox (tested with 35.0.1) and the RSS items 
contains HTML links, following this links results in Firefox sending the RSS 
feed URL as referer header to the link destination.

Normally this isn't a problem.
But some private RSS feeds contains auth tokens in their URL to authenticate a 
user to a private RSS feed service.
In this case the referer header contains also the auth token, which is send to 
the link destination and can be inspected in the webserver access logs.

This is some kind of sensitive information disclosure. 
Something similar was discovered at Dropbox in May 2014 [1].

To solve this problem Firefox should send an empty referer header for links 
on the RSS preview page.


I found this while working with the Request Tracker (RT) ticket system from 
Bestpractical [2]. A user can create a RSS feed URL from a ticket search which 
includes a auth token [3].
I informed the RT developers and they have assigned CVE-2015-1165 to this.
They will remove HTML links from the RSS feeds to not disclose the auth token 
when users following links on the RSS preview in Firefox and currently plan to 
release this on February 26th. If you want to get in contact with the RT 
developers use [e-mail] and [e-mail].


Chris

[1] https://blogs.dropbox.com/dropbox/2014/05/web-vulnerability-affecting-shared-links/
[2] https://bestpractical.com/rt/
[3] https://bestpractical.com/docs/rt/latest/reporting/feeds.html#Secret-Tokens

Comment 1

[:Gijs (he/him)]

Attachment: use noreferrer for links in feedwriter,

Comment 2

[:Gijs (he/him)]

(In reply to Christian Loos from comment #0)
> When previewing a RSS feed in Firefox (tested with 35.0.1) and the RSS items 
> contains HTML links, following this links results in Firefox sending the RSS 
> feed URL as referer header to the link destination.

Just to be clear... do you mean the links to items listed in the feed, or you mean that the entry descriptions contain HTML which is rendered and which contains links? An example feed would be helpful. (You could save it and attach it with a new filename to avoid leaking those auth tokens)

The patch I just added addresses the former issue, which you can see with e.g. http://feeds.bbci.co.uk/news/rss.xml .

For actual <a> elements embedded in the RSS feed, I would have thought the feed provider could just set rel="noreferrer" on them to avoid the browser that uses the HTML sending the referrer? Is there some reason that is not practical / not enough here? (I'm not 100% clear on how BestPractical obtains the content of the feeds, and what that content is, and so on)

Comment 3

[Christian Loos]

(In reply to :Gijs Kruitbosch from comment #2)
> Just to be clear... do you mean the links to items listed in the feed, or
> you mean that the entry descriptions contain HTML which is rendered and
> which contains links? An example feed would be helpful. (You could save it
> and attach it with a new filename to avoid leaking those auth tokens)

I actually mean both, the item link and description element.

Here is a link from their demo site:
https://demo.bestpractical.com/NoAuth/rss/guest/3094be6c913aa85d/?Order=ASC|ASC|ASC|ASC&OrderBy=id|||&Query=id+%3D+164

> For actual <a> elements embedded in the RSS feed, I would have thought the
> feed provider could just set rel="noreferrer" on them to avoid the browser
> that uses the HTML sending the referrer? Is there some reason that is not
> practical / not enough here? (I'm not 100% clear on how BestPractical
> obtains the content of the feeds, and what that content is, and so on)

The item description content is actually user input (the ticket create message, text/plain or text/html). Adding a rel="noreferrer" to all <a> tags would mean rewriting the user input, which I think isn't a good idea here.

I'm not sure if it is possible for Firefox to not send a referer header for links followed from the RSS preview page without rewriting the item description content.

Comment 4

[Daniel Veditz [:dveditz]]

Gijs: the <meta referrer> feature (bug 704320) has landed in Firefox 36 so you could add

   <meta name="referrer" content="no-referrer">  (or content="origin")

to the top of the document and save having to rewrite all the content links. (note correct spelling of referrer, don't use the misspelled http header "Referer"). Also note that spec went with a hyphen in no-referrer rather than matching the hyphen-less rel=noreferrer from the other spec :-(

Personally I'd prefer content="origin" to preserve at least a little bit of link source tracking, but no-referrer does what you've tried to do with your patch so you might prefer it.

Firefox's built-in feed reader can't be the only web-based feed reader (at least there used to be others). This was a rather unfortunate design choice on the part of Bestpractical and hard to consider a Firefox security bug. Still, helps user privacy to fix it.

Comment 5

[:Gijs (he/him)]

Attachment: Use <meta name="referrer">

Nice! Done, works a charm.

Comment 6

[Matthew N. [:MattN]]

Comment on attachment 8562261 [details] [diff] [review]
Use <meta name="referrer">

Review of attachment 8562261 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/feeds/content/subscribe.xhtml
@@ +32,5 @@
>            type="text/css"
>            media="all"/>
>      <script type="application/javascript"
>              src="chrome://browser/content/feeds/subscribe.js"/>
> +    <meta name="referrer" content="origin"/>

content="origin-when-crossorigin" seems less likely to cause problems and preserves more data for referral tracking but that assumes that we treat this page as the origin of the feed URI which doesn't seem to be the case unfortunately. As a web developer, I'm not a fan of the information loss when linking to my own origin. This is going to lead to uglier URLs as sites add extra query parameters or use intermediate redirects to identify which feed was the referrer. These things break visited link colouring and can slow down the navigation. I would prefer to make a origin-when-crossorigin policy work here or WONTFIX.

Comment 7

[:Gijs (he/him)]

(In reply to Matthew N. [:MattN] from comment #6)
> Comment on attachment 8562261 [details] [diff] [review]
> Use <meta name="referrer">
> 
> Review of attachment 8562261 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/components/feeds/content/subscribe.xhtml
> @@ +32,5 @@
> >            type="text/css"
> >            media="all"/>
> >      <script type="application/javascript"
> >              src="chrome://browser/content/feeds/subscribe.js"/>
> > +    <meta name="referrer" content="origin"/>
> 
> content="origin-when-crossorigin" seems less likely to cause problems and
> preserves more data for referral tracking but that assumes that we treat
> this page as the origin of the feed URI which doesn't seem to be the case
> unfortunately. As a web developer, I'm not a fan of the information loss
> when linking to my own origin. This is going to lead to uglier URLs as sites
> add extra query parameters or use intermediate redirects to identify which
> feed was the referrer.

You're assuming that pages don't already do this (the BBC, for instance, has query bits in the URLs in links in feeds that note the source was a feed - the top one right now being, for instance, http://www.bbc.co.uk/news/world-middle-east-31375445#sa-ns_mchannel=rss&amp;ns_source=PublicRSS20-sa ).

You're also assuming that they currently get vastly useful information through these referrer logs. The latter seems like it'd only happen for Firefox in-browser-displayed feeds - desktop/mobile feed readers and web feed readers likely provide no or completely different referrer URIs, rather than working hard to pass the 'real' referrer.

While I think privacy is important, I don't think fixing the document origin (which is likely what's at issue here) is in-scope / proportionate for fixing this bug - we'd likely have to rearchitecture quite a bit in order to get the menus at the top of the page ("what to do with this feed") to work while ensuring the page has the "correct" origin principal etc.

Can I ask for you to reconsider clearing review? :-)

Comment 8

[Matthew N. [:MattN]]

Note that bug 1113431 affects manually testing this change.

(In reply to :Gijs Kruitbosch from comment #7)
> You're assuming that pages don't already do this (the BBC, for instance, has
> query bits in the URLs in links in feeds that note the source was a feed -
> the top one right now being, for instance,
> http://www.bbc.co.uk/news/world-middle-east-31375445#sa-ns_mchannel=rss&
> ns_source=PublicRSS20-sa ).

I'm not assuming that page don't (I said uglier i.e. more sites will do this) as I know some already do.

> You're also assuming that they currently get vastly useful information
> through these referrer logs. The latter seems like it'd only happen for
> Firefox in-browser-displayed feeds - desktop/mobile feed readers and web
> feed readers likely provide no or completely different referrer URIs, rather
> than working hard to pass the 'real' referrer.

Many web-based feed readers provide statistics for publishers on their own dashboards and/or through the user-agent string (containing the subscriber count).

> While I think privacy is important, I don't think fixing the document origin
> (which is likely what's at issue here) is in-scope / proportionate for
> fixing this bug - we'd likely have to rearchitecture quite a bit in order to
> get the menus at the top of the page ("what to do with this feed") to work
> while ensuring the page has the "correct" origin principal etc.

It's debatable whether this is a Firefox security bug in the first place so if it's too hard to fix then that pushes me more toward the WONTFIX option. See the last paragraph of comment 4.

> Can I ask for you to reconsider clearing review? :-)

You haven't provided any new information to me and I disagree with the dataloss proposed so you'll have to find another reviewer if you want to proceed.

Comment 9

[:Gijs (he/him)]

(In reply to Matthew N. [:MattN] from comment #8)
> > You're also assuming that they currently get vastly useful information
> > through these referrer logs. The latter seems like it'd only happen for
> > Firefox in-browser-displayed feeds - desktop/mobile feed readers and web
> > feed readers likely provide no or completely different referrer URIs, rather
> > than working hard to pass the 'real' referrer.
> 
> Many web-based feed readers provide statistics for publishers on their own
> dashboards and/or through the user-agent string (containing the subscriber
> count).

Actually, my point was that if you clicked links to external sites in a web-based feed reader, the referrer URI would refer to the web-based feedreader. That still wouldn't tell sites what feed the clickthrough came from, just like reading the actual content in the reader wouldn't. Ditto for desktop/mobile readers.

Your argument seems to be "dataloss" on the side of the publisher, whereas I'm basically saying that non-Firefox feedreaders will mostly never have provided this data to begin with, and so ceasing to do so in Firefox doesn't seem like it will materially impact publishers, or their statistics. Publishers including origin feed info explicitly in the URIs contained in their feeds corroborates the view that the referrer header is already not actually useful for analytics purposes.

It's not clear to me why you think Firefox's current behaviour is of such paramount important for publisher statistics/data. Can you elaborate on this, given the above? Are there well-known analysis suites for feed usage that are reliant on this data, for example?

Comment 10

[Matthew N. [:MattN]]

(In reply to :Gijs Kruitbosch from comment #9)
> (In reply to Matthew N. [:MattN] from comment #8)
> > > You're also assuming that they currently get vastly useful information
> > > through these referrer logs. The latter seems like it'd only happen for
> > > Firefox in-browser-displayed feeds - desktop/mobile feed readers and web
> > > feed readers likely provide no or completely different referrer URIs, rather
> > > than working hard to pass the 'real' referrer.
> > 
> > Many web-based feed readers provide statistics for publishers on their own
> > dashboards and/or through the user-agent string (containing the subscriber
> > count).
> 
> Actually, my point was that if you clicked links to external sites in a
> web-based feed reader, the referrer URI would refer to the web-based
> feedreader. That still wouldn't tell sites what feed the clickthrough came
> from, just like reading the actual content in the reader wouldn't. Ditto for
> desktop/mobile readers.

I understood what you were saying and my reply was that there was still often a way to get the data about usage of the feed and possibly referrals from it (if the web-based reader was tracking it). With the change in question, the data is lost for clicks via Firefox (without changing the feed contents).

> Your argument seems to be "dataloss" on the side of the publisher, whereas
> I'm basically saying that non-Firefox feedreaders will mostly never have
> provided this data to begin with, and so ceasing to do so in Firefox doesn't
> seem like it will materially impact publishers, or their statistics.
> Publishers including origin feed info explicitly in the URIs contained in
> their feeds corroborates the view that the referrer header is already not
> actually useful for analytics purposes.

Non-Firefox feed readers have provided this information but not in the same form (referrer header). This is either through public information in their UI (e.g. the number of subscribers) or though a dashboard you can login to if you prove you own the domain.

> It's not clear to me why you think Firefox's current behaviour is of such
> paramount important for publisher statistics/data. Can you elaborate on
> this, given the above? Are there well-known analysis suites for feed usage
> that are reliant on this data, for example?

As a whole of the subscriber base of feeds, I suspect usage from the feed view is probably low (Live Bookmarks provide a better UX for someone who actually want to subscribe IMO) but I don't think that necessarily means we should stop sending what we currently do. The data isn't just useful for statistics; it's also useful to identify the cause of broken links, for example. After this change I may end up searching all over my homepage trying to find where I made a broken link (since the origin URL can't be distinguished from a visit from my homepage) when in-fact the broken link was in one of my feeds.

I know web developers look through server logs to identify the causes of errors and there are many web analytics tools that use the server logs (with referrer information) to show where traffic is coming from. There aren't necessarily feed-specific but I'm sure some let you look at referrals based on the landing page. Webalizer is a very common analytics report that shows referral traffic and it's installed on most of the shared hosting services I've used.

I wish there was an option to send just the origin + path and the site could put the token in the query params…

Also:
"Note: The Origin Only policy causes the origin of HTTPS referrers to be sent over the network as part of unencrypted HTTP requests." so this causes us to send the origin for downgrades now. deveditz, is that fine with you?

Comment 11

[:Gijs (he/him)]

Matt and I also discussed this out-of-band.

It seems to me like:

1) the effort required to get origin-when-crossorigin to work might be non-trivial. Matt says the page is explicitly null-principalled, but we're not sure why that is (rather than the feed's principal). dveditz, do you know why? :-)

2) this isn't a critical security issue on Firefox's side, but rather a privacy issue if the feed is either provided over http (I'm hoping it's not...), or the links are to third-party https sites (https->http referrers won't be sent by default)
3) the website provides custom feeds, and therefore can (and arguably should) fix this by either providing interstitial pages to mask the referrer, and/or marking the in-content links as rel="noreferrer". AIUI the links from the search page on bestpractical's site will be same-origin for the entries in the feed (as they'll be bestpractical tickets), only the contents will be
4) Matt noticed that using "origin" here will start sending the https origin to http sites (!) which it won't do currently.
5) there are other downsides to blocking referrers for non-thirdparty pages relating to analytics/deeplinking/source-sharing/debugging, which are worsened if we use noreferrer rather than origin or origin-when-crossorigin (in order to deal with (4)).

Ultimately, it also seems to me that it's a security issue in bestpractical's site that they put the actual auth tokens (!) rather than a derivative/separate hash in the URL for the feed. That is, the fact that those tokens, according to https://bestpractical.com/docs/rt/latest/reporting/feeds.html#Secret-Tokens, are enough to authenticate you to the *entire* service ("they can see tickets as your user"), is a bug. Generally, tickets such as these (e.g. identifiers for trips stored on sites like kayak.com that you can share with others, or the dropbox vulnerability in comment #0, or shared google calendar links, or...) are only enough to get you access to that specific item. That's not nice, but not as terrible as giving full access to the user account by reusing the same token across all RSS-based accesses to the system.

Putting together all of the above, I'm not sure what approach makes the most sense here...

Comment 12

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #11)
> 3) the website provides custom feeds, and therefore can (and arguably
> should) fix this by either providing interstitial pages to mask the
> referrer, and/or marking the in-content links as rel="noreferrer". AIUI the
> links from the search page on bestpractical's site will be same-origin for
> the entries in the feed (as they'll be bestpractical tickets), only the
> contents will be

... third-party origin (as they'll be ticket content).

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to Matthew N. [:MattN] from comment #10)
> I wish there was an option to send just the origin + path and the site could
> put the token in the query params…

Sites that put sensitive stuff in URLs manage to get it into every part of the URL. If we're not going to simply blame this on stupid sites and try to address it then we wouldn't want to include path.

> "Note: The Origin Only policy causes the origin of HTTPS referrers to be
> sent over the network as part of unencrypted HTTP requests." so this causes
> us to send the origin for downgrades now. deveditz, is that fine with you?

I'm not too worried about it. I'd also be OK with a referrer policy of None because an actual feed reading app (native or web) will process feeds and not use the raw feed as the document so the referrer isn't going to be all that useful.

Comment 14

[Christian Loos]

A quick Google search for "RSS token" shows that it is quite common to use
a URL auth token for private RSS Feeds (Github, Mediawiki, Moodle).
So it is not only Bestpractical, who is affected by this problem.

Adding the referrer meta tag or the rel attribut to all <a> tags on the client
side would result in lost of informations, as mentioned in the previous comments.

Just to make this clear, the problem just exists on the RSS preview page.
From the client side it is not possible to stop Firefox from sending the
referer from the RSS preview page but send the referer from the actual RSS feed.
So this information disclosure can only be fixed in Firefox.

Comment 15

[:Gijs (he/him)]

(In reply to Christian Loos from comment #14)
> A quick Google search for "RSS token" shows that it is quite common to use
> a URL auth token for private RSS Feeds (Github, Mediawiki, Moodle).
> So it is not only Bestpractical, who is affected by this problem.

Where does github/mediawiki have "private" RSS feeds? Do they actually have this issue, ie don't they themselves specify rel="noreferrer" for external links in the RSS feed content, with the items themselves being same-origin with the feed (ie other github/mediawiki items) ?

And my point was, there is a difference in severity of the disclosure issue between this token being valid for a single feed or for the entire site (where the latter is the implication for bestpractical).

> Adding the referrer meta tag or the rel attribut to all <a> tags on the
> client
> side would result in lost of informations, as mentioned in the previous
> comments.

You can't have it both ways, though - sending the referrer because you want the information, and not sending the referrer because the information you want is private. What are you trying to argue here? And is bestpractical the "client" in this paragraph, or Firefox?

> Just to make this clear, the problem just exists on the RSS preview page.
> From the client side it is not possible to stop Firefox from sending the
> referer from the RSS preview page but send the referer from the actual RSS
> feed.

I don't understand what this last paragraph tries to say. Who is the "client" here? And what differentiation do you want? ("stop sending ... but send" -- where exactly do you want / not want a referrer sent?)

I'm unassigning myself because at this point it is very unclear to me what the ideal solution would be, how close we can reasonably get (Firefox isn't psychic and can't tell if a referrer URI contains private information or not), and whether it's worth spending time on considering other things that need getting done this week and the next.

Comment 16

[Christian Loos]

(In reply to :Gijs Kruitbosch from comment #15)
> Where does github/mediawiki have "private" RSS feeds? Do they actually have
> this issue, ie don't they themselves specify rel="noreferrer" for external
> links in the RSS feed content, with the items themselves being same-origin
> with the feed (ie other github/mediawiki items) ?
If you are logged in to Github you will find a "Subscribe to your news feed" link.
This link contains an auth token.
Attached a snippet from my News Feed which luckily contains a link to 
http://forum.fhem.de/index.php/topic,30128.msg261174.html#msg261174
You will see that even Github doesn't provide an rel="noreferrer" attribute.
(while in this example the HTTPS referrer wouldn't be send because the link href 
is HTTP, I assume that the guys from Github don't add a rel="noreferrer" attribute
to <a> tags if the target is HTTPS).

> And my point was, there is a difference in severity of the disclosure issue
> between this token being valid for a single feed or for the entire site
> (where the latter is the implication for bestpractical).
What this discloses depends on the site.
For Github it discloses part of the commit messages of the subscribed repositories
(which may also contain sensitive information as Github also support private 
repositories beside their public repositories).
For Bestpractical's Request Tracker it discloses the ticket create message
(just wan't to note that here the token is also only valid for the rss feed).

> You can't have it both ways, though - sending the referrer because you want
> the information, and not sending the referrer because the information you
> want is private. What are you trying to argue here? And is bestpractical the
> "client" in this paragraph, or Firefox?
If I open a rss feed in Firefox (the rss preview page) and follow a link, 
I don't want Firefox to send the referrer (the rss feed URL) as this maybe contains
sensitive information (an auth token).
If I open the the same rss feed in an web rss reader and follow a link, 
the referrer is the web rss reader URL and should be send, as this wouldn't
disclose private informations.

> I don't understand what this last paragraph tries to say. Who is the
> "client" here? And what differentiation do you want? ("stop sending ... but
> send" -- where exactly do you want / not want a referrer sent?)
As client I meant the site that provides the rss feed.

I'm not sure who should be responsible to fix this.
Is using an auth token for rss feeds so quite common that Firefox should make sure
it doesn't send a referrer for rss feed URLs?
Or is a site, who provide private rss feeds, is responsible that the rss feed 
auth tokens are not send as a referrer?

Comment 17

[Christian Loos]

Attachment: github-rss-feed-example.xml

example rss feed item from Github news feed

Comment 18

[:Gijs (he/him)]

I poked at this some more; AFAICT the reason we don't honour the origin-when-crossorigin thing is because the principal of the page is still about:feeds. Changing that of course breaks loading all the scripts for the page and so on. We could either look at using message passing for the privileged stuff, or putting in a seamless iframe for the actual feed content.

Comment 19

[Matthew N. [:MattN]]

(In reply to Christian Loos from comment #16)
> (In reply to :Gijs Kruitbosch from comment #15)
> > You can't have it both ways, though - sending the referrer because you want
> > the information, and not sending the referrer because the information you
> > want is private. What are you trying to argue here? And is bestpractical the
> > "client" in this paragraph, or Firefox?
> If I open a rss feed in Firefox (the rss preview page) and follow a link, 
> I don't want Firefox to send the referrer (the rss feed URL) as this maybe
> contains
> sensitive information (an auth token).
> If I open the the same rss feed in an web rss reader and follow a link, 
> the referrer is the web rss reader URL and should be send, as this wouldn't
> disclose private informations.

How did you come to that conclusion? Feed readers include the Feed URL in their URL too:
https://feedly.com/i/subscription/feed/http://planet.mozilla.org/atom.xml?token=SOME_SECRET_TOKEN_HERE

Comment 20

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #18)
> I poked at this some more; AFAICT the reason we don't honour the
> origin-when-crossorigin thing is because the principal of the page is still
> about:feeds. Changing that of course breaks loading all the scripts for the
> page and so on. We could either look at using message passing for the
> privileged stuff, or putting in a seamless iframe for the actual feed
> content.

bug 1109714 will help here because it takes the subscribe UI out of the page. Not sure if we're OK waiting for that, or OK taking a non-ideal solution now if we know that we can improve the situation for web authors and referral info in the near future... Matt, thoughts?

Comment 21

[Matthew N. [:MattN]]

(In reply to :Gijs Kruitbosch from comment #20)
> (In reply to :Gijs Kruitbosch from comment #18)
> > I poked at this some more; AFAICT the reason we don't honour the
> > origin-when-crossorigin thing is because the principal of the page is still
> > about:feeds. Changing that of course breaks loading all the scripts for the
> > page and so on. We could either look at using message passing for the
> > privileged stuff, or putting in a seamless iframe for the actual feed
> > content.
> 
> bug 1109714 will help here because it takes the subscribe UI out of the
> page. Not sure if we're OK waiting for that, or OK taking a non-ideal
> solution now if we know that we can improve the situation for web authors
> and referral info in the near future... Matt, thoughts?

I don't think this is a priority for us as I pointed out how this is also a problem for web-based readers in comment 19 so it seems like this should be fixed by content authors anyways. I also just replied on bug 1109714 to point out that that bug doesn't require moving the UI. We don't support seamless iframes btw (bug 631218).

Comment 22

[Daniel Veditz [:dveditz]]

Does not meet the bounty criteria.

Comment 23

[Al Billings [:abillings - ex-MoCo]]

Is this bug a "won't fix" or will we do anything here?

Comment 24

[:Gijs (he/him)]

(In reply to Al Billings [:abillings] from comment #23)
> Is this bug a "won't fix" or will we do anything here?

I think we're willing to do something here, but not willing to spend what would currently be a very large amount of effort on this to fix what is in effect an issue with the website.

Comment 25

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #24)
> (In reply to Al Billings [:abillings] from comment #23)
> > Is this bug a "won't fix" or will we do anything here?
> 
> I think we're willing to do something here, but not willing to spend what
> would currently be a very large amount of effort on this to fix what is in
> effect an issue with the website.

(ie, if we want this fixed without breaking 'legitimate' referrer info, it would be a lot of work)

Comment 26

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.