VistaLover

I'll remind people here that I'm not actually an authority on Google Chrome and Chromium derived browsers, having been from the very start a Mozilla Firefox user, first (2005-2008) on a WinXP desktop and then (2008-2018?) on this Vista laptop... This is to clarify that I haven't followed closely Chromium's development during that era... I've learned quite a few things from XP users of Chrome 49, and it's true that specific [old] version (officially the EoS one for XP/Vista) does rely on OS resources/libraries for secure connections (which involve both available TLS protocols and available cypher suites). Contrary to what Google (the No.1 enemy of the Vista OS, by far ) believed, WinVista != WinXP, so having a fully updated Vista SP2 OS with TLS 1.2 support will grant you more accessible websites using Chrome 49 on Vista, thanks to Vista supporting more cypher suites by default and, on top of that, having SNI support that WinXP lacks... But all this is probably a moot point already, because Chrome 49's rendering engine is antiquated by now... To conclude, yes, Chromium 49 can only go up-to TLS v1.2 on an updated Vista system (with KBs targeting WS2008 originally ) At some point further down its development, Chromium disengaged to a degree from OS libs where TLS support is concerned, so that Chromium 57/58, upon which Yandex Browser (YB) 17.4/17.6 builds, comes with bundled/native support for the TLS protocol. I haven't used YB 17.6 (portable) here for many months, having long ago switched, first to 360EE v11 (Chromium 69 based), then to 360EE v12 (Chromium 78 based) and currently testing (beta channel of) 360EE v13 (Chromium 86 based). YB 17.x has other significant shortcomings by now, affecting Google Web Store (GWS) support , but that is part of a future post about YB 17.x ... By default, YB 17.6 supports TLS 1.0+1.1+1.2, provided by its own (Chromium) libs (i.e. non-dependent on OS TLS support, kinda like Firefox); but there is latent TLS 1.3 support, too, which can be enabled via a browser flag; The problem is that YB 17.6 was released at a time when TLS 1.3 hadn't been finalised yet, so it only supports a TLS 1.3 draft preceding the final one (i.e. RFC8446) Testing on dedicated TLS testing sites you get mixed results, depending on whether the test site detects pre-final TLS 1.3 drafts or not; SSL Labs client test picks up pre-final TLS 1.3: ... but Browserleaks ... and pinterjann DO NOT! As a closing note, if you want to disable lower, deemed currently insecure, versions of TLS, you can launch YB via a shortcut containing the following flag: --ssl-version-min=tls1.2 or --ssl-version-min=tls1.1 if you want to disable just TLS 1.0 ...

The last release channel version of WSUS Offline with Vista support was v10.9.2, released on 2017-03-19; the last release channel version of WSUS Offline with WS2008 support was v11.8.3, released on 2019-11-14. Vista users should probably use the ESR channel of WSUS Offline; the last/most recent version advertised on their download page with any Vista support is v9.2.5, released on 2019-06-04: https://download.wsusoffline.net/ => Archive However, there's still a more recent v9.2.6, not being publicly advertised, released on 2019-11-08: https://download.wsusoffline.net/wsusoffline926.zip

... My thoughts exactly!

Thanks for the explanation! How do you intend on pursuing this? Will you be going back to a --disable-accessibility build config flag for your future NM28 builds, continue as things stand now or is this simply now out of your control? ... OK then, pretty much as I had it figured out myself...

Let me begin by thanking you for continuing to deliver updated builds of your browsers, despite the recent major hardware hardships... (pun intended! ) Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are: Accessible.tlb AccessibleMarshal.dll IA2Marshal.dll I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir ; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant... Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 ) Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them... It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading... https://github.com/MoonchildProductions/UXP/issues/1653 Clean up Windows widget code https://github.com/MoonchildProductions/UXP/commit/6f5cd8a [widget] Clean up Windows widget code some. Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done... I'm really sorry to have to bring this up, but don't you expect "upstream" to hear about that? You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this? Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public? Thanks for all your hard work and efforts , thanks in advance for any answers received... Best greetings

MSE offline definitions file (mpam-fe.exe) and WD offline definitions file (mpas-fe.exe) both share the same engine, file mpengine.dll (currently at version 1.1.1730.5); no need to wonder anymore...

YES

... Now you hush, "young" gentleman! Those people are already extremely p***ed that you, single-handedly, created the Vista Extended Kernel project, so much so that they fear their "support channels" will get overwhelmed by Vista users running their official builds: https://forum.palemoon.org/viewtopic.php?p=198116#p198116 As the saying goes, "No good deed goes unpunished" ...

In yet another move, MCP have just modified specifically the unofficial branding for their Pale Moon web browser application: https://github.com/MoonchildProductions/Pale-Moon/commit/54aeb54 with updated graphics and nomenclature ... The overhauled graphics resembles that of the Mozilla Firefox recent Nightly channel, in blue-purple colours: ... but the new name given to unbranded unofficial builds (like what has been till now @roytam1's New Moon 28) is just... Browser ! No doubt a attempt on their part to coerce things to move to the direction they want... So, come this weekend (with the hope @roytam1's hardware issues are somehow rectified), be prepared to say hello to Browser 28.10.2a1 ...

@Vistapocalypse : A teaser/taster for now:

Moonchild's reaction, as of several hours ago: https://forum.palemoon.org/viewtopic.php?p=199503#p199503 In that same thread, now locked, he even hinted/threatened to move Pale Moon source code to a private repository, a la Binary Outcast... Let's just hope things don't get to that... Addendum: Related: https://forum.palemoon.org/viewtopic.php?f=40&p=199513 (... and Mypal build 28.13.0 - discussed above - has been now withdrawn, due to issues, replaced by build 28.13.1; this one has the same limitations though, with regards to upstream resources...)

... Impatience is not actually a virtue, at least not by me... You've also asked me practically the same thing last Sunday: In fact, I had already scheduled a detailed reply tackling the WD-on-Vista situation, but due to other things I'm into currently (coupled with an emergency visit to the dentist's ), that reply has been delayed... More to come when I find the time...

Off-topic: Well, people like you and me need to "spend" there, period: https://archive.org/donate/ (I have donated twice in the past... ) On-topic: As a friendly reminder, Adobe Flash player v32.0.0.171 has publicly disclosed security vulnerabilities, which have been patched in later versions; as long as the vendor continues to issue updated versions (currently 32.0.0.443) and until the announced final deprecation date (31/12/2020), the wise thing to do is use a current version when facing the internet... v32.0.0.171 should only be used to play back locally stored content (.SWF files) after the last "timebombed" version ceases to function... Just my 2 (euro)cents, of course...

... Well, fortunately things aren't yet as dire as you pictured them , all thanks to web.archive.org The URL https://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html has been captured 187 times in total, the last time "valuable" content was still in was on July 18th 2020 (https://web.archive.org/web/20200718192527/*) The last version of Adobe Flash Player without the 2021 timebomb was/is 32.0.0.371; WAO have actually captured the following URI https://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip 5 times, last one was on June 30th, 2020 (https://web.archive.org/web/20200630185943/*) ; the zip archive itself is at 388 MiB, so it'll take a while to come down from WAO... It contains all possible flavours of installers/packages, no need to search further... Don't make that mistake again...

... Do I get extra points for prophesying ? Try the above Direct Link now and you'll get the door slammed at your face : Access Denied You don't have permission to access "http://fpdownload.macromedia.com/pub/flashplayer/installers/archive/fp_32.0.0.371_archive.zip" on this server. Reference #18.c46656b8.1600036305.1ef6b01c

FT DeepDark has been my preferred Firefox Complete Theme ever since it was made available ; of course, Fx Quantum killed it , so development reached an end, with its final version supporting Fx 56.0 (and I could only run up to Firefox v53.0 on this Vista machine ) ... It is a crying shame that Firefox Complete Themes haven't been salvaged, in CAA or elsewhere... If you are persistent, you may find some versions archived in the web archive and similar services... Specifically where FT DeepDark is concerned, its author (Stefano Rosselli, a Swiss) has attached a very limiting licence to it so, despite me having the XPI file saved on disk (from the era it was still on AMO), I'm not at liberty to redistribute myself... However, all hope is not lost for you:

... I took the test using Firefox ESR 52.9.1 (32-bit), and the pop-up with the error reported was also displayed at the end of the test execution: Given that the initial fork point of official UXP was Mozilla ESR 52.6.0 (the platform used in Mozilla Firefox 52.6.0 browser), an educated guess of mine would be that this is something Serpent 52 inherited all the way back from Mozilla ; at the same time, one may also claim that the "site" doesn't - by choice - support fully older desktop Firefox versions/engines ... At any rate, this is all probably a moot point , seeing that - as I can also confirm - by dismissing the pop-up, one can successfully get the final test score... I went as far as searching for the term "parent.RankDataLists", but nothing useful for debugging purposes showed up EDIT: ... Scratch that ; it's been reported that even Firefox 80 produces the same error pop-up ...

... Has been reported in the past, but in relation to Serpent 55 : ... BTW, not a fan of these benchmark sites myself, but whatever tickles your fancy...

TBH, I don't think Moonchild himself had anything to do with it; that was all pure/unadulterated M.A.T. , acting out of spite indiscriminately against forks run on NT < 6.1; proper branding was irrelevant at that point in time; and, of course it was intentional; M.A.T. claiming snarkily, quite proud of himself, on the afternoon of the 25th that https://forum.palemoon.org/viewtopic.php?p=197919#p197919 ... and some of his sidekicks in that same thread trying to prove the doubters are delusional... I'm happy for @letmeindude for standing up to the lot of them, and for doing major debugging of the issue (both in the PM forums and GitHub). As for a "reasonable explanation", don't expect one... I'll just refer you to what MC posted on the matter (link in my post just above yours...)

... Are you sure this is FULLY de-obfuscated? function displayContent() { if (X("0x3", "^Mn5") in navigator) { uaPrefix = navigator[X("0x10", "wOY$")] + "/5.0 (" + navigator[X("0x5", "&j9b")] + ";"; if (!navigator["userAgent"][X("0xf", "wkB!")](uaPrefix)) return; if (navigator[X("0x4", "G9*&")] && (navigator["oscpu"][X("0x8", "^Mn5")](X("0x9", "Puzb")) || navigator["oscpu"][X("0xe", "73(^")](X("0x11", "e6DU")) || navigator[X("0x0", "DLe0")][X("0x2", "fCh&")](X("0x6", "pseB")) || navigator["oscpu"][X("0xb", "k4n@")](X("0xc", "GBIt")))) return null } var ig = document["getElementById"](X("0x1", "6osW"))[X("0x7", "rMvY")][X("0x13", "czCY")](!![]); document[X("0x12", "&iPz")]["appendChild"](ig); document[X("0xa", "Y8yJ")]["id"] = X("0xd", "wOY$") } ... Though he doesn't acknowledge he had anything to do with their removal, Moonchild's account of things: https://forum.palemoon.org/viewtopic.php?p=198040#p198040 TL;DR 1. He pretty much (as expected) justifies M.A.T. because he was undeservedly banned from MSFN without notice, as being "a long-standing member with a good track record" () 2. Once again, fork users are being called "so selfish"... The whole affair boils down to two things, basically: 3. MONEY ; the addons infra is being maintained fiscally out of M.A.T.'s own pocket; supposedly, "freeloaders" such as the fork-users put a significant extra burden towards bandwidth consumption/server costs... Edit: Fork users, when using the default Search Engine, DDG, also contribute towards the official project by Moonchild, do they not? 4. Branding (and all related stuff discussed extensively elsewhere in these forums). NB: The term "out of spite" is never mentioned ... I must thank @siria for being the first person in these forums mentioning in the past this HIDDEN Firefox pref When SSUAOs for the add-on repos stopped working for me, but I could still access them in my sister's Win7 laptop inside the same WLAN, I became sure I smelled of fish ... I arrived to the conclusion he must be checking OS version by Javascript, so I remembered that pref and applied it independently on my own; I did not disclose this early on, fearing the involved person's unpredictability... general.oscpu.override changes the Javascript-detected OS version globally; you can read more about it here . However, I wanted something more elegant, that would only work on these two "affected" sites; since I have Greasemonkey for Pale Moon installed, I concocted the following userscript: // ==UserScript== // @name Fake 'navigator.oscpu' on PM & Bk add-on repos (25-08-2020) // @namespace VistaLover // @description Changes 'navigator.oscpu' on PM & Bk add-on repos // @include https://addons.palemoon.org/* // @include https://addons.basilisk-browser.org/* // @run-at document-start // @grant none // @version 1 // ==/UserScript== Object.defineProperty(navigator, 'oscpu', { value: 'Windows NT 6.3' }); Sharing it now for purely academic reasons, just in case... BTW, navigator.oscpu is a feature of only Firefox and friends, Chromium-based browsers don't (easily) divulge the OS version when queried by JS... So, one major crisis averted, I'm sure there'll be more coming...

... I, too, was using DNS Quad 9 Public servers (9.9.9.9,149.112.112.112) until I recently found out that Dropbox links weren't resolving , e.g. : https://www.dropbox.com/ https://dl.dropboxusercontent.com/s/7d47x36vuibc39h/palemoon.js ... so I went back to DNS Cloudflare Public (1.1.1.1,1.0.0.1) ... (OT: Using the very handy nirsoft utility QuickSetDNS v1.30 )

The block was originally implemented (no doubt by M.A.T. ) in the afternoon (my timezone, i.e. UTC+0300) of August 14th, 2020; it denies access to forum.palemoon.org by UAs containing the PaleMoon/28.10.1a1 slice ; that one was relevant to recent New Moon 28 builds prior to the latest one (which, at last, has 28.10.2a1 as appversion) : What is noteworthy is the nature of the error generated, which would have the uninitiated believe it was related to a genuine TLS connection/certificate issue ... On that day, @roytam1 "dared" to post in The Official Interlink Mail & News Discussion Thread : https://forum.palemoon.org/viewtopic.php?p=197174#p197174 which presumably tripped M.A.T. over: But the official forums do not only contain M.A.T.'s "board", who granted this individual God-like rights to ban online community content at a whim? <OT rant> I'm not a young person anymore, sadly, but I swear to all of you I hadn't come across, both in my whole real life and in my "digital" one (since ca. 2005...), such a mean-spirited, vindictive and petty individual, and this is also taking into account the latest unethical shenanigans... The great Albert Einstein might have said : ... but I must add a third one: human evilness Note to admins: As you all probably know by now, I have shown exemplary conduct in these forums; but this time I had to vent ; I apologise profusely and can only swear this won't happen again... </OT rant>

... He's using the WSUS (Windows Server Update Services) that comes with Windows Server 2008 R2 SP1 to access and download Win2k updates, not an actual Win2k installation... @max-h : Where can one find/install/configure a suitable version of WSUS on Vista SP2 itself (if at all possible...) ? Having an existing installation of WSUS on WS2008R2 as a means to fetch Vista updates isn't practical, to say the least...

2008 R2 is the Server side of Win7 (and plain 2008 is the Server side of Vista); both 2008+2008 R2 are still supported by WU/MU, thus WSUS, if the corresponding updates that bestow SHA-2 support are manually pre-installed... This isn't any news, is it? OTOH, you haven't responded with clarity to @Vistapocalypse's query: Have you recently tried WSUS on plain Vista (+SP2?) ??? M$ don't offer an official update that implements SHA-2 support to the OS, one may use the KB for 2008, but does WSUS really work on Vista SP2?

Hello I'm not a Discord user myself, so the report "this trick stopped working" doesn't provide, at least to me, any detail I could use to troubleshoot further... My original post you quoted was from 20 months ago so, yes, many things might've changed since then... First thing that stands out is the domain name change, discordapp.com -> discord.com Then, FirefoxESR 60 has been long EoS'ed by Mozilla, likewise Win7 has been EoS'ed by Microsoft... It is highly unlikely Discord have already removed support for Win7 (... but I'm sure they'll do so when paid by Microsoft, who push their spyware Win10 onto everything on-line...), but it's quite probable they've stopped supporting ESR 60; ESR 68 (now at version 68.11) is on the way out, so to speak, while the new ESR is 78; so, in August 2020, I'd use general.useragent.override.discord.com;Mozilla/5.0 (Windows NT 6.3; rv:78.0) Gecko/20100101 Firefox/78.0 How exactly is your Discord experience broken in @roytam1’s (latest) Basilisk forks (BTW, they're called Serpent; mentioning the official app name tends to upset people upstream... ) ? Please be specific... This is, of course, the place to post about Serpent (and friends); while letting us know that a different Basilisk fork works for you has importance on its own for the wider XP/Vista communities, it doesn't help to identify that specific "some reason" you wrote about, due to which Discord stopped working in Serpent; if we are to assume the breakage is due to Serpent code and not due to a change implemented recently by Discord, then you can at least perform some bisection to identify the LAST GOOD and the FIRST BAD Serpent builds where Discord is concerned; then it'd be fairly easy (usually...) to pinpoint the culprit change that caused the offending bug... Is the above used in Centaury? I see two issues with it, though... 1. %OS_SLICE% will reveal the actual OS you're running the browser on, and if that one is XP (Windows NT 5.1;), then you're more probable to get blocked by Discord... 2. Having different values for Mozilla Platform (Gecko) revision (rv:73.0) and Firefox version (69.0) is not standards compliant, so I'm really puzzled the whole UA string works for you (?) Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent FWIW, I have just created a temporary/guest account with Discord and having applied the SSUAO I posted above, I first see some GUI glitches in latest Serpent 52.9.0 32-bit: ... i.e. three vertical (empty) scrollbar placeholders display, while, IMO, they shouldn't (they don't show up in 360EE v12, Chromium 78 based...), but I can't tell anything more is broken, since I've never used Discord before...