VistaLover

@kuja killer Paypal-related issues have also appeared in the upstream forum: https://forum.palemoon.org/viewtopic.php?f=61&t=32581 https://forum.palemoon.org/viewtopic.php?p=264391#p264391 Mixed reports from various users there, probably depending on their physical location; PayPal are conducting various A/B tests, it seems (read e.g. this PMForum thread ); user at the second link I posted thinks that it's NOT CloudFlare, but a PayPal-specific recaptcha (security check) that is NOT compatible with UXP-based browsers ... Can you try again with a fresh NM28 profile, where you block nothing? FWIW, with my ISP's Greek IP, I can access https://www.paypal.com/signin in NM28 at this very time without issue, but, as I don't have an account with them, can't proceed any further...

...It wasn't working for him, but now it is : PS: The forum software doesn't send a second (e-mail) notification to thread-subscribed members after one has edited one's original post (for which an initial notification has already been sent) ... Browser profile corruption is always a possibility, so, as others have noted, regular profile back-up and back-up of important info on physical copies is always strongly recommended ... ... Probably NOT ...

... Your generalised , yet unhelpful , comment about AVs aside, what I actually meant with "berserk" was that the ZIP archive (and contained yt-dlp.exe binary) shared by nicolaasjan previously here was flagged, more specifically the wrapper DLL file "libxt.dll"; I'm sure this is a false positive, yet many AV engines won't "tolerate" well such wrapper DLLs, which hook and alter system file behaviour ; on VT, half (31/67) the engines listed there ALSO flag the archive as "malicious": https://www.virustotal.com/gui/file/6ee52d1561e7ba3fc833eef35673d35b5325b2a5aad4efeeda5a1ae2c08aba41/detection ... but let's NOT turn this into an AV pros & cons discussion; MSFN has a dedicated forum/thread, oftentimes turbulent and cyber-bullied ... I whitelisted the archive and binary, what I wanted to convey was that the binary wouldn't even launch under Vista SP2, let alone perform a video download test ...

... One should visit nicolaasjan's GitHub repo ; load latest yt-dlp release, https://github.com/nicolaasjan/yt-dlp/releases/latest then expand assets (if not expanded) and there they are : yt-dlp_win7.exe => 64-bit compile, yt-dlp_x86_win7.exe => 32-bit compile, BOTH are built on py3.13, so are good for the next 4 yrs, at least... Win7-compatible py3.13 courtesy of adang1345 ... Well, you didn't go through the GitHub issue I linked to ; there are automated solutions suggested such as this one : https://github.com/grqz/yt-dlp-getpot-jsi/blob/master/README.md @user57: https://www.python.org/downloads/release/python-31018/ is the latest py3.10 release by the PSF (security-only release in source-code form: https://www.python.org/ftp/python/3.10.18/Python-3.10.18.tar.xz ) Let me just say that achieving Vista SP2 (NT 6.0) compatibility should be much easier that targeting XP (NT 5.x); the last Vista compatible version was py3.7 (py3.4 for XP SP3). One should thoroughly comb the py3.10 source code and identify ALL the Vista breaking code the PSF authored after py3.7; these changes should then be reverted or rewritten with "translated" code that is py3.7 compatible; once that task has been completed, the modded source should then be compiled with a suitable compiler (MSVC and/or MSYS2) targeting NT 6.0 and, also, the 32-bit architecture; but this is NOT all ; yt-dlp itself has quite a large number of dependencies, i.e. Python modules; the py3.10 wheels for them to be found on PyPI are made with the official py3.10 in mind, so compatibility with a Vista-py3.10 isn't always a given, especially in the case when the modules contain C/C++ extensions (i.e. DLLs, which, under Windows, have the .pyd file extension); these Python modules have to be recompiled from their sources using the modded py3.10 and the same compiler that compiled py3.10 itself (probably on a Win10 host). Things on XP should be even more difficult because several py3.10 own dependencies, e.g. OpenSSL, have moved away from XP long time ago... https://github.com/adang1345/PythonWin7/blob/master/Notes.md#python-310 and https://github.com/adang1345/PythonWin7/tree/master/patches are adang1345's instructions on how to make py3.10 run on Win7; perhaps they'd be somehow useful for someone wanting to also attain NT 6.0 compatibility ... PS: the yt-dlp devs are adamant on always dropping a Python version once the PSF have dropped security support for that version (they're also keen on using the latest bells and whistles a new Python version comes with ) ; and the PSF always align themselves behind Microsoft when it comes to the Windows OS, so, as a result, only Win10+ is officially supported now ... PS2: Maroc's py3.11 offering previously discussed is what is called a binhack (binary hack): official DLL and EXE binaries are HexEdited and XP-incompatible functions are either stubbed or forwarded to a set of wrappers, mostly One-Core-API and/or Wine DLLs; the end result 1) makes my antivirus solution go completely berserk 2) WON'T even launch under Vista SP2 32-bit, as the wrapper DLLs specifically target NT 5.x system DLLs ...

First of all, have a read of below yt-dlp GitHub issue tracker comment: https://github.com/yt-dlp/yt-dlp/issues/13965#issuecomment-3168934752 Some of the described solutions may work for you (as they did for others ) ... At the same time, the yt-dlp devs are already working towards the (plausible) scenario of SABR-only: https://github.com/coletdjnz/yt-dlp-dev/tree/feat/youtube/sabr https://github.com/yt-dlp/yt-dlp/pull/13515#issue-3164587812 (latest test release, requires Win10+: https://github.com/coletdjnz/yt-dlp-dev/releases/tag/2025.08.10.010506 ) Since you're mostly on WS2008R2, the server edition of Win7, and @nicolaasjan already provides Win7-compatible (py > 3.9) yt-dlp compiles, you should be good to go when the currently experimental SABR downloader makes it, in due course, to the release branch of yt-dlp; Vista SP2 and XP SP3 users will be the ones "left stranded on a desert island" after October, because so far no solution has materialised for those users (i.e. a CPython > 3.9 recompile/fork that would launch BOTH on NT 5.x/6.0, having additional support for all yt-dlp required Python modules ) ...

https://ssyoutube.online/privacy-policy

Well, r3dfox comes with SSUAO (site-specific-user-agent-override) support , so I bet you can set one just for chase.com and be done with (i.e., it won't affect other domains/sites) : general.useragent.override.chase.com;"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0" FWIW, "128.0" is the previous ESR version, currently at v128.13.0, which is supported for a month or two more , to be EoS'ed with v128.14.0; it's highly probable by that time that Chase's minimum requirements will get upped to "140.0" , the current ESR branch (now in v140.1.0) ...

... Is it this one ? https://repo.palemoon.org/MoonchildProductions/UXP/commit/76c9a8a09fa5eb6d0a7567adefeb57a4dbdf2964

One of the features of r3dfox I like the most is the fact it allows for the installation of UNSIGNED Firefox extensions, despite itself being derived from the "Release Branch" of upstream Mozilla Firefox; in "stable" (and "beta") Firefox, the pref "xpinstall.signatures.required" defaults to "true" but even when toggled, it doesn't produce the desired effect: UNSIGNED extensions remain incompatible and won't install (Mozilla's decision to protect the "masses" - this term is now used loosely, considering the declining Firefox userbase - from shooting themselves in the foot ) ... The way r3dfox achieves this is via two buildconfig flags (issued at build time): --with-unsigned-addon-scopes=app,system --allow-addon-sideload ; additionally, in the resulting binaries, "xpinstall.signatures.required" defaults to "false" ... As in the case of ESR Firefox/r3dfox builds, the add-ons manager (AOM, about:addons) will let you know of installed unsigned extensions, if any, by displaying a coloured "warning" bar underneath each unsigned extension (taken from 128.12.0esr): Personally, I regard these "warning" bars as (slight) irritants, polluting my AOM's view, so, starting with r3dfox-115.13.0esr onwards, I have been systematically hiding them via custom userContent.css code: /* Remove "Recommendations" from AOM, https://www.reddit.com/r/firefox/comments/184nqq0/how_to_remove_recommendations_page_in_firefox/ */ @-moz-document url-prefix(about:addons) { .category[name="discover"] { display: none !important; } .addon-card-message[type="warning"] { display: none !important; } } Above code was working flawlessly up-to-and-including r3dfox-139.0.4-2 (Greek, "el", locale shown below): Enter r3dfox-140.0.4 , to which I updated yesterday; imagine my surprise+disappointment when the AOM was loaded: Make no mistake; I did go through 140's Release Notes as hosted on GitHub, prior to installing, and, as another MSFN member noted, they stated: IMHO though, any r3dfox-specific change likely to interfere with user customisation, however small, IS worth mentioning in Release Notes... Luckily for me, I found my way to 140's source code in GitHub and immediately noticed what looked to be the culprit commit: https://github.com/Eclipse-Community/r3dfox/commit/c69c8d07e9e421ef8b3f3ea6b730f8b3a4443fa8 With respect to the browser author , changing the "aboutAddons.ftl" file, part of the embedded en-US locale, isn't a smart thing to do, unless: 1) you restrict users exclusively to the embedded en-US locale, 2) you have the resources to produce yourself (i.e. translate from English-US) the rest of the locales; e.g., once one installs the Mozilla-provided 140.0.4_en-GB locale, the author changes are being reverted to what the Mozilla wording is: FWIW, the change in the "aboutaddons.js" file is what BROKE my custom CSS code above; sanity returned when the code was amended accordingly : /* Remove "Recommendations" from AOM, https://www.reddit.com/r/firefox/comments/184nqq0/how_to_remove_recommendations_page_in_firefox/ */ @-moz-document url-prefix(about:addons) { .category[name="discover"] { display: none !important; } /* https://github.com/Eclipse-Community/r3dfox/commit/c69c8d07e9e421ef8b3f3ea6b730f8b3a4443fa8#diff-602c847d11b48c077836e06c7ee9e9e8450ad6a90d39211ba75530743c44fbb7 */ .addon-card-message[type="info"] { display: none !important; } }

https://repo.palemoon.org/MoonchildProductions/UXP/issues/2078 (CLOSED some 2 1/2 yrs ago ...)

What version of New Moon? What SSUAO in use? In what way does the site NOT work for you? I'm currently using: general.useragent.override.arte.tv;Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0 and a very old by now NM28 (v28.10.7a1, 32-bit, 2024-09-06) has no issues here, both loading the site AND playing back videos:

... OT , but JRE 8u461 has already been released: For the duration it's the current version, it can be downloaded anonymously from: https://www.java.com/en/download/

... And now yt-dlp have updated their random UA string to report Chrome 132-138: https://github.com/yt-dlp/yt-dlp/commit/c59ad2b066bbccd3cc4eed580842f961bce7dd4a#diff-b6d91e8afdfc47fb2b59e37d22d3621b79d252bc5a8205edc2b80530dcceecc2

I took a closer look at updated file "update.py": https://github.com/nicolaasjan/youtube-dl/blob/embedthumbnail/youtube_dl/update.py which you originally copied from: https://github.com/ytdl-org/ytdl-nightly/blob/master/youtube_dl/update.py The update process correctly "calculates" the hashsum of "current" version, Latest version: 2025.07.12.1, Current version: 2025.07.12 Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735 which is indeed identical to the value displayed at https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12 Which part of the code inside "update.py" is responsible for that? I understand that your tags/releases don't have a SHA2-256SUMSfile as asset... Updating to version 2025.07.12.1 ... WARNING: no hash information found for the release According to https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.12.1 the missing hashsum value for youtube-dl.exe should be: 21534c1543d62f4543efff017da1c8dd18a47e64995fd7e8c84215a433752db5 Why isn't "update.py" able to "calculate" it and, more importantly, how can it be fixed? GitHub adding a "sha256:*" column under assets (not as separate asset) is a relatively new feature, AFAIAA... In file update.py, I can identify two hashsum calculating blocks: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L84-L91 Is this one for "current" (non-updated) binary? Then, there is: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L130-L138 which obviously pertains to the "updated" binary; I can see mentions there of files "SHA2-256SUMS" that your fork lacks; lastly, the WARNING is issued as a result of lines: https://github.com/nicolaasjan/youtube-dl/blob/da27e0bb378940575d4ac1a5d2a9c9899f7f94ec/youtube_dl/update.py#L172-L174 Someone knowledgeable in Python needs to review the "update.py" file and come up with a "fix"; perhaps if you kindly ask dirkf in GitHub, he could oblige ... C'mon, you know me better than that ... Sorry for being a PITA, best wishes !

... Some fine tuning is still needed, am afraid ; yes, I got build "2025.07.12" to update to "2025.07.12.1" via "-U" from the cmdline, youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.07.12 [debug] Lazy loading extractors enabled [debug] Single file build [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} Latest version: 2025.07.12.1, Current version: 2025.07.12 Current Build Hash 58815fc0de70a06e76a9e9ca0337dfcdda59b1db0ffed12d150df626d8cd7735 Updating to version 2025.07.12.1 ... WARNING: no hash information found for the release Updated youtube-dl to version 2025.07.12.1 but a WARNING is issued during that process: Is this something that can be fixed somehow? FWIW, that warning isn't there when updating dirkf's "nightly": youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.02.28 [673277e51] (single file build) [debug] ** This version was built from the latest master code at https://github.com/ytdl-org/youtube-dl. [debug] ** For support, visit the main site. [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} Latest version: 2025.05.05, Current version: 2025.02.28 Current Build Hash a1ab42ffb8175b7d32c87e986b5d9f476b952b239aae7a228fac4b6bd8a81b3e Updating to version 2025.05.05 ... Updated youtube-dl to version 2025.05.05 Thanks in advance ...

... Huh, I see ... This is very puzzling, indeed ; in fact, the "yt-dl.org" domain now auto-redirects to yt-dlp GitHub URLs, e.g. https://yt-dl.org => https://github.com/yt-dlp/yt-dlp , which, of course, is a fork of the original youtube-dl project; I think dirkf doesn't have immediate access to the "yt-dl.org" server (wasn't that one blocked in Germany at some point?), so the answer about who arranged the autoredirection to yt-dlp might be possibly found inside the yt-dlp repo itself (too hot here currently for me to check, sorry ) ... I know; however, I have a small list of test commands I issue with fresh releases of both youtube-dl (nightly branch) and yt-dlp (your "Vista" compatible build) and that same list was used to test your 2025.07.11 compile; that was how I noticed the change in behaviour for " -vU" ... As I'm not proficient in Python (quite the opposite, in fact ), that was what I was about to suggest to you ; glad you got it sorted already ... The same with most "yt-dl.org" links contained inside: https://ytdl-org.github.io/youtube-dl/download.html I know ; I had already modified locally the latest "official" Nightly release (2025.05.05) according to your posted diff on GH; let's hope a py3.4 solution becomes available if evil Google start blocking Chrome > 97 UAs... Best regards !

There's something wrong with the latest (v2025.07.11) youtube-dl.exe build downloaded from GitHub: https://github.com/nicolaasjan/youtube-dl/releases/tag/2025.07.11 https://github.com/nicolaasjan/youtube-dl/releases/download/2025.07.11/youtube-dl.exe youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.07.11 [debug] Lazy loading extractors enabled [debug] Single file build [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} Traceback (most recent call last): File "C:\Users\nico\Desktop\youtube-dl_source\youtube_dl\update.py", line 48, in update_self File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 502, in error File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 685, in http_error_302 File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 470, in open File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 580, in http_response File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 508, in error File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 442, in _call_chain File "c:\Program Files (x86)\Python3.4.4\lib\urllib\request.py", line 588, in http_error_default urllib.error.HTTPError: HTTP Error 404: Not Found ERROR: can't find the current version. Please try again later. The previous compile, of version 2025.06.26: https://github.com/nicolaasjan/youtube-dl/releases/download/2025.06.26/youtube-dl.exe , behaves as expected: youtube-dl -vU => [debug] System config: [] [debug] User config: [] [debug] Custom config: [] [debug] Command-line args: ['-vU'] [debug] Encodings: locale cp1253, fs mbcs, out cp737, pref cp1253 [debug] youtube-dl version 2025.06.26 [debug] Lazy loading extractors enabled [debug] Single file build [debug] Python 3.4.4 (CPython x86 32bit) - Windows-Vista-6.0.6003-SP2 - OpenSSL 1.0.2d 9 Jul 2015 [debug] exe versions: none [debug] Proxy map: {} youtube-dl is up to date (2025.06.26) Many thanks for your ongoing efforts towards maintaining support for "our" older OSes ...

https://github.com/advisories/GHSA-mj9c-f5v6-7665 Severity: High (8.1/10) https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_30.html Manual mitigation, at the expense of performance, if you don't want to update: https://github.com/Alex313031/thorium/issues/1024#issuecomment-3038992237

Out of curiosity, I got myself a HK IP address and then tried to load: https://repo.palemoon.org/MoonchildProductions/UXP This is what I got: It would be far-fetched to think (would it? ) that MC specifically blocked access to his Gitea instance in Hong Kong, where roytam1 resides, as a means of thwarting further development of the UXP "XP forks", that he so much despises... In any case, @roytam1 are you behind the GFW in HK? Can you not use a geo-spoofing application (VPN, VPS, DNS, Shadowsocks, etc. ) to acquire, e.g., a European IP address and properly access RPO? Worst case scenario, one of "us" here could send you a tarball of the proper UXP repo, though currently this stands at ca, 252 MB:

RPO (repo.palemoon.org) is a server owned and paid-for by Moonchild himself; Gitea is just the version control software deployed on that private server to manage source development for UXP, Pale Moon and related projects; it's what is called a "private (self-hosted) Gitea instance" ; on the Anubis test page itself, one can read: ... so I believe MC is mainly concerned with excessive bandwidth consumption; please also note that he had already implemented geolocation-based ACLs (access-control-lists) to counter automated DDoS attacks and, as a consequence, in Hong Kong (where our own roytam1 lives ) RPO is blocked ...

... This only means further/wider proliferation of such MITM anti-crawler "services", with the web becoming even more "unpleasant" as time moves on (with a greater impact, of course, on older browser engines, on old/weak H/W); what's the point of having 500 (or more) Mbps fiber internet speeds when every tab you open in your browser will need additional time to pass complex JS tests? FTR, I keep, for historical purposes, a "portable copy" of NM27 (not the last one published, though), which isn't able to pass the Anubis test (e.g., on RPO Gitea repos); and even Serpent 52 struggles passing that test, especially if I don't disable "security/privacy"-oriented solutions (extensions and/or userscripts); privacy also falls victim here, because you're given no other choice on such web-policing "services": either "open" your "privacy fences" or be denied access to the site you're after ... This is all depression-inducing ...

https://repo.palemoon.org/MoonchildProductions/UXP/issues/1721 https://repo.palemoon.org/MoonchildProductions/UXP/commit/c030a50228349fa1b2c0b4fbc2e83752324dd4d7 https://www.palemoon.org/support/global-privacy-control

@IXOYE : In NM28, a SSUAO for ARTE is needed; posing as FxESR-128 on Win10x86 works for me in order to load its English homepage : general.useragent.override.arte.tv;Mozilla/5.0 (Windows NT 10.0; rv:128.0) Gecko/20100101 Firefox/128.0 ...

Upstream (i.e. UXP/Pale Moon) are already aware: https://forum.palemoon.org/viewtopic.php?t=32222 https://repo.palemoon.org/MoonchildProductions/UXP/issues/2721 Here a workaround is kindly offered (requires an additional extension ) ...

... Respectfully, I beg to disagree ... While 128 is the currently supported Firefox ESR version, the previous ESR (Firefox 115) is also supported, for the sake of Win7/8/8.1 users (support will end, supposedly, next September); the minimum Fx version supported by AMO, is, thus, 115 ... FirefoxESR-115 has the same User Agent String as the release channel Fx-115 had, which was (e.g., on Win7 SP1 32-bit): Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 For Firefox versions 110-119, the "rv:" value was frozen to 109, due to a Mozilla bug ... Below is r3dfoxESR-115.13.0 (a FirefoxESR-115 fork that is able to run under Vista SP2) with a SSUAO of: general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/115.0 visiting https://addons.mozilla.org/de/firefox/addon/traduzir-paginas-web/ : When the above SSUAO is "lowered" to Fx-114, general.useragent.override.addons.mozilla.org;Mozilla/5.0 (Windows NT 6.1; rv:109.0) Gecko/20100101 Firefox/114.0 ... the issue you reported occurs: So, probably until the end of Sep 2025, Firefox 115 is now the minimum... Kindest regards.