Jump to content

VistaLover

Member
  • Posts

    2,253
  • Joined

  • Last visited

  • Days Won

    93
  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by VistaLover

  1. Hello ; do you think https://repo.palemoon.org/MoonchildProductions/UXP/commit/e4643f5bed2cdc600fc29900fe3b4d22e25763bc is the culprit, hence you did this: https://github.com/roytam1/basilisk55/commit/9bd1d38f77d2c01548f8802c369368e68ca08911 ? I'm no coder myself (everyone here knows that ) , but I had more time now to study Mathwiz's report, specifically: The issue is specific to the native downloader and the "open file" function - the file here being an "installer" binary which needs to be executed by the browser; the 7-zip installer comes in two varieties, EXE & MSI, so it would be helpful to clarify which - in any case, my own eyes fell on this: https://repo.palemoon.org/MoonchildProductions/UXP/commit/98c3aa57431c4b158c750dfabfd0ab90708ebf16 which you ported both to UXP and Bk55 trees: https://github.com/roytam1/UXP/commit/74a4260ecd6b6e6f40d48d4b181e34127487532b https://github.com/roytam1/basilisk55/commit/a406edc82008cf5b4fba914b73929a9933065319 Both of these first landed on the 2023/10/28 respective releases ... Speaking purely for myself , I think it's a bad practice to let the browser run executables; if it's installer packages, I strongly prefer to first "properly" download to disk and then archive them; many a times I've been bitten by a new application "update" that broke things for me and had to restore the previous version via its archived setup (often times no longer retrievable from the vendor); as for the actual installation step, I tend to exit all not-needed apps (including browsers) and then manually launch the setup - perhaps I interpret the "law" very "strictly" ...
  2. ... You're welcome ; à propos, you may want to correct that double negative there , else one may assume you do use Vista (joking, ofc) :
  3. ... This is not a correct assumption , and I think I have mentioned this issue in passing in the past, possibly in another thread (that I'm too lazy now to dig up ); the implementation by cmalex (ProxyMII_v230813) employs a specially crafted/patched edition of CPython 3.7.11 (based on the initial 3.7.1-XP implementation by Dibya), which runs specifically only under WinXP SP3 x86; when the python37.exe binary is launched under Vista SP2 x86, it throws function errors: The DLLs enclosed inside the red rectangles are foreign to Vista and are, in fact, loans from OneCore API, Wine and/or ReactOS projects, while several DLLs/EXEs inside the "python" directory have been HexEdited to point to these DLLs, which, in essence, port some NT 6.0+ kernel functions to XP SP3 (see some analysis here) ... OTOH, default CPython 3.7 x86 (as distributed by the PSF) can run natively under Vista SP2 (but NOT under XP SP3), being, sadly, the last CPython version that works there; default CPython 3.8 requires Win7+, default CPython 3.9 requires Win8.1+, etc. ... Hope it's clearer now (... and since this is an "XP audience" thread , I didn't want to share additional "Vista-details" here, but since you brought it up, I indulged ) ... Happy Thursday evening to you!
  4. As a FYI , even when using very recent versions of ProxHTTPSProxy, several fields in the https://browserleaks.com/tls detection page apparently don't work with the IEx severely outdated Javascript engine ; I have developed a Vista SP2 x86 targeting edition of ProxyMII (based on the original work by cmalex ), which uses: ProxHTTPSProxyMII-v1.5 (python script) CPython-3.7.17 x86 (EoS for py3.7) cffi-1.15.1 (EoS for py3.7) colorama-0.4.6 cryptography-41.0.5 pyOpenSSL-23.3.0 PySocks-1.7.1 urllib3-1.26.18 (script incompatible with urllib3 >=2.0.0a1) and when IE9 is configured to use it, the sections Protocol Support, Mixed Content Test and TLS Fingerprint remain empty: Best regards
  5. Greetings ; IMHO, it'd have been a service to this community if you had actually named that "streaming service" for which Mypal68 doesn't work, because you would've saved some other MSFN members the "hassle" you yourself went into ... According to my own investigations, the more prevalent audio streaming services (Spotify, Apple Music, Tidal, Amazon Music) use in-browser DRM (largely Google's WidevineCDM), with the notable exceptions of Youtube Music and deezer (those two use different methods for protecting their audio streams ) ; I'm not very familiar with the codebase of Mypal68, but AFAIAA it doesn't support DRM; even if it did inherit the DRM support extant inside Mozilla Firefox 68, its initial fork point, the Widevine version supported by Fx68 has been long deprecated/blacklisted by Google and their WV licence servers - besides, Google make sure their blackboxed Widevine DLL only runs on Win7 SP1+; and even Win7 is going to be deprecated by Widevine, once Fx115esr reaches its EoS ... As for AstroSkipper , I'm absolutely confident he double- and triple-checked those links at the time his post went live, because that's how much meticulous he is on such matters - it would be unrealistic to expect of him to (occasionally) check the validity of the links post-submission and, indeed, the fact they were removed by Mypal68's author soon after was quite unexpected, TBH ...
  6. You're welcome ... How so? Aren't you subscribed to this thread? That was my gut feeling, thanks for the confirmation ... The first, older, pref "security.fileuri.strict_origin_policy" was inherited by UXP from Mozilla ESR 52; the second one you cited, "security.fileuri.unique_origin" is a newer one, implemented by MCP in 2019: https://repo.palemoon.org/MoonchildProductions/UXP/commit/33b6f178d16f94df7de98d1316f563f14a2bedd5 with a clarifying comment written in: https://repo.palemoon.org/MoonchildProductions/UXP/commit/408ca49a029efa54d18234288c04944d2905fecb The original PR#1196 that implemented this pref has, apparently, been lost now, amidst their migration from GitHub to Gitea ... It is my conviction that MCP tried to replicate Bugzilla #1500453->#1558299 of that same period, although Mozilla chose a different name ("privacy.file_unique_origin") for the pref: https://hg.mozilla.org/mozilla-central/rev/2ad059cc9e78 That Bugzilla entry aimed to patch CVE-2019-11730 , but the default pref value there was "privacy.file.unique_origin;false", whereas in UXP it's "security.fileuri.unique_origin;true"; I'm not an expert on security, nor a coder, so can't advise you which of the two UXP "security.fileuri.*" prefs to toggle for your use case; from the Pale Moon v28.6.1 Release Notes: so I tend to think toggling only that newer, second, one might be preferable; toggling any of the two (permanently) lowers your browser security; a Mozilla expert advises to create a separate browser profile exclusively for such use cases ; in conclusion, Mozilla have removed "privacy.file.unique_origin" in Fx95+ and "security.fileuri.strict_origin_policy" is also to be axed (if not already); another case of them "foolproofing" their browser, in their effort to save their users from self-harm ...
  7. @roytam1 : This week, upstream have merged some additional "aspects" of UXP#2346 ; since we've kept EME in our tree, am I right to assume those upstream commits should be exempted from merging? FWIW, some few sites do still use ClearKey (soft) encryption, also part of EME; some other sites delivering both Clear and DRM'd media content would not load at all if they sniff out the browser doesn't support EME/DRM; so, even if used solely as an indication of "sites-requiring-Widevine", I still feel keeping the (mostly broken) DRM implementation in Serpent 52 is a "good" thing... Also, UXP#2281 is being pushed; will that impact buildability/NT<6.1 compatibility for "you"? Thanks for your stupendous efforts ...
  8. Actually, something relevant was discussed a few pages back: It loads without "an actual web server", if file "Lights.html" is drag-n-dropped on a Serpent 52 New Tab, provided you temporarily disable (from true to false) "security.fileuri.strict_origin_policy" pref: I don't have HTTrack installed here, so can't test now on your behalf ...
  9. ... QT Player v7.7.9 (file version 7.79.80.95) for Windows is the last one Apple released for installation under Vista SP2/Windows 7 SP1; the EXE setup has a SHA1 digital signature from way back in Dec 16th, 2015, so quite outdated ; that same installer won't even work on Win10+, unless you hack it yourself ... Since the recent discussion here was about the QT browser plugin, even that isn't installed by default: My Serpent 52.9.0 copy does pick up the QT-v7.7.9 browser plugins under both "about:addons => Plugins" and "about:plugins", but, since I have now no actual use for it inside my browser (for online content), I have it permanently disabled ...
  10. ... We're again steadily drifting off-topic , but, e.g., https://www.nbcnews.com/tech/elon-musks-business-ties-china-draw-scrutiny-twitter-purchase-rcna26057 https://www.nytimes.com/2022/04/29/technology/elon-musk-china-tesla.html @mina7601 : Are you into world politics at all (given your young age) ? Greetings ...
  11. In latest Serpent 52, I didn't have to toggle that pref to enable successful loading+rendering of either https://www.elektroda.pl/ (Polish version) or https://www.elektroda.com/ (English version); creating SSUAOs for both domains, impersonating the latest FxESR, did the trick for me : general.useragent.override.elektroda.pl;Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 general.useragent.override.elektroda.com;Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 Seems like another case of their UA-sniffing scripts rejecting "unfamiliar" slices ... Best greetings !
  12. FWIW, the same stands true for pre-Quantum Firefox Complete Themes, too : https://github.com/JustOff/ca-archive/issues/28 https://github.com/JustOff/ca-archive/issues/63 and some later comments on the matter: https://github.com/JustOff/ca-archive/issues/58#issuecomment-1278351039 https://github.com/JustOff/ca-archive/issues/58#issuecomment-1283141327 FWIW, I've never been a "persona" person myself (pun intended ), but had since the very start opted for Complete Themes - Mozilla hunt them down even before they removed the "legacy" lightweight ones; at first, personas were dubbed "themes", whereas the real "themes" were dubbed "Complete Themes" and made harder to locate on AMO; ultimately, Complete Theme authors practically gave up even before the advent of Quantum, because every newer Fx release broke, in several ways, the latest (complete) theme version, which then had to be reworked extensively to remedy the Mozilla inflicted breakage ...
  13. Hello there ; I became aware a while ago via this reference below (in another forum thread ) : ... and I can still verify this today: Can a member of the mod team kindly share some additional info with regards to this decision? Is it something temporary and if yes, how long will this measure last for? I'm not that preoccupied myself though , if anything, it'll stop "persons" from further "cloning" their MSFN accounts (you know, those ones that many existing members - including me - are convinced they exist, but no-one, including the mods, can, beyond doubt, prove they belong to the same physical person ), still it'd be welcome if some clarification on its implementation was communicated to plain members... Kindest regards (BTW, Happy Halloween to those that observe it!) .
  14. Greetings ; back in the glorious days of "proper" Mozilla Firefox, one of your compatriots had created the stupendous extension called "Add to Search Bar": https://firefox.maltekraus.de/extensions/add-to-search-bar The extension's XPI file (last version for Serpent 52 is 2.9) can be found inside the CAA ; since years ago, I had created myself specific MSFN Forums search engines via that nice extension - e.g. for this very forum: A popup appears, where you have to approve or edit the proposed SE name (and optionally add a keyword for that engine): and then you have your new MSFN SE: Best regards.
  15. https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID "Upstream" just implemented this natively in UXP: https://repo.palemoon.org/MoonchildProductions/UXP/commit/3d92b8212595769c40da7ccfbafb3898cfaaf7bd Thanks @basilisk-dev ...
  16. OT: I seriously doubt that Firefox Nightly 117.0a1 build you reference has the "WebP patch"; https://thehackernews.com/2023/09/mozilla-rushes-to-patch-webp-critical.html CVE-2023-4863 landed on Mozilla Firefox 117.0.1, this is the stable/release channel of the browser, coming after initial stable release 117.0; 117.0.1 was what's "affectionately" called by Mozilla a "chemspill" release, https://wiki.mozilla.org/Release_Management/Chemspill i.e. the patch wasn't extant in the "upper" unstable channels (beta/dev, nightly) when it was first applied in their trees; at the time Fx stable was on v117.0, beta/dev was on v118.0b and nightly was on v119.0a1 - too late for deprecated 117.0a1 builds, which had served their purpose when the WebP vulnerability was made public... Last moment (before submission) addition: I located the post you mentioned: https://msfn.org/board/topic/185870-i-found-the-latest-build-of-firefox-nightly-that-works-on-windows-7/?do=findComment&comment=1253973 If you notice the Mozilla FTP link contained there, the Nightly 117.0a1 build you talked about has a build date of 2023-07-14, thus it doesn't contain the WebP fix, which was only applied on 2023-09-12 (two months after that build was compiled+uploaded) ...
  17. Personally, I avoid Discord with a passion, because it really is unsuitable for old/under-resourced H/W like the one I'm currently on ... Additionally, all these Chrome-targeting chat services run sub-optimally on UXP, even on recent/supported H/W... Your main query has been answered here many a times, and (besides Discord) also encompasses similar services - Discord uses WebRTC for its audio and/or video features: https://sukhadanand.medium.com/how-does-discord-scale-to-5-million-concurrent-users-ed0874063fd but WebRTC, since the very beginning, was never supported by upstream in their PM browser (the same stands true for NM28); Serpent 52/55 do come with WebRTC enabled but, the last time I heard, their implementation is still eons behind the current iteration Discord etc. feel comfortable with... TL;DR: Discord are right from the start: Unsupported browser (you can still use text-based functionality, though) ... Since you appear to be on Win11, plenty of "workarounds" are available to you, just not for a UXP-based browser...
  18. ... That same question was already raised: I suspect it'd be difficult to find one which uses the exact code US bank "chase.com" uses; in the upstream forum, they have several members who are Chase customers, but the @Mathwiz solution has already made it there ; obviously, for a native UXP implementation, either here or by MCP, a dev must be granted access to a chase.com account (perhaps someone in the US can open an "empty" such account for the purposes of this WebCompat issue ), if "no-login" alternatives aren't found in the near future...
  19. ... I get you , but... At least the ones containing polyfill code aim to implement JS features not natively present in "the browsers able to run on older Windows NT-Family OSes"; for the rest of those userscripts (e.g. the youtube ones I posted two years ago ), I'd claim that even the Windows XP subforum isn't a suitable "place"; perhaps start a new thread inside this very subforum with just the polyfill-based userscripts? In any case, it's not up to me to decide if/where that topic gets transferred to - I just wanted to emphasise my observation/point that those userscripts aren't exclusive to Windows XP ...
  20. Pity that the "topic" is inside the Windows XP subforum ; IMHO, it should be transferred to the "Browsers working on Older NT-Family OSes" subforum (where this very thread resides ); but I know, I'm just a minority Vista user myself ...
  21. IIANM, structuredClone() has been already implemented in UXP in the recent past, https://repo.palemoon.org/MoonchildProductions/UXP/issues/2197 so, perhaps, @Mathwiz stands a good chance of having chase.com (after signing-in) work in latest Serpent 52 and/or NM28 ...
  22. Try these links, from their SourceForge mirror: 64-bit: GoogleChromePortable64_98.0.4758.102_online.paf.exe GoogleChromePortable64_99.0.4844.84_online.paf.exe 32-bit: GoogleChromePortable_98.0.4758.102_online.paf.exe GoogleChromePortable_99.0.4844.84_online.paf.exe As you might be already aware by now , these online installers need to fetch stuff from Google servers, but versions 98/99 are relatively recent to have been wiped out from Google CDNs... Regards .
  23. In the case of GitHub, and I'm talking here strictly about a dark vs light theme, not the new "Global Navigation Update ", they respect the browser's default/custom setting (provided the browser has such a setting) with regards to anonymous visitors. In Serpent 52, that setting is: browser.display.prefers_color_scheme and when left to its default value of 1, GH will serve their Light Theme to (anonymous) visitors; change that pref to a value of 2 and they'll serve their Dark Theme... A signed-in GH member can control the type of Theme served via custom "Appearance" settings inside his GH profile, where more than two Theme selections are offered, and can thus override the aforementioned browser setting... In contrast to GitHub, GitLab only offer their anonymous visitors a Light Theme variant (see my previous post); to change that, you'd have to sign-in ...
  24. It's worse than that ; the sign-out option (not a button anymore, either ) is tucked away inside one's "avatar" menu, which now opens as a right sidebar: OT : On the 360EEv13+ variants (which have better support for GH compared to current UXP-based browsers), my "avatar menu", instead of opening as a right sidebar, travels all the way to the left and displays as a left sidebar; this is annoying, because I then have to move the mouse cursor towards the left (vertical) tab border to access that menu's entries ; can others reproduce? A fix for that would be most welcome! Yes, most sites (including GH) want you permanently signed-in, so that they would track/monitor you more efficiently ... I do spend a lot of online time on various GH pages and need to use members-only features (e.g. comment on issue trackers, react to comments, download GitHub Actions artifacts, etc.), and what with the "hoops" of signing-out and then signing back in (especially when your ISP has "given" you a new dynamic IP address in the interim ), I tend to stay mostly logged-in and protect those signed-in GitHub cookies in my browser profile via a dedicated extension... BTW, GitLab also serve different CSS files to anonymous visitors Vs logged-in members: Signed-out: Signed-in (dark theme offered/selected): You are shown the "default" vendor selection for a said site permission when the "Use Default" square has been ticked; e.g., for "Access Your Location", the default permission is "Always Ask" (and that default is again stored inside permissions.sqlite); if the user unticks the "Use Default" box, then he/she(/they-them ) can choose one of the two other (non-default) available selections (i.e. Allow/Block), which are now non-greyed-out; finally, ticking anew the "Use Default" square will reset the permission to "Always Ask" and grey-out the other two...
  25. As posted already, file "Login Data" inside 360EE's profile is where login credentials for user accounts are stored; the file is actually of the sqlite format, but without that file extension (in contrast to Mozilla Firefox, where similar files come with the .sqlite extension); inside that file, ONLY actual password strings are being encrypted, not the sites for which you have created accounts for, nor the actual usernames/e-mails you're using on those sites to log-in; so, be careful with that info, too ... Password string encryption is tied to the machine/OS where the password was first saved/created, because parts needed for their decryption (salt?) are stored, encrypted, inside the host's registry; this is different to Mozilla Firefox, where you just need logins.json+key*.db profile dir files to transfer account credentials between Firefox profiles! In any case, profiles in recent Chromium versions are really not portable across different machines ... 360EE also doesn't offer you an option to actually see saved passwords when chrome://settings/passwords has been loaded, nor does it allow you to export saved account credentials in an unencrypted form (.txt, .json, .csv, etc.) - recent Chrome versions (XP-incompatible, of course) do come with such a feature ... What worked for me to manually transfer account credentials from an old 360EE profile to a new one, on a second, different, machine (from Windows Vista SP2 32-bit to Windows 7 SP1 64-bit) was the NirSoft utility called ChromePass . Depending on the type of your 360EE installation (e.g. "proper" or "portable"), you may have to point ChromePass to the actual 360EE profile dir account credentials are to be extracted from; if you don't have a lot of created site accounts (say, less than 20), then you can manually transfer those accounts to other browser profiles, on the same or different machines... NB: Be sure to first read the CP documentation on its site - for 360EEv13+, Chr86-based, you'd need versions > 1.50 ... Hope I've helped ... Cheers
×
×
  • Create New...