Mathwiz

Seems to be another recurring issue. We last encountered it last May: The "non-interactive JS challenge" GitLab are sending, as part of their CloudFlare protection, is meant to work on only the major villains, i.e. Chrome and "buddies" ... That article was last modified a month ago, possibly the same time GL log-in became broken... And it would seem that User-Agent-Sniffin' does play a role, in the initial detection at least, according to: https://support.cloudflare.com/hc/en-us/articles/204191238-What-are-the-types-of-Threats-#bad-browser The problem from back then (May 5) was eventually resolved by NM 28.10.6a1: But, from @AstroSkipper's post, it looks like Cloudflare has "fixed" their challenge to once again block NM (probably official PM too). AIUI, Cloudflare just out-and-out blocks certain user agents "abused most commonly by spammers," but if you spoof a modern browser (Chrome on my Android is up to version 105 now), Cloudflare will send Javascript that only a modern browser can pass. What to do? Well, first, make sure it's not just a regression: download and try the previous NM version. If it works, report back here. But that probably won't work. Next step is for someone to try official PM. If, as I suspect, it doesn't work there either, know that upstream will be working on it, so 28.10.7a1 will likely resolve the issue. (Not much comfort in the meantime, I realize.) In the meantime, or if all else fails, your best option would be to find a UA that is neither "abused most commonly by spammers" (whatever that means) nor that of a modern browser, in the hopes that Cloudflare will then send you a CAPTCHA. You'd then have to solve an annoying CAPTCHA (and likely provide Google some unpaid labor) but at least you could sign in. Edit: Well, once again, @VistaLover beat me to it, although I suspect he worked longer on his post than I did on mine! Anyway, using Serpent 52 (and presumably its default UA) he did eventually receive the annoying CAPTCHA, which apparently he didn't have to solve manually. (Cloudflare may not like his PC, but Google was apparently satisfied that he wasn't a bot.) BTW, does anyone besides me find it, well, just plain stupid that Cloudflare thinks you may be a bot if your PC is too slow? What would be the point of using a bot that's slower than a human anyway? If it's that slow, you could just pay some impoverished third-world resident to do the same work, and (s)he could solve all the CAPTCHAs your site could manage. Edit 2: Or not - it just occurred to me that many of Google's CAPTCHAs are rather specific to modern Euro-American culture, so maybe a third-world resident couldn't solve them so easily; I don't know for sure....

In the interest of choice, Serpent (Australis interface) offers yet another solution: open about:about in a tab, then pin the tab! BTW, when using my pinned tab, I prefer to right-click, then open my chosen about: page in a new tab. That way I don't have to remember to go back to the previous page when I'm done.

Thank you; I wanted to make sure I wasn't just overlooking it. Back when Serpent was new, both versions (52 and 55) had support for Sync, so at least back then - 2018 or so - it just got included by default in Firefox forks like Basilisk/Serpent. So it seems to me that if it isn't in MyPal 68, its absence is likely deliberate. I just don't know whether it's deliberate on Feodor2's part or on Mozilla's part. It could be that Feodor2 removed it to avoid licensing issues with Mozilla, or it could be that Mozilla changed the source so that unbranded/rebranded forks no longer contain Sync by default. But it's not that big of a deal. I'm just curious, and I'm sure Feodor2 has bigger issues to contend with (MyPal 68 is still in beta).

I just learned a new trick I've been using the "Open With" extension for some time to simplify my Web browsing in Serpent. I normally use a profile with multiprocess mode enabled, but when I come across a link that requires a polyfill (such as GitHub, GitLab, etc.), I need to open a new browser window using my single-process mode profile. So I set up Open With to give me a menu option to do that. But there was a restriction. I always wanted the ability to run Serpent 55 from Serpent 52 or vice versa; but if I tried, even though I specified the correct path to the "other" Serpent, it would always open up the version I was running again. Weird. Well, I just found a workaround. Unfortunately it only works on 64-bit OSes, but it turns out that, if I'm running, say, 32-bit St 55, I can open 64-bit St 52! I just have to specify the path to the 64-bit version in Open With. Example entry: (They are truncated a bit in the above snip; the end of the command is of course basilisk.exe, and the end of the argument is -no-remote. I haven't tested every combination yet, but I assume it will work in reverse; i.e., if I'm running 64-bit St 55, I can open 32-bit St 52, and vice versa. One "gotcha," though, is that while folder names are not case-sensitive, profile names are! So make sure you get the case after the -P flag exactly right; otherwise you'll get the "Choose Profile" prompt instead of launching directly into your desired profile.

Well, of course, not 10 minutes after I posted the above, I found a new potential issue. Is anyone able to expand a long quote? For instance, this quote should "fade out" after a few lines, with an "expand" button at the bottom to reveal the whole quote. Does the "expand" button work with older browsers? For me on Serpent 55, it appears to work inconsistently; i.e., I can expand the quote below, but not some others:

It appears that the site issues that prompted this thread have been resolved. You could ask @xper, but there may be nothing more to discuss about the original topic. As such, you may wish to close this thread to further replies. Although I wouldn't object to having the last several posts moved to a new thread about browser sync systems. Up to you; it's fine with me either way.

Not sure, but the topic came up recently in another thread, and this seems like the appropriate place to ask: Was support for Firefox Sync removed from MyPal 68? I looked around and couldn't find it, but the Photon UI is so Chrome-like (and Australis-unlike) I could easily have missed it. If it was removed, was it because of a requirement under the MPL?

As you may know, Martok has just released Palefill 1.20. Since he has unfortunately declined to update Palefill to support www.ING.de, users of that web site will have to follow the above instructions themselves (do not key in the +'s; those merely indicate added lines) in order to use www.ING.de with Palefill 1.20 or subsequent releases. Oh, and by the way, GitHub is partially broken again with Palefill 1.19 or 1.20, at least when force-installed in Serpent 55. (Edit: Palefill 1.20 does seem to be doing the job in IceApe, so this must be an incompatibility between Palefill and St 55. GitLab is still working fine in St 55 though, so Palefill must be doing something right!) I swear, Micro$oft must require its GitHub developers to shoehorn in at least one use of every newly-announced Javascript feature, so that something on GitHub will break every time Google thinks up anything new! Luckily, downloading new releases still works (for now).

Me too! But if I did want a sync service and were free to pick one, PM Sync is more secure (there's that word again), and both are free, so all else being equal I'd choose PM Sync. If one were very ambitious (and had enough free time and programming skill) the best solution might be to add code to, say, St 52, offering a choice of PM Sync or FF Sync. That way, if you (a) wanted a sync service and (b) used FF on other platforms, you could choose FF sync; if (a) applied but not (b) you could choose PM sync. Best of both worlds!

I've always understood the word "insecure" to mean "not" secure vs. "less" secure; that's why I would've used the latter wording. But as you say, it's linguistic hair-splitting; hardly worth arguing about. A more interesting question is whether it's possible to restore Firefox Sync functionality to either version of Serpent. In the case of St 52, this would involve reverting some very old changes, which sounds risky: no telling what subsequent changes would be rolled back in the attempt. And St 52 users may be using Palemoon Sync now, and wouldn't want to lose that functionality. So probably best to leave St 52 alone, at least unless MCP blocks it from accessing Palemoon Sync. But St 55 still has the original Sync functionality it inherited from FF 53; it just doesn't seem to work for some reason. It may be feasible to fix Sync in St 55. Another possibility that comes to mind is MyPal 68; an XP-compatible FF 68 fork that may support FF Sync. (I haven't tried it.) Either could be the ultimate answer to @Dave-H's conundrum, since he could then use St 55 or MyPal 68 on XP, and Firefox on his other platforms, and could browse most modern Web sites, even on XP, without having to move to 360EE and lose Sync functionality.

I had to go back to that post because I honestly didn't remember reading anything about Basilisk being sold to a new developer, and when I got there, I saw why: There just isn't much to that post - mostly just "wow" without explaining what was so "wow"-worthy - and I'm not in the habit of clicking blind links just because someone says "wow." Basilisk wasn't even mentioned until the very last word - and that was in a quote about removing telemetry from Basilisk with no obvious relation to the rest of the post. Which brings up an MSFN question. When you post a link on MSFN to another MSFN post, MSFN "unfurls" it by default, providing a brief preview (although for some reason it didn't do so in @VistaLover's post). Does MSFN provide a way to similarly "unfurl" a link to a "foreign" site like palemoon.org? I've seen that feature at other fora, and it would've been quite useful in @XPerceniol's post. Thank you! This is actually such a simple solution to the branding issue I'm surprised no one thought of it earlier. Not that it would have satisfied the previous owners, but still, thanks again! I'm betting it's upstream, and that @roytam1 didn't even know about it. I'm also betting upstream couldn't possibly care less about our issues with the change. Perhaps @roytam1 could restore the original profile location; OTOH, deliberately forcing the path in MailNews back to "Binary Outcast\Interlink" would likely be viewed by upstream as trademark infringement. So perhaps it's best to live with it as is, particularly since you found a workaround.

So (official) Basilisk lives again, under new management! I guess money talks. Official Basilisk doesn't run on the "older OSes" that are the focus of this subforum; still, I'm surprised. I don't remember reading anything about this news before now. I do hope the new owner is less hostile to XP/Vista forks than MCP was. He did say to a Mac developer: ... which is encouraging. @roytam1's Serpent has diverged from official Basilisk in several ways other than retaining XP support, since Roytam also retained support that MCP removed for e10s, WebExtension add-ons, container tabs, and possibly lots of other stuff I'm forgetting. Still, it's nice to know there's an "upstream" again.

Come to think of it, even the word "insecure" overstates the case against FF 52.9. I'd probably describe it as merely "less secure" than 360EE, MyPal 68, and UXP-based browsers. WinXP is even older, of course, but we XP users got security updates through 2019, thanks to the POSReady hack. So strictly speaking, I guess FF 52.9 is even more out of date than XP itself! That said, the security risks involved are similar. IMO, they exist, but aren't terribly significant for most purposes. The best reason to move on from FF 52.9 is the one @Dave-H himself just gave; it just doesn't work well with the modern Web any more.

Basilisk/52.9.2022.08.06? I'm surprised ABBO accepts that. Wasn't MCP's final Basilisk version released over a year ago? But, as long as it works.

And here I thought Plex was just PVR software to run on your own PC! I guess they're branching out and trying to get into the streaming game with plex.tv.

Let me push back a little bit against that. AFAIK, FF 52 does support TLS 1.2 and many modern, secure cipher suites. I probably wouldn't store my email or banking passwords in a FF 52 profile, but it's probably just fine for most casual browsing. Like WinXP itself, just because it doesn't have all the latest security features, doesn't make it "totally" insecure! You just have to be a little more careful.

I can answer on @Dave-H's behalf. He also uses Firefox on Android and so relies on Firefox Sync, which hasn't been supported on, say, Serpent, in many years (specifically, since MCP created their own sync platform for Pale Moon and, at the time, Serpent Basilisk, and @roytam1 followed suit in New Moon and Serpent). True, he could probably "upgrade" to the last Serpent version prior to the changeover, but that really wouldn't improve his situation all that much.

Possibly related: I'm using @roytam1's Serpent 55 and am able to post. However, when I click Submit Reply, MSFN doesn't appear to do anything. It actually does post my reply, but since it doesn't seem to, it's easy to accidentally double-post. That just happened to me. Edit: It appears this behavior only occurs if your post appears on a different page than the one you're viewing! So it usually works correctly, and only fails one time out of 15 (or if I'm replying to an old post). Edit 2: Seems to be fixed. At least, St 55 is working fine for me now.

(deleted)

Question about this: it wasn't long ago that addons.palemoon.org checked your browser's user-agent and wouldn't let New Moon users (version 28.10.*) or users on unsupported OSes (< NT 6.1) download any add-ons. Easily fixed with a SSUAO; e.g., general.useragent.override.addons.palemoon.org;Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:4.8) Goanna/20211001 PaleMoon/29.4.0.2 (that's a rather old Pale Moon version, but you get the idea) ... but is that not required any longer?

Well, your (and @VistaLover's) English is far, far better than my German (and I don't understand Greek at all)! But since this is an international forum, whenever I'm misunderstood, I always wonder if something I said didn't translate well into the reader's native language. Hence my preemptive apology for any language barrier. At any rate, it was all just a big misunderstanding! I knew at least one browser (my favorite St 55) requires palefill's install.rdf to be modified, and as far as I knew, there, well, "may" be others, so I thought it best to warn those reading my post about that possibility. But somehow that possibility got misread as an inevitability, so everyone thought I must have "assumed" that NM, or all browsers compatible with XP (or something - I'm still unsure what exactly I was thought to be "assuming") required a modification to palefill's install.rdf. The fact that the gh-wc-pf version I happened to be using (1.2.19.1) doesn't work with GitLab (which is why I recommended switching to palefill in the first place), but both the version before (1.2.19) and the one after (1.2.19.2) do work, likely added to the confusion. If your only goal is to download the latest CleanFlash installer, you don't need palefill at all; the last "official" version of gh-wc-pf on its GitHub page, 1.2.19, displays GitLab pages fine. But ironically, you are more likely to need to modify gh-wc-pf 1.2.19's install.rdf. Besides, palefill fixes some Web sites besides GitHub and GitLab. So even though you don't have to, it's probably worth switching to palefill anyway.

(emphasis added) Wow; what a prickly pair of posts! Let me respond in kind. The GitLab link failed to load for me, not only in St55, but also in (UXP-based) IceApe. I was using 1.2.19.1 in both browsers, so I'm surprised to learn that GitLab works with "plain" 1.2.19; I guess the fix @roytam1 added in .1 (to fix a GitHub issue) broke GitLab somehow. Unfortunately Roytam's fixes are linked in comments and so aren't shown on gh-wc-pf's release page, so I was unaware 1.2.19.2 even existed until I read @VistaLover's post. Thus I turned to Palefill (v1.19.3), and the GitLab page loaded fine in both browsers. So I linked to Palefill as a known-working GitLab solution, though of course now that I know about gh-wc-pf 1.2.19.2, I suspect Palefill 1.19.3 doesn't incorporate the latest GitHub fixes (or equivalent ones) from it; so for the specific case of GitHub, I suppose gh-wc-pf 1.2.19.2 is the preferred solution. (Also unknown is what happens if both are installed at once!) At any rate, both add-ons are chasing many fast-moving targets. And speaking of Palefill, apologies if there is a language barrier, but I made no assumption about browsers. I said, "you may also need to modify install.rdf," not "you will also need to modify install.rdf." "May" makes the sentence conditional, so I didn't think I'd nonetheless be expected to test Palefill installation in every possible browser to see which ones needed a modification!

Clean Flash Installer version 34.0.0.267 is now available at https://gitlab.com/cleanflash/installer/-/releases/. Unfortunately, JustOff's GitHub-wc-polyfill add-on is no longer v1.2.19.1 isn't enough to access GitLab from a UXP browser; if you have that version, you must now either downgrade to v1.2.19 or upgrade to v1.2.19.2 (links below) or use Martok's Palefill add-on. You may also need to modify install.rdf to allow either add-on to be installed. Palefill is compatible with more browsers without modification, and it fixes some websites other than GitHub and GitLab, so I now recommend Palefill over GitHub-wc-polyfill. Also, Serpent 52/55 must be in single-process mode. 360EE-based browsers should work without issue.

I get the "unsupported after Dec. 2020" banner as far back as Version 77.0.235.9 (Aug. 2019). M$ had already built a time bomb into Edge by then.

At least this time it's not Google causing trouble! I'm guessing, from the "-moz" prefix on the media queries, it's Mozilla this time - probably unintentionally too; the idea was probably to let Web designers give their sites a look "compatible" with the standard theme of a user's OS (so on Vista/7, a Web site could have an Aero look, etc.) But it also allows Web designers to make their sites unusable on any OS they dislike, as long as a Mozilla-derived browser is used. Just make everything hidden unless Win 10 is detected! And UA spoofing is useless, since the browser itself is determining the OS version and applying the CSS accordingly. I'm surprised MCP didn't use this CSS trick to make their sites useless to XP/Vista users running Serpent/New Moon/MyPal back when MAT was there! Might be a good idea to find a launcher that can fool the browser into thinking it's running on a Windows version other than the one it's really running on, just in case this becomes a bigger problem over time. Naturally, St55 does require install.rdf to be modified. But I've gotten quite used to that by now; once modified it installs and looks fine in St55. Naturally on Win 7, I get the Win 7 "look," which doesn't really match my "Classic" (Win98-like) theme! Still, my only complaint was that everything got way too big for my taste. It's perfectly usable.