User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:188.8.131.52) Gecko/20060729 SeaMonkey/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:184.108.40.206) Gecko/20060910 SeaMonkey/1.0.5 Almost every time SeaMonkey starts up and starts to access the internet, McAfee Firewall reports "This application has changed since the last time it communicated over the Internet. Do you want to allow this program to access the Internet?" I have answered "yes, always" many times, but it keeps happening. I have checked the firewall settings and verified that the only version of SeaMonkey in the list of authorized applications is the update I installed recently (i.e. build 220.127.116.11 2006091003), and that the list of ports is the same as it was for SeaMonkey 1.0.3 (which did not give me this problem). I have also closed the firewall and restarted it to ensure that it has saved the configuration info for the new SeaMonkey version. Reproducible: Always Steps to Reproduce: 1. With McAfee firewall installed and enabled in its "filter" mode, install & run SeaMonkey 1.0.5 without its quick launch feature. 2. When firewall asks "Do you want to allow this program to access the Internet?", click "yes, always" and "OK". 3. Close SeaMonkey & wait for it to finish closing - ie. ensure that it's not still in memory. 4. Restart SeaMonkey. Actual Results: Firewall should not ask again, but it does. Expected Results: SeaMonkey should be able to access the internet without triggering a firewall warning.
I wonder if you could install Firefox 18.104.22.168, allow it to access the internet and observe if this problem also occurs with FF then?
It sounds to me like a firewall quirk or bug. Do you have a program that can calculate a hash for a file (some file sharing programs do this) Make a copy of your current Seamonkey exe. And then after several start ups and messages from the firewall, make a second copy of Seamonkey. Compare the hashes of both those copies: they should be the same.
(In reply to comment #2) > It sounds to me like a firewall quirk or bug. I would agree, but I've been using this firewall for years and never had this problem with any other trusted apps, despite applying updates to many of those apps - e.g. IE 5.5sp2 to 6.0sp1. > Do you have a program that can calculate a hash for a file (some file sharing > programs do this) Make a copy of your current Seamonkey exe. And then after > several start ups and messages from the firewall, make a second copy of > Seamonkey. Compare the hashes of both those copies: they should be the same. Thanks for the suggestion, crf. I don't have a hash program, but I have checked for changes in Seamonkey.exe & other files in the install directory (using DOS COMP) and verified that there have been no changes. Maybe it's a registry issue? Anyway, I've found a workaround: I deleted SeaMonkey from the list of trusted apps, closed the firewall & restarted it, then re-added SeaMonkey. Now the firewall no longer complains. Interestingly, it's still using the same rule file (SEAMONKEY.RUL), which has not changed since I installed SeaMonkey 1.0.3 in July, but it has obviously updated its trusted app version info (CPD.GID?). Maybe McAfee Firewall doesn't recognize the new version of an app as legit unless the update process records the update in a particular fashion - e.g. in some registry key. (Just guessing; I know almost nothing about the registry, and even less about installers & updaters.)
(In reply to comment #1) > I wonder if you could install Firefox 22.214.171.124, allow it to access the internet > and observe if this problem also occurs with FF then? Thanks for the suggestion, Frank. The problem only seems to occur after updating a trusted app, and SeaMonkey is the only trusted app with which I've encountered the problem (see my reply to comment #2). However, I haven't tried Firefox. If I could find an earlier version of Firefox I'd try installing it and then updating to 126.96.36.199, but 188.8.131.52 seems to be the only release currently available for download. (I'm unwilling to try a beta version.)
Resolving INVALID - this is very very likely an issue with the firewall.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.