So to summarize, I’m using Firefox Developer Edition and it gets updated regularly.
There is a problem, however, with Glasswire’s tracking of version numbers.
Here is a list of alerts regarding Firefox updates:
I’m working with Mozilla tech support trying to figure out what is going on and they can’t make heads or tails of these version numbers. The lines with *** shows an anomaly. Meaning the source file does not match the destination file of the previous update. This should be the case in all instances of an update.
Where do these numbers come from if Mozilla, the creators of the files, don’t recognize them?
How is it these files appear to be changing and glasswire is either sending out the wrong information or some process is back-porting the executables? Whatever is happening Glasswire should be accounting for all changes in executables. Something else appears to be going on.
The problem is that the “destination versions”, which is to say the current Firefox versions, all look correct to me, as I previously stated. So at no point has the current version of Firefox on the disk been an unexpected version. The only thing that looks incorrect to me is the “source versions”. But I have no idea where these “source versions” are coming from. I’ve never heard of any way of asking a program what version it used to be. And if Glasswire is just remembering the old version number, it’s clearly doing a terrible job because, as you pointed out, the version number that it is remembering doesn’t seem to match the value that would be expected.
So, really, it sounds like Firefox is doing everything right. And whatever it is that Glasswire is doing to determine the “source version” is either wrong or doesn’t line up with your expectations, for some reason.
Does that sound correct, or is there something that I’m missing?
If the destination versions are correct as you are saying, I don’t understand why there would be multiple entries for any one version as in .8074, 8062, 8060, and 8053. Something appears to be back-porting the executable before the second entry. At least that is my interpretation. My concern for this is the reason of my original post.
Now we’re getting somewhere./
The dev appears to be a bit anal retentive and is not well suited to interacting with the public, but this response suggests TWO IMPORTANT THINGS:
There is no downgrading going on.
Glasswire may be erronesously reporting these downgrades.
Mozilla’s dev’s comment:
I’m not sure that “backporting” is the word that you are looking for here because it doesn’t make sense to me in this context. You don’t really backport an executable. You backport newer fixes/features from a newer version of a program to an older version of a program. My best guess is that you mean “downgrading”. But that doesn’t really make sense either. The version on the disk in both instances appears to be the exact same version, so it seems clear to me that no downgrading is occurring.
As a developer from Mozilla he doesn’t believe the downgrades are happening which means Glasswire is inaccurately reporting version numbers. The key is Glasswire has to ‘remember’ what the last version of the executable was. Mozilla thinks there is a bug in Glasswire that is reporting the wrong information.
I downloaded the Firefox XML file containing the update history from Mozilla’s perspective. The developer took his sweet time to get to this obvious step. He, like many young developers, likes to argue with customers and correct their technical diction rather than solve problems.
Anyway, I assume he’s looking at update history and will get back to me with how this may or may not match the update history Glasswire has for Firefox.
The Firefox Dev closed the bug which is not a surprise given his attitude.
Glasswire is reporting lots of updates that are unaccounted for in the Firefox logs.
There are several reports of ‘upgrades’ from different versions to a single target.
There are discreet problems in the Comparison logging.
Here’s an example:
Jan 18 Firefox reports updating to v97 beta5 which Glasswire reports as 97.0.0.8053
Jan 20 Firefox updates to v97 beta6 which Glasswire also reports as 97.0.0.8053.
There is a problem in either how Glasswire is recording the change or how Firefox is setting the version number.
On Feb 29 & 30 there are multiple reported upgrades of Glasswire that Firefox cannot account for.
The question remains. What is going on. Firefox devs are dyspeptic children and can’t be bothered, but I’d like to understand what is going on.
What are Glasswire’s recommendations on ways to move forward?
I am also a big Firefox fan, and I am using it now. However, I only use the stable versions so I have not seen the issue you are experiencing.
Is it correct that the red numbers in the list are versions GlassWire has missed completely? Please confirm. I read through and even searched for “red” in the post, and maybe I missed this. If so I apologize.
