IceApe - what are the differences from SeaMonkey 2.49?

[w2k4eva]

I recently installed IceApe on my old XP system (it has SP3 and the PosReady2009 updates) hoping that some of the web sites that old SeaMonkey can no longer connect to might be workable, but found no difference. The same list of websites get the Connection refused error in both browsers.

Ironically, this very site is among the ones SeaMonkey can no longer load. So are

• https://o.rthost.win/
• https://github.com/roytam1/iceape-uxp/tree/winbuild
• https://rtfreesoft.blogspot.com/

In other words, Ice Ape cannot visit its own sources, nor download itself, even after being installed. Is this expected? Do other people see the same issue?

edit: Whoops, I meant to put this in the "Browsers working on Older NT-Family OSes" subforum, could moderators please move it?

Edited October 29, 2024 by w2k4eva
fix bad link

[Mathwiz]

GitHub is problematic without some "help," but my IceApe-UXP pulls up the others fine. What problems are you seeing? Can you post a screen shot?

BTW, your first two links above both point to the same GitHub page.

Edited October 29, 2024 by Mathwiz

[w2k4eva]

6 hours ago, Mathwiz said:

BTW, your first two links above both point to the same GitHub page.

You're right, I never saw the forum software do that before... link is fixed.

Here are screenshots for the linked sites. Lest you assume it is some sort of network blockage or firewall issue - no, it is able to visit the Qualys site, it seems to report TLS1.3 being available as expected. While these screenshots are being made with iceape default profile that has no addons, I get the same results in my seamonkey install with its usual addons, which in time past used to be able to visit github until fairly recently. I even tried installing JustOff's polyfill addon (since I use it on my W7 system running 2.53.19) but that makes no difference on the XP system, not sure if it can really work in Seamonkey 2.49 even after installing, but it does not help either seamonkey 2.49 nor iceape.

What I find odd is that iceape supposedly has TLS1.3 available where seamonkey 2.49 does not, yet that seems to make no difference in what sites the browsers can connect to.

Edited October 29, 2024 by w2k4eva

[AstroSkipper]

On 10/29/2024 at 10:29 AM, w2k4eva said:

Here are screenshots for the linked sites. Lest you assume it is some sort of network blockage or firewall issue - no, it is able to visit the Qualys site, it seems to report TLS1.3 being available as expected. While these screenshots are being made with iceape default profile that has no addons, I get the same results in my seamonkey install with its usual addons, which in time past used to be able to visit github until fairly recently. I even tried installing JustOff's polyfill addon (since I use it on my W7 system running 2.53.19) but that makes no difference on the XP system, not sure if it can really work in Seamonkey 2.49 even after installing, but it does not help either seamonkey 2.49 nor iceape.

What I find odd is that iceape supposedly has TLS1.3 available where seamonkey 2.49 does not, yet that seems to make no difference in what sites the browsers can connect to.

 

 

 

There is no problem with IceApe. I can easily connect to all websites. Here is a screenshot regarding the https://o.rthost.win/ site:



Either your browser is misconfigured or something is blocking some of your connections. Check your network settings, internet connection settings, security  settings, and update your root certificates! In any case, the problem is on your side. And don't forget that the problem can also be sitting in front of the computer! (Old computer wisdom.)

Edited October 30, 2024 by AstroSkipper

[Mathwiz]

From the screen shots, connections to those sites are refused before you even get to the TLS negotiation stage, so TLS 1.3 support won't make any difference.

(At present most sites still support TLS 1.2, so TLS 1.3 support doesn't yet add much to the places you can go. That will probably change in the future though.)

I can get to all those sites with IceApe (although the GitHub site looks terrible). SeaMonkey 2.49.5 works too, so I think your problem could be a DNS issue, or maybe some kind of proxy is in the way. Whatever it is, some sites (such as SSL Labs) apparently work but others don't.

If I "ping o.rthost.win" from a command line, I get responses from IP address 104.21.48.191. What happens on your XP system?

[w2k4eva]

8 hours ago, Mathwiz said:

"ping o.rthost.win" from a command line

Dang, wish I had seen this reply before I started putzing with this again... this might have been an interesting thing to try. The problem seemingly affected roughly a third of the entire internet, not just those sites.

Anyway, the problem was clearly something about my XP system, since my W7 laptop running SeaMonkey 2.53.19 connected to the same router could view those pages. Your reply above plus AstroSkipper's confirmed that it was not IceApe (and your second reply also rules out old SeaMonkey 2.49). So, thanks to both of you for confirming that.

On 10/30/2024 at 10:08 AM, AstroSkipper said:

Check your network settings, internet connection settings, security  settings

SeaMonkey (and thus IceApe based on it) does not use any of the settings from IE/Internet Options, none of its trusted or blocked zones, etc.

On 10/30/2024 at 10:08 AM, AstroSkipper said:

update your root certificates!

I had already updated the system root certs.

I know SeaMonkey (and thus IceApe as well) uses its own internal cert store rather than the system one; just for jollies I looked there to verify the relevant certs were in place (they were, for both browsers).

I was not using a proxy either, and had already disabled AV scanning of web pages for other reasons, so that left Comodo.

None of the Comodo firewall rules where I could mark the checkbox for "log this" produced any log outputs (for either browser). This narrowed it down to the only place without such a checkbox, namely the "Blocked Network Zones" list (which had only 6 obscure sites listed, so should not have been doing this much blocking). I tried deleting the one rule that uses this list, and replacing it with another rule that lists each of these entries separately, rather than as a reference to the first list. That did let me browse those sites, with both browsers. Next I tried going back to using that list in the rule again, which broke those sites (again for both browsers).

This list, like all Comodo rules, is stored as part of a private registry hive, and thus subject to the same bitrot issues as the rest of the windows registry.  I ended up having to delete the reference to the list, then delete the contents of the list as well. Retried some of those pages, they worked again. Finally re-entered the contents of the list, then used the list in the block rule, thus putting everything back like it was before this mess started. And after re-entering all this stuff, that seems to have cleared out the bitrot, and everything works again, for both browsers.

So, long story short, having such a paranoid set of firewall rules sort of qualifies as a "loose nut behind the wheel" type problem!

 

[AstroSkipper]

On 10/30/2024 at 3:08 PM, AstroSkipper said:

something is blocking some of your connections ...
Check your network settings, ... security  settings ...!

Just as I assumed! And that's why I prefer Windows 10 Firewall Control Plus XP when it comes to firewalls under Windows XP.  Never had such problems.  Most of computer problems are rather home-made. 

Edited November 3, 2024 by AstroSkipper
Update of content

[Mathwiz]

Glad you got it sorted out.

8 hours ago, w2k4eva said:

SeaMonkey (and thus IceApe based on it) does not use any of the settings from IE/Internet Options, none of its trusted or blocked zones, etc.

That's correct. None of the Mozilla-based browsers use those, including the UXP line. Chromium-based browsers are, of course, different and do use them; that may be one reason Micro$oft was comfortable replacing Edge's browser engine with Chromium.