Opened 5 months ago

Last modified 4 months ago

#30732 needs_information defect

"Your Firefox is critically out of date" banner

Reported by: hellomebois Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When running an up-to-date version of Tor, I'm sometimes prompted with a banner which says:

"Your Firefox is critically out of date. An update is required to stay secure. (Button: Update Now)"

This is a piece of Firefox code that should be disabled, so users will use the Tor update flow instead of being prompted to install Firefox.

Child Tickets

Attachments (1)

screenshot.png (68.2 KB) - added by hellomebois 5 months ago.

Download all attachments as: .zip

Change History (13)

Changed 5 months ago by hellomebois

Attachment: screenshot.png added

comment:1 Changed 5 months ago by gk

Resolution: not a bug
Status: newclosed

What makes you believe this is a piece of Firefox code? I rather think that's something on the website that is alarming you (see that the notification bar is overlapping the underlying content), because it is not expecting to see a Firefox 60 anymore (which Tor Browser is based upon). While one could argue that the ESR series is less secure than the default release I think it is wrong to say it is critically out of date. Nevertheless, I think there is not much we can do unless we switch to mozilla-release. We plan to tackle that problem at least for mobile after Tor Browser 9 gets out I think.

Closing this as "not a bug" as this is strictly speaking a website issue and not a Tor Browser bug.

comment:2 Changed 5 months ago by gk

Resolution: not a bug
Status: closedreopened

So, looking at https://support.mozilla.org/en-US/kb/rate-your-firefox-experience-heartbeat this actually seems to be legit. However, it's not clear where the banner text is actually coming from. Do you have your Tor Browser modified somehow that could explain this kind of banner? Your bug report is the first one of this kind I think which makes me wonder. Do you know when these banners are showing up?

comment:3 Changed 5 months ago by gk

Status: reopenedneeds_information

comment:4 Changed 5 months ago by mcs

#28978 is probably a duplicate.
Some time after we fixed #19047, the shield add-on was converted into a bundled component (see https://bugzilla.mozilla.org/show_bug.cgi?id=1436113). Kathy and I are out of time for research today, but probably we need to set app.normandy.enabled to false. We could also clear the app.normandy.api_url pref as a "defense in depth" measure.

The questions from comment:2 are still worth seeking answers to though. Here is one more question: if you look in about:config, what is your value for toolkit.telemetry.enabled?

comment:5 Changed 5 months ago by hellomebois

the toolkit.telemetry.enabled row reads: "Status=locked, Type=boolean, Value=false"

also, I've just now updated to 8.5.1, and the banner still appears. No need for another screenshot, it's the same as the above attachment.

comment:6 in reply to:  5 Changed 5 months ago by gk

Replying to hellomebois:

the toolkit.telemetry.enabled row reads: "Status=locked, Type=boolean, Value=false"

also, I've just now updated to 8.5.1, and the banner still appears. No need for another screenshot, it's the same as the above attachment.

Thanks, could you answer the questions from comment:2 as well?

comment:7 Changed 5 months ago by hellomebois

regarding comment:2, I have the following add-ons: HTTPS Everywhere and Privacy Badger (both by EFF)

I have not made any other modifications as far as I am aware.

comment:8 Changed 5 months ago by mcs

What is the value of datareporting.healthreport.uploadEnabled ?

By default that hidden pref is set to false in Tor Browser, which disables the Shield/Normandy subsystem. See: https://gitweb.torproject.org/tor-browser.git/tree/toolkit/components/normandy/lib/RecipeRunner.jsm?h=tor-browser-60.7.0esr-8.5-1#n137

comment:9 Changed 4 months ago by hellomebois

the value for datareporting.healthreport.uploadEnabled is false

comment:10 Changed 4 months ago by steph

I also get this banner. I don't remember ever having modified anything, and I don't have any add-ons, but my value for datareporting.healthreport.uploadEnabled was true.

comment:11 in reply to:  10 ; Changed 4 months ago by gk

Cc: mcs brade added
Priority: LowMedium

Replying to steph:

I also get this banner. I don't remember ever having modified anything, and I don't have any add-ons, but my value for datareporting.healthreport.uploadEnabled was true.

Did you start to see the banner recently or is that already ongoing for a while? And does it go away if you flip the pref?

So, we set the pref to false in 000-tor-browser.js. There is only one way this get set to true (apart from changing the pref manually) which is via https://searchfox.org/mozilla-esr60/source/toolkit/components/telemetry/healthreport-prefs.js#10. Which is only included if MOZ_SERVICES_HEALTHREPORT is defined (https://searchfox.org/mozilla-esr60/source/modules/libpref/greprefs.js#6). And that seems to be the case. So, maybe we have some race-condition here in the pref system that is causing this and we should make sure MOZ_SERVICES_HEALTHREPORT is not defined in the first place? (And MOZ_TELEMETRY_REPORTING and MOZ_DATA_REPORTING and friends) mcs/brade: what do you think?

comment:12 in reply to:  11 Changed 4 months ago by mcs

Replying to gk:

So, we set the pref to false in 000-tor-browser.js. There is only one way this get set to true (apart from changing the pref manually) which is via https://searchfox.org/mozilla-esr60/source/toolkit/components/telemetry/healthreport-prefs.js#10. Which is only included if MOZ_SERVICES_HEALTHREPORT is defined (https://searchfox.org/mozilla-esr60/source/modules/libpref/greprefs.js#6). And that seems to be the case. So, maybe we have some race-condition here in the pref system that is causing this and we should make sure MOZ_SERVICES_HEALTHREPORT is not defined in the first place? (And MOZ_TELEMETRY_REPORTING and MOZ_DATA_REPORTING and friends) mcs/brade: what do you think?

We agree with you that it would be better to disable more of these "phone home" services. The pref system race is an interesting idea, although it seems like we would receive more reports of this problem (unless it is very rare that the race finishes a certain way).

An additional question for Steph: when you look at datareporting.healthreport.uploadEnabled via about:config, is it bold (user-modified)? In other words, do you have a default value of false or a default value of true?

Note: See TracTickets for help on using tickets.