VistaLover

However, clicking on the "Visit legacy store" area (JS-controlled button) will only start a vicious circle , resulting in that same "new CWS" page ... Well, it's March 1st in my timezone already , and the "in-page info banner" no longer offers the alternative of "visiting the legacy store" :

... I don't want to "burst your bubble" , but even if you manage to sort out all dependencies of the DLL under NT 5.1, the CDM will be practically non-functional on most popular DRM'ed services (e.g. Netflix, Amazon Prime, Hulu, Spotify, Apple Music, Tidal, etc.) ; since years now, Google (owners of Widevine CDM) have implemented the Verified Media Path (aka VMP) security feature: https://www.expressplay.com/products/google-widevine-drm/ In layman's terms, this means that the application within which the CDM is run (Supermium in your case) must've been previously whitelisted/sanctioned by Google ; this process involves acquiring special certificates from Google, for DRM purposes only, and signing various browser components (e.g. "chrome.dll") with said certificates; when the CDM is requesting decryption keys (aka "licence") from a Widevine lic server, it first sends (obfuscated) a payload with extreme detail of the environment it's currently running on; this detail includes exact browser specifics, as well as the OS/device the browser is running on; the WV lic server can reject the licence request if the CDM version/browser/OS/device is not to Google's liking; browser applications are being accepted if they have been signed with that special VMP certificate, and this fact limits the selection to ones offered by the major vendors, ONLY (Google Chrome/Mozilla Firefox and a few Chromium variants) ... Supermium hasn't been granted VMP compliance (being a one-man, open-source, project) and even if its author (win32) applied for such, it could well take several years for this to materialise, if at all ... In addition to VMP, you said you manually edited the DLL: This fact alone changes the CDM's hash value/invalidates its file signature (which is SHA-2, BTW, incompatible with XP) and when the CDM identifies itself to the WV lic servers (yes, it does send its hash inside that obfuscated payload I mentioned earlier), it "screams": "I've been tampered with, just ignore me", thus no decryption keys are delivered to it ... FYI, some Supermium issues relating to its DRM (Widevine) support: https://github.com/win32ss/supermium/issues/127 https://github.com/win32ss/supermium/issues/169 https://github.com/win32ss/supermium/issues/242 FWIW, Widevine related documentation used to be publicly accessible until a few years ago, when evil Google decided to put it behind corporate gmail accounts, for media-enterpises members only, who also have to sign strict NDAs ... At this point in time, it seems DRM-savvy private individuals are to be found only inside private discord servers, no more open to "outsiders"; I used to be part of such a server back in the day, but got kicked-out because I wasn't "active enough" (at least according to the server's owner ) ...

Fortunately, that one has been salvaged by crx4chrome : https://www.crx4chrome.com/crx/299038/

... With respect , you did not make an effort, it seems, to follow what I have already posted in a previous post ; whether a PDF on-line URI will generate a "Save As" file download prompt (case 1 in your previous post) or the PDF file will be auto-downloaded in the background and rendered+displayed inside the browser's Native PDF Viewer (case 2 in your previous post) is something beyond the user's (initial) control, in fact it's a server-side configuration: the PDF file on the hosting server has been configured with a content-disposition value, by the server admins... In case 2, the value is "inline"; this (alongside a suitable Content-Type header) instructs the browser to handle the PDF file "in-line", i.e display it inside a tab via the native viewer (or via a PDF reader plugin, where applicable); in case 1, the value is "attachment"; this instructs the browser to simply "download" the PDF file to disk, for storage. I have already mentioned an extension in my previous post which changes the "attachment" Content-Disposition value to "inline", but the problem with such an extension is it's not specific to PDF files; other types of files you may want to download to disk (e.g. images, audio, video, etc.) will attempt to be displayed directly in the browser (if the browser is able to render them natively); that's why I said I only enable that extension at will...

As an addendum to my previous post, Mozilla do host (on GitHub) "on-line" editions of their PDF.js lib, one targeting "current" browser engines: https://mozilla.github.io/pdf.js/web/viewer.html and another targeting "legacy" browser engines: https://mozilla.github.io/pdf.js/legacy/web/viewer.html Neither of the two works on Ch86/87-based browsers (and on St52) to display the "C0801E.pdf" file, https://mozilla.github.io/pdf.js/legacy/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf https://mozilla.github.io/pdf.js/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf while BOTH do when loaded in Ch121-based latest Supermium-v121-hf ... Yes, the browsers "we" use here are more "legacy" than what Mozilla even thought of ...

... Indeed ; as the web console portion of the first image I posted previously reveals, the "enganchesaragon.com" site are self-hosting v3.0.279 of the pdf.js library; according to the GitHub repo for it, tag 3.0.279 was cut on 2022-10-29 ; ... The library inside the latest Serpent 52 build is of version "1.7.348-git-754c4bd", committed on 2017-03-04, i.e. 5 1/2 yrs older (!) ... It would then seem that v3.0.279 (from 2022) requires platform features not fully compatible with UXP ... I'm uncertain as to how to proceed to find the version of the pdf.js (equivalent) lib inside 360EEv13.5 and/or KMB; Chrome 86 stable was released on 2020-10-06, 87 stable on 2020-11-17; Google probably don't use the same lib Mozilla maintain ; as discussion here has proved already, Ch86/87 (autumn of 2020) don't support the much "younger" Mozilla pdf.js v3.0.279, that came two years after those browsers were released... After my analysis, one "probable" answer why "enganchesaragon.com" choose to self-host an instance of the Mozilla PDF.js lib to display the PDF files "they" serve is: "They" prefer it over the native-PDF-viewer implementation on users' (mostly Chrome-based) browsers... Don't know what else to think of ...

... Couldn't agree more ; but, "no sense" is probably only "applicable" to frequenters of these threads, on "legacy" browser engines ; I can assure you that the web designers of that Spanish site did NOT, even for a mere second, think of "backwards compatibility" ; they're probably "trained" to expect each and every eventual user of their service to be running the latest Chrome/Firefox/Safari, where the original "issue" you reported (and generated many additional posts here) is simply non-existent - it works right away and the user "there" doesn't notice any issue; he/she just moves on with the browsing; the comparison between "sensical" and "non-sensical" never crosses his/her mind ... It is us here inside the MSFN "older OS" forums who harbour a mentality of being "the centre of the IT universe", whereas, in fact, we're just one dying old star which has practically extinguished all of its fusion-able material ...

OT ... I use a userstyle for that : @-moz-document domain("msfn.org") { body.ipsApp article.ipsComment div[data-quotedata*='roytam1'] div.cPost_contentWrap p { max-height: 300px !important; overflow-y: auto !important; } } ; I've named it: msfn.org @roytam1 "long" posts fix ...

... The "more" correct way to do it is: 1. click the code button (</>) in the MSFN editor toolbar 2. In the opened popup, change the code syntax to "Javascript" (bottom right) 3. Paste the code (you copied directly from TM) in the main box 4. Click the "Insert into post" blue button 5. (Optional) Preview your embedded code (far right button of the MSFN toolbar)

... Indeed (and pardon the slight OT ), the "online-PDF-viewer" URI: https://storage.enganchesaragon.com/public-websites/ecommerce/pdf_viewer/web/viewer.html?file=https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf does load in last week's Serpent 52, but the pages are rendered blank there : If one downloads directly the PDF file via: https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf (it's 10.4 MiB in size) and then tries to view it in St52, all's fine : Yes, the PDF file specs have evolved over time and full backwards-compatibility isn't guaranteed ; the file in question is of version 1.7 and I had better luck than you in that it opened in my Adobe Reader X (aka 10) copy: Though, do note that it is stated in the above screenshot that PDF v1.7 should be compatible with Adobe Reader/Acrobat 8.0+, so there may be something off in your case ...

That's how I've been doing it so far. But I thought it might be easy to get around this. One other approach I use myself is to let the browser handle itself the online PDF files (without a prior download to disk and then drag-n-drop ) and display them via its native PDF viewer; however, in the case discussed, https://storage.enganchesaragon.com/public-websites/ecommerce/Inst/C0801E.pdf the file has an "attachment" content-disposition and loading that URI will generate a "Save File" download prompt; that's why I have also installed: https://chromewebstore.google.com/detail/undisposition-racle-fork/bbppejejjfancffmhncgkhjdaikdgagc and I enable it as needed - you want the older v0.0.4, which is still at MV2, for 360EE... Below is KafanMiniBrowser loading the referenced PDF URI in its default viewer, via "undisposition" extension :

... This is probably just a simple oversight , but these two packages are being served through plain HTTP, while the page they're on (MSFN) is served through HTTPS ; recent Chromium versions block by default such scenarios as "mixed-content" and won't let you download the files out-of-the-box (a security warning is issued, can be ignored/overridden at user's discretion); I experienced this myself as I was testing latest Supermium-v121-hf-x86 on those links... Not a big thing , but perhaps the links could be edited to HTTPS, too (as are all the links to the rest of this weekend's packages ) ... Many thanks!

Interested members can find needed files on SourceForge: https://sourceforge.net/projects/winscp/files/WinSCP/6.1.2/ The "WinSCP-6.1.2-Portable.zip" is the one you need under WinXP (unpack and launch the .exe file); the problem arises if you want the app localised , because that zip archive ONLY comes with the default, en-US, locale (embedded into the .exe) . The installer, "WinSCP-6.1.2-Setup.exe" comes with multi-language support, but it's built with an InnoSetup version that requires at least Win7 . To get the localisation files out of it you need use a tool capable of extracting Innosetup installers; my two "loved-ones" are just CLIs, innounp (at v0.50) and innoextract (at v1.9) ; however, if you are a GUI type, you can use the much larger app UniExtract2, which contains those two above CLIs as internal components (this extracting "suite" has been mentioned and linked before by AstroSkipper). Once you have successfully unpacked "WinSCP-6.1.2-Setup.exe", you should have access to a "Translations" dir, with numerous "WinSCP.*" files; pick the one that has a file extension denoting your desired locale (e.g., for German it should be "WinSCP.de") and place that adjacent to the WinSCP.exe main executable inside your originally unzipped "portable" archive; launch the app (it'll still be in English) and through the app's configuration (Options -> Preferences -> Environment -> Languages) you can now select your preferred locale: An app restart is then required for the change to take effect ... If you don't mind your "portable" app being in the much acclaimed PAF format, the people over at "portableapps.com" have prepared a "special package just for XP users", who have now been deprived of future WinSCP updates: https://sourceforge.net/projects/portableapps/files/WinSCP Portable/WinSCPPortableLegacyWinXP_6.1.2.paf.exe/download That package has all available localisation embedded ... PS (and OT): This time, the WinSCP devs did not put Vista SP2 32-bit in the same boat as WinXP - the latest release as of writing this, 6.3.1, again via the "portable" distribution, launches and runs fine there () ... Just as a FYI...

... Yes, thanks, this solution was already pointed to inside Sm's GitHub issue tracker some 6 weeks ago : https://github.com/win32ss/supermium/issues/134#issuecomment-1883249689

Exactly! "20220812" is the buildID of the 32-bit, xpmod (i.e. capable of SSE2+), build; buildID is listed inside "about:" and "about:support" ; the corresponding "released" package should be the one with a close "git-date", most probably: palemoon-27.10.0.win32-git-20220813-042db568fd-xpmod.7z

... Well, Win7 is certainly "On Topic" here, because the roytam1 forks (browsers and other apps) do work under that OS; after all, despite its users not wanting to admit it, Win7 is by now an "Older NT-Family OS" ... However, and this is just me , "extensive" references to the Chromium forks (compatible with said "older NT-family OSes") should be better posted in the dedicated threads (we have enough already...) ; I don't exclude myself here , I've often fallen foul of this before ...

@Jody Thornton : No worries, we're good ... You're right, nobody "twists my arm" to make long-winded posts here, but in your case I did provide replies to your queries because I thought you deserved the replies - also, this is material that, no doubt, will be of interest to other members here (and see, roytam1 pinned it to the start of this thread) ... A correction on a technicality there: "official" Pale Moon 27 had native support for Vista (the 64-bit variant had some glitches with media playback - only recalling from memory, because my Vista OS is 32-bit), so NM27 by roytam1 only had to re-instate WinXP support ... ... Tell me about it ... Old(er) age is a b*tch ... ... Neither do I, but I'm the type of person that first reads the toaster's manual (if it comes with one ), and only then do I plug it to the mains; do you get my drift? ... well, sorry to say it, but you didn't look well : Linked Answer: https://msfn.org/board/topic/182647-my-browser-builds-part-3/?do=findComment&comment=1199724 If I'm being asked (once) again , the decision back then was made based on uncertainty on how several, then popular, Firefox extensions would behave under an application with version 29.0+; it was a time when "upstream" (spearheaded by M.A.T.) wanted to completely remove ALL support for Firefox-specific extensions and move solely to PM targeting ones (in fact, they did do that for a while, didn't they?) ... The transition from v28.x to v29.x was crucial for Mozilla Firefox, because Fx-29.0 came with radical internal and external changes, collectively known as Australis (which, contrary to public belief, wasn't just a change in GUI); many Firefox extensions of that era, to keep backwards compatibility, had different sets of internal code to cater to Fx <=28 and Fx >=29 at the same time, so using such an extension on NM29 (with a Fx-28 type of GUI/engine) was just asking for trouble...

Greetings ; what do you mean by "still" ? Was it working in UXP-based browsers and then stopped? How long ago was that? Have you already reported that breakage in the past and you now feel disgruntled the issue remains unresolved? Please be aware that UXP, as a platform, is not very good at supporting these so-called web (in-browser) editions of popular chat/messaging applications, which are usually optimised for recent Chromium-based browsers (or just for the browsers on your mobile device ) ... Such web-compat issues are usually for "upstream" (MCP) to address, but if one asks "there", the standard answer from "them" is: "Use the dedicated Windows application"; this is, of course, no consolation for XP/Vista users, because most of these apps now require at minimum Win7 (soon to be Win10 ?) ... Searching in the PMForums, someone there suggested using a "legacy" URI of the form: https://web.telegram.org/?legacy=1#/login , does it still work on you for log-in purposes? ... In my "dirty" St52 profile, all I get is a white/empty page inside a thin-lined black frame , much like what @mina7601 has already posted... It would appear the most important clue inside the Web Console simply eluded you ; the page deploys a script which performs browser-feature checks: https://web.telegram.org/a/compatTest.js UXP then fails those tests , because it doesn't, yet, support "Intl.DisplayNames", a JS feature which was first implemented in Fx-86/Ch-81: It just so happened that "upstream" (MCP) have opened a UXP issue for that just 6 days ago, but so far it hasn't received any activity ... A polyfill for that missing function already exists ; my JS-coding skills are non-existent , but I tried to make a userscript out of it (and inject it through Violentmonkey), problem being the script gets quite large when you add all the needed "locale.data" ... Another issue is that, during my tests, I discovered that for the userscript to work on "telegram.org", one has to globally disable CSP protection in the browser, which. in itself, is a security risk ... FWIW, with my basic "polyfill-as-userscript" and CSP (temporarily) disabled (security.csp.enable;false), the offending web page finally loads: I don't own a mobile device (yet anyway , by my government has other "plans" for its subordinates ), nor do I have an account with Telegram, so my experiments ended just there ... Kind regards.

Hi again ; I can't see myself how that could've helped , because Fx-120.0 is incapable of running under NT 5.2 (Windows Server 2003 x86 ?); with the above UA, you're just "sticking out like a sore thumb" ; still, stranger things have happened in the world of IT... Also, if elektroda are adamant on supporting only the latest Mozilla Firefox version, pretty soon you'll have to spoof Fx-123.0 ... ... And you're most welcome ...

Like you, I do agree that Adobe Flash Player, despite being closed-source, was a good technology for its time and served well XP/Vista users running the OS under era-correct H/W; it came embedded with patented decoders and worked quite well with most GPUs of the era... But it wasn't deprecated due to "Adobe's incompetence", nor was this related to just Google pushing their ways... FWIW, a localised version of Flash is still being used in mainland China, maintained by a Chinese Adobe affiliate... As Microsoft moved away from XP (and Vista) and introduced new media playback technologies inside the Windows OS itself (e.g. Windows Media Foundation, WMF, which matured in Win7), and with newer WinOSes requiring more "advanced" H/W (GPUs/CPUs/RAM) to run properly (but through which, higher-spec'ed, H/W native playback becomes "attractive"), browser vendors saw it proper to move away from NPAPI/PPAPI Flash into HTML5 native playback, inside the browser; Adobe Flash had been notorious for many serious vulnerabilities during its lifetime, so for many computer users the deprecation of Flash was a blessing in disguise... Google was not the only browser vendor in favour of the migration, in fact Apple had a bigger role in this ... I can understand, though, that the deprecation of Flash and the general move to HTML5 media playback has left XP users on older/under-resourced H/W at an impaired/handicapped state.... But when I talked about the "Googl-isation" of the web, I did not have the deprecation of Flash (and NPAPI in general) in mind; I meant the current trend of Google web devs constantly "devising" new "dialects" of the Javascript programming language and them, via their undisputed dominance on everything-web, leveraging these new JS iterations into the web standards; these, even when still at "draft" status, are pushed to the newer Google Chrome releases and, as a result, become also adopted by the web-frameworks that are part of most contemporary web sites; sites that, unlike the good times of the past, aren't just comprised of pure HTML pages, but are instead monstrous blobs of JS+CSS code that has to be downloaded and rendered locally by the browser engine, putting a heavy tax on your H/W... Thus, Google make sure that "the web" will break on other "legacy" web engines and also make sure that "the web" will underperform on your older H/W - IOW, "they" try their best to make your old "setup" practically no longer capable of any more use ... People who follow me here know that I'm not a coder/web developer, so it's possible some of my wording above was not well chosen; but I'm sure you all get the gist of it ...

Dear Jody, and I mean this in a genuine way , you of all people shouldn't come back with the very same queries, because it was I who answered your similar queries in the not so distant past... What it all comes down to is: 1. do you have a grasp of what open source code is? 2. do you have a grasp of what a forked open-source code repo is? 3. do you have a grasp of what a platform and an application built on it is? If not, any answer you'll get from me won't make much sense to you, and I'm sorry to say that there's no simplistic yes/no answer to your re-iterated queries above... MCP maintain the official UXP application platform, its repo is hosted below in: https://repo.palemoon.org/MoonchildProductions/UXP/ There are several branches in that repo, main ones being master and release MCP maintain the official Pale Moon browser application, its repo is hosted in: https://repo.palemoon.org/MoonchildProductions/Pale-Moon/ Again, the two more important branches in that tree are master and release The official Pale Moon releases are being issued at least once a month, compiled from code from the UXP release platform branch and PM release application branch. Likewise, Basilisk-Dev maintains the official Basilisk browser application, its repo hosted in: https://repo.palemoon.org/Basilisk-Dev/Basilisk/ Two branches of note there, too; master and release The official Basilisk releases are being issued monthly, or as the dev's time permits, compiled from code from the UXP release platform branch (by MCP) and the Bk release application branch. OTOH, roytam1 maintains a somewhat different development scheme; he maintains a code "smorgasbord" below: https://github.com/roytam1/UXP This is a fork of the official UXP platform repo (see above); the tracking branch of that repo follows more closely the master branch of the official UXP platform (see above); the forked UXP repo, by now, is different to the original one in various ways, one of which is in restoring WinXP+Vista support (which also entails several lib differences, like in ffvpx), another one is keeping Mozilla features MCP have dumped long ago (e.g. Web Extensions, Tab Containers, half-baked e10s code, EME, e.a); also, the NSS lib in "our" browsers is somewhat different to the one MCP maintain; that is why profiles between the official apps and roytam1 apps aren't 100% interchangeable... The UXP repo by roytam1 also encompasses application-specific code, ported from the official PM master branch and the official Bk master branch, again chosen selectively (i.e. not all Pale Moon features end up in NM28, not all Bk features end up in St52, but most do). The custom branch of roytam1's UXP repo holds the code snapshots that get compiled weekly to produce the NM28 and St52 releases; if you're still following: It's difficult to directly compare the official releases to the roytam1 ones, because the first follow a different code development scheme + release schedules, but indeed all the vital code parts (features, bug/security fixes, etc) from the former find their way to the latter, sooner or later... As a rule, based on what I detailed above, the "latest NM28 release" should contain all the "applicable" platform/app code found in the last PM release, and then some (i.e. code in the official master branches authored after the release was cut) ; likewise, the "latest St52 release" should contain all the "applicable" platform/app code found in the last Bk release, and then some (i.e. code in the official master branches committed after the release was cut - on that note, it's sad that Basilisk-Dev has admitted elsewhere that he's withholding on purpose to publish Bk code in its master branch until "the very last moment", so that "we" here be incapable of using it "ahead of time"...). The only exception to the above is when "upstream" collectively (MCP/Basilisk-Dev) make a "mid-week release"; in that case, the builds released by roytam1 on the Saturday that immediately follows those mid-week upstream releases will have "caught up with them", so to speak... Jody and others, please bookmark this post and revisit it as needed, so that I don't get asked the same things again and again - and no, one "can't have one's cake and eat it, too"; if one wants to keep using "these" browsers, one must also "keep in touch" with how things are developing "here" ; the issue of "precious personal time" has come up many a times in the past, but be sure I'm just a volunteer here, my personal time is as precious (to me) as is yours... PS: Changelogs are NOT confusing, if one ever made a simple effort to understand what they do represent; they're made of git-commits between the previous and the current release, often times they're identical to the "upstream" commits they were ported from; so one can easily verify how far ahead of (or behind of or different to) the upstream code the current release happens to be...

These come via the platform (UXP) "updates" and are being implemented (when possible) by MCP himself (who has private access to them through Mozilla); if they're uploaded to the official UXP repo, then sure they'll be integrated/backported to Roy's fork of UXP (off-the-top-of-my-head, last summer's webp vulnerability was also patched "here"); be advised that a large number of Firefox "security fixes" involve e10s, as that isn't implemented in UXP, they won't make it onto "our" browsers... ... Tsk, bad on you, dear friend ... Best wishes

FWIW, there's nothing "standard" about NM27 here ; to add to what Mathwiz has posted: "Pale Moon" is an upstream browser application, which has a GUI from the pre-Australis Fx era; also, members here must understand the distinction between platform and application (Mozilla are the ones to blame for this confusion, because they had equated the Mozilla platform, not used solely by Fx, to their main browser, Firefox) ... When PM was at its major version 27 (did not support XP, Vista support was rudimentary), the platform it was built on was called Tycho, a fork of the Mozilla ESR 38 platform - the browser engine of PM27 was called Goanna version 3. The roytam1 fork derived from PM27 was/is New Moon 27 (NM27) ; as the web became more-and-more Googl-ised , PM27/Tycho started being crippled at loading many popular sites, so "upstream" (MCP) abandoned the Tycho platform and moved on, first to UXP Take 1 (aka Moebius), forked from a Mozilla 53.0a1 platform snapshot, and soon after to UXP Take 2 (just UXP now), forked from Mozilla ESR 52[.6] platform; PM27 became PM28; Pale Moon is currently at v33.0, but it's still built on UXP; both the paltform (UXP) and the browser application (PM) are being developed independently from Mozilla/Firefox... When upstream (MCP) abandoned Tycho (and PM27), roytam1 chose to keep his forked platform and browser (NM27) for the sake of Win2k/XP users on very old H/W, that doesn't support the SSE2+ instruction set ; as of this writing, NM27 and its browser engine, Goanna 3, is being "updated" based on a new "upstream", the developer (rmottola) behind the Artic-Fox project; this project aims to develop a (semi-)usable browser on old Macs, unsupported by Apple and the mainstream browser vendors; the project strives to "uplift" the browser from a Mozilla 38 platform snapshot (like in PM27/Tycho) to more recent versions, hence the large number of weekly updates (there's a lot of catching-up to do when you're still at a Fx mid-40s level) ... Also, Arctic-Fox isn't New Moon 27, hence several bugs that plague the latter are being reported by (the few?) NM27 users... To put it bluntly, I have now no need for this fork, because its web-compatibility is severely impaired in 2024; in addition to that, Roy is publishing SSE-compatible builds of NM28+St52, so if your old H/W can cope, it's advisable you use these instead of NM27... NM27 has inherited from PM27 a "status-4-ever" internal component, but as the platform is being updated by rmottola to Fx43+, this component has been partially BROKEN, breaking with it several download-related functions/extensions/userstyles/userscripts etc.; I have kept, for archival purposes, a NM27 build from 20220812, which seems to be the last with no such issues... As for NM28 (and St52), this is being updated mostly by backporting MCP code, especially in the platform aspect of it, and occasionally PM-specific (and Bk-specific) code is also being backported; and don't let the appVersion (28) confuse you ; Roy, for reasons he has explained in the past, decided to "freeze" the major version at 28, but latest NM28 embeds platform code to be found even in the latest PM33 "official" release ...

... So, you used the Fx-120 based one; try to use as value of "general.useragent.override.elektroda.pl" just "Chrome" (without the " ") and report back ...

... Which SSUAO value did you in fact use there? Was it the Fx-120 one or the "just Chrome" one ? In any case, being able to use that bloated (if I may say so ) portal for several hours is still better than not being able to even access it at all ... I don't have an account there, so it's just impossible for me to further troubleshoot ... It's possible they're (still) doing some form of fingerprinting once every several hours and then you're kicked out ... If I had to bet some money , I'd say evil CloudFlare is behind all of this... Kind regards.