w2k4eva

YouTube just doesn't work this way, in fact it is exactly backwards from what you want. I have never had a google account of any kind, including YouTube, and have never been blocked from watching any video I wanted to see. And trying to put restrictions on her account (if it is even possible) isn't likely to work for very long - at age 11, she is old enough to figure out that she can just go view them without logging in. You might be better off having a conversation with her about why some content is not suitable and convincing her to avoid it on her own. Especially since a channel blacklist is about as useless as an AV that tries to work by listing known malware - there will always be a new item that is not on the list yet. You might still be able to set screen time limits, or per-app time limits, with whatever parental controls are in Windows or Android, though. Just not channel-specific blocks.

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. 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. 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!

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.

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?

Not directly, the web server decides which cert chain to present. At some sites it depends on what device, OS or browser it thinks you are using, or what location it thinks your IP is at. You can try experimenting with different user agent strings, but some web sites use additional javascript libraries or other fingerprinting methods to get past a simple UA string spoof. Or you can try different VPNs to get IP addresses from different locations.

Yes, this is my conclusion as well:

Okay... it looks like that should have covered it in terms of having the certs. So what is left is whether chrome360 can handle the certs it has. Which is a different question than whether they are missing. For the two X1 root certs, are they indeed the same? Or does one use ECC type encryption while the other uses RSA? You would need to examine both of those certs in detail to see that. Could you look at which certs that site is actually using, and check each one in the chain to see if they are using the possibly problematic ECC versions? For some versions of some browsers, if a given website had multiple possible paths to chain to a trusted root cert, they would try the first path encountered and if that failed they would not try any of the other paths even if that would have worked if the first path tried had not been there. For that situation one would have to figure out the failing path and eliminate some certs so that path would not be possible, forcing the browser to use another path that would work. I do not know whether your version of chrome360 has this issue, or if eliminating such a duplicate path might help for your case. Some other users are posting screenshots of such ECC certs working in XP with MyPal, is trying that an option for you? Otherwise you are back to making the proxy handle it for chrome360, which does indeed belong in this thread.

Seems this question could fit in any of 3 threads. Since the screenshots are already in this thread, I'll try here, though if forum admins ask and/or move the posts with screenshots I'll be happy to move there. But looking more at your previous screen shot, leaves me more confused too, it gives conflicting information. On the heading "Insecure connection" it says "Your connection to web1.carparts-cat.com is not encrypted" but 2 sentences later says the connection is encrypted, plus the "security overview" thing has the 2 items of green text saying ""the connection to the site is encrypted" and "All resources on this page are served securely" ... rather contradictory. Does anyone have access to source code for chrome360 who can tell us what this combination of messages might actually mean? Also from the previous screen shot, it says "Certificate - missing". Your second screen shot shows the ISRG Root X2 cert, but not as a root cert - that looks like the cross signed version (actually an intermediate cert, not a root cert), which depends on also having the X2 cert signed by the X1 cert. So, does your chrome360 have a root cert for ISRG Root X1 (probably listed on a different tab in the certificate manager, I don't really read German so can't suggest the tab title)? Part of the confusion is that there are multiple versions of these certs, having the same names. That's why I mentioned "Certificate details (self-signed)", it seems you have the cross signed version. If you need the X1 root cert, it can be downloaded from the same page I linked before (again, look for the "self signed" variant). So if that is present (as a root cert, it too has a cross signed intermediate form that would require yet another root cert that signed it), it might come down to whether chrome360 can handle the ECC type encryption, or if not, whether you can get the proxy to do that for you.

Does your chrome360 include the root cert ISRG Root X2 ??? This could be as a root cert, or in the older case it used to be an intermediate cert cross signed by ISRG Root X1, which in turn could have been either a root itself, or cross signed by DST Root CA X3. If that/those is missing you might have a problem... it DOES appear to be properly encrypted, just to a root cert that itself is not trusted. edit: you can download the cert from https://letsencrypt.org/certificates/ scroll down to "Root CAs", then "ISRG Root X2", then "Certificate details (self-signed)" choose your format, since I do not use chrome360 I'm not sure whether it prefers *.der or *.pem, someone on here who uses it can give better instructions on how to add it for your browser, or if it uses the system store

One thing that still puzzles me is about the *.sst files themselves. What is the function of each file, and does updroots.exe do anything different based on the filename it is called for? I mean, the use of something called "delroots.sst" or "disallowedcert.sst" seems self explanatory, but what about the other 3? I see from the contents that roots.sst has Microsoft-related stuff that could be needed to check the cert lists themselves, so it makes some sense to have it in a separate file for the convenience of those folks who want to manage their own lists. But for authroots.sst vs updroots.sst, the difference is less clear. There must be some reason Microsoft used 2 files instead of combining them all into 1 file, so how are these different?

I've been seeing this Wayback problem for at least 4 years now. It seems to affect many (most/all?) MS KB pages that were crawled from 2016 onward. I never had much luck with this method, since for me the page load takes several seconds after clicking Stop to take effect. So I must stop it before the page is shown and it was very hard to get the timing right on something I can't see yet and am not sure exactly how long it will take on any given attempt. What I did notice is that over the years MS has changed the format of URLs for their KB pages, and usually the older version of the URLs was from a time before this wayback problem. So fortunately for this particular update there is actually an older crawl with the different format of URL that works, even from SeaMonkey 2.49.2 on XP: http://web.archive.org/web/20150602151315/https://support.microsoft.com/en-us/kb/898461 (notice the /en-us/kb/ part, these are usually the better formatted crawls) Sadly for other updates there isn't always an older crawl that will work, and sometimes I am stuck with having to view page source and poke through the HTML tags to find the unformatted content (which is generally still present although not rendered correctly/at all).

There are a few lists, depending on whether you do/don't use MS Office, .NET, WMP11, IE8 etc. Some posts: https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1156088 https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1162280 (and next post too) https://msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/?do=findComment&comment=1167061 Perhaps you want the opposite list, of updates that are SSE2-free? https://msfn.org/board/topic/178377-on-decommissioning-of-update-servers-for-2000-xp-and-vista-as-of-july-2019/?do=findComment&comment=1162417

No. I have this update installed on at least 3 systems - two of which have had the HDDs replaced several times so Windows got reinstalled and updates re-applied several times - and have never seen any issues from it. Continuing to quote from the same KB article as luweitest found above, You can look there to see if you have any of these files. Depending on which updates you have already installed, you may have some of them (minus the .ref suffix) also in \windows\system32 or elsewhere, probably even a newer version. In any case updates downloaded from the Update Catalog will generally have these files (or more likely a newer version, this set is VERY old, from 2005) packed inside each update as needed, although there is the occasional poor quality update that has a missing file, these will probably have been flagged somewhere in this massive thread. (As noted above, "Downloads from the Windows Update Catalog site are not affected.") So you could just get ALL your updates from the catalog and install them manually without needing to install this one first. I suspect Windows Update considers this to be a prerequisite for doing any further updates, this may be why you see this behavior of not doing the other updates. If you want WU to install ANYTHING for you, this one is probably needed first. But beyond that, I'm a little surprised WU did anything at all, I thought the update server was no longer compatible with XP since they changed all the certificate signatures to SHA2 only....

You could (assuming you have "custom" mode selected rather than Express mode) highlight it and then look for the "hide" link to click. But choosing to download them manually from the catalog and install only after researching each one is the safer option.

It's a pretty persistent glitch, I've been seeing this for more than a week now. And yes, on wired ethernet, not even wifi. In some cases, repeating the page load does not produce the links even after 10 or more reloads. At least the suggestion to use the googlebot UA does seem to work nicely for the catalog site. Too bad it has the opposite effect for thehotfixshare.net and some other sites - it will cause a not-so-nice forbidden error there. FWIW, my normal UA would be Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 SeaMonkey/2.49.2 Edit - I have also been seeing (intermittentently) incomplete data from the catalog. Sometimes a search comes up with nothing found, other times it will find some items but have others missing - such as listing only 14 items when there are actually 17 to be returned. This is both for search results, and also for the replacement info when one of these search items is clicked. Sometimes all replacement items are missing entirely, other times only a subset is returned when I already know certain items should be there but are not.

Well, the fixed IP address turned out to be the relevant clue. I changed this back to automatic assignment from the router's DHCP service, rebooted, and had no connection. Investigating this showed the XP DHCP client service had somehow gotten disabled. Resetting this to Automatic solved the issue. Apparently Comodo likes to see the DHCP handshake happening for whatever reason, even if it does not actually need the IP address - I can even go back to fixed IP address now without getting that 90 minute delay any more!

For KB4494528 do the regsvr thing like Ed_Sln and others have said. I installed KB4493563 and do not see any problem, but I am using the US English version in case that matters. KB4501226 is a time zone update (these are usually neither critical to have, nor troublesome if you do use it) for Morocco and the Palestinian Authority. I installed it with no problems.

Did you end up with a corrupt download? Or are you using a non-ENU version? I got this from the catalog on 18 Apr 2019 and it does indeed contain ntdll.dll version 5.1.2600.7682. I even re-downloaded it again a few minutes ago from the catalog and the file is identical to the April download. I do agree though that the English version of ntdll.dll has the last error message duplicated and the other message missing as you describe.

Has nobody else ever seen this? I ran scans with MBAM, SuperAntiSpyware, and Avast boot time scan. As expected, no malware found. Also noted another odd thing. The 90 minute delay can be cut short by temporarily disabling the ethernet adapter; the GUI unlocks, and the tray icon works again. Re-enable it, and everything is good to go. FWIW, I found it was set up for a fixed IP address rather than the usual assignment from the router's DHCP server, so it wasn't even waiting for an IP address. Any debugging suggestions?

Is anyone else here using an old version of Comodo? (3.14.130099.587 for me, or possibly some of the v5 series) I've had this version installed (just FW and Defense+, not the AV, for that I use Avast 6) on this machine and running perfectly for more than 4.5 years. But around 4/29 it started behaving oddly (on just this one system, I have it running perfectly on several others). That's when I noticed that the system tray icon allows calling up the GUI for a little while immediately after booting, but somewhere between 2 and 3 minutes post boot, the tray icon goes unresponsive. When this happens I also cannot call up the GUI from the start menu, nor from desktop shortcut. Then after roughly 90 minutes, suddenly the GUI that would not start earlier finally appears and thereafter works as if nothing were ever wrong. This delay seems pretty consistent as does the 2-3 minutes postboot, almost as if something has a timeout, though I don't know what it is waiting for. I checked in Task Manager during this time, and there are no unfamiliar processes listed. Both cmdagent.exe (the service portion) and cfp.exe (the GUI portion) are running as expected, but I can't switch to cfp.exe during this 90+ minutes. Trying to kill cfp.exe during this time simply hangs Task Manager. Leaving this sit for the 90+ minutes will let it suddenly unlock and everything goes back to normal. It isn't a normal sort of network issue, I can surf and check email just fine during this time, the only thing I cannot do is open the Comodo GUI. I tried looking with the process list tool in an old version of Spybot; this has the added bonus of showing what network connections a process has open, which I can't check in the Comodo UI since I can't get to that while it is hung. It seems to have one ephemeral port open, the port number changes every few seconds while the GUI is not responding, but these changing ports will suddenly stop and the open port vanishes when the GUI becomes available again. Checking system event logs gives no clues, likewise Comodo's own logs show nothing odd. I even tried setting a rule on Comodo to log its own traffic but there are no entries from that rule. Other rules do make log entries during this time so it isn't a logging issue. Searching the Comodo forums finds several posts with similar symptoms (all from version 3.x or 5.x, I didn't see any later) but all of the supposed cures end up not solving it even for the posters who initially thought they had found the answer. (Apart from "upgrade your OS, then update to latest version", generally something post-ver 5 - but then why did this version work perfectly for 4.5 years on this system and even longer on my other systems?) I have tried the uninstall-reboot twice-reinstall path a couple times with initial success, but the problem always returns after 2-3 reboots so it isn't really the solution. I plan to run more malware scans later today but so far have not found anything; since there are no other symptoms I'm not really expecting to find anything when they are finished. Assuming the scans come up clean, does anybody have a suggestion for how I might track down the cause of this odd behavior?

I suspect they're the same thing, I downloaded the two files, and they are only 4 bytes different in size! The "payload" stuff is indeed the same. What is different is the catalog file, because it is signing the files branches.inf and update_SP3QFE.inf. These inf files contain slightly different timestamps between the versions. The other interesting difference is that the update_SP3QFE.inf file for the plain-XP version does not have the Prerequisite section that is present in the posready version; that section is what restricts the update from being applied to plain XP. Since that section is missing from the plain version, wouldn't those who did the reghack be able to use either version without modifications?

I mostly just use the editor included inside Ghost Commander. It's pretty basic but serves my needs. Ghost Commander is ad-free, tracker-free and open source. It's also root-aware, though it will work for unrooted devices too for as much access as filesystem permissions allow. There's even older versions in case your android is very old, I use ver 1.54.1b2 on my old FroYo device (this old version is supposedly compatible all the way back to 1.6 Donut), current version is for 2.3.3 Gingerbread & up. Second this! If I can't find something open source, I do make sure to check the IzzyOnDroid app lists to see how snoop-y it is likely to be or if there are alternatives I haven't considered yet. He does list which problematic libraries are compiled into what apps and if trackers are (not) found in them (look for the gold star icon). For instance, Office Suites and Text Editors lists a lot of editors you might check into. Another bonus to open source apps is they are more likely to still be compatible with older devices. A great open source non-google app is Yalp Store. This is a must for androids too old to install the current play store app like my FroYo device (it supposedly works back to 2.0 Eclair), and has active development (a new version was released in response to a bug I posted last fall). For email there is either K9 (for newer androids) or Squeaky (for older androids), both open source from the same codebase. I love CSipSimple for VoIP calling/texting over WiFi, it used to be on both playstore and f-droid (see https://f-droid.org/wiki/page/com.csipsimple) but has gone missing since I found it there. One last location survives, http://web.archive.org/web/20180816022955/http://nightlies.csipsimple.com/stable/ which does have the last version. It's none of Google's business where I hike or drive, so Navit gives an alternative to the preinstalled GPS/map apps. You can pre-download whatever maps/databases you like from several sources (including OpenStreetMaps, or you can make your own) and there is no need for a map server/user tracking/ad serving/whatever. The version on f-droid is older than the playstore version. The UI is rather goofy and takes a bit of getting used to so reading the wiki is a big help. Despite this I found it well worth the time I spent figuring out how to use the app and even extend it a little to show my favorite locations (there are forum posts on how to do this). There is an android section on http://software.oldversion.com/android/ in case you want an older version that is no longer on the playstore, though this is not an open source repo.

I don't have them myself but when OnePiece Alb created his various update packs and addons he collected these. Thankfully he posted them on box.com for public access.

Same here. Even worse, this problem exists for ALL hotfixes, even ones I already downloaded. Even if you already know the actual DL link, in a form like http://hotfixv4.microsoft.com/Windows Server 2003/sp3/Fix200653/3790/free/315139_ENU_i386_zip.exe from having downloaded it before, the same thing happens. Seems that the DNS entry for hotfixv4.microsoft.com now has a new CNAME pointing to hotfixv4.trafficmanager.net, not sure when that happened.

MS12-045 KB2698365 was for MDAC 2.8SP1, I seem to recall that for W2K builds this did not always integrate well with other MDAC updates, though I was not using nlite. I wouldn't be surprised if a similar issue exist with the XP version too. Are you able to integrate just this one by itself? If so perhaps close the nlite session, then start a second session for kb4489973? There may be a post by tomasz86 or bristols on the W2K and/or hotstream board about this...