Mathwiz

Basilisk Serpent 55 isn't as compatible with add-ons/plug-ins as Serpent 52. It was forked from a later FF version where most NPAPI plug-ins (except Flash) were disabled. Edit: That turned out to be totally wrong; sorry. Actually Serpent 55 does support NPAPI plug-ins, and at least a few add-ons that Serpent 52 doesn't support.

The patches for NM/Serpent should apply to FF also.

@i430VX: Does your installer work with PM 27 builds, particularly, the pre-SSE2 builds? If not, someone just posted a request for one:

Mypal, NM, and Serpent are all confirmed working with Instagram videos (from 21 July 2018 forward). For those on FF 52.9, Serpent is probably the easiest upgrade since it's most similar to FF (same UI and supports the same add-ons & plug-ins). But Mypal and NM are fine too. All three are updated regularly.

It has to be one of the changes applied to New Moon & Serpent here: Both browsers play Instagram videos from the linked version forward, but earlier versions do not.

(W)TL;DR: Some sites were able to detect legacy versions of uBO but not WE versions. Obviously a problem for those of us who prefer the legacy version. A new legacy version of uBO, 1.16.4.10, fixes this issue. Legacy uBO users, please update. After doing so, you must back up, then restore your settings (uBO Dashboard / Settings tab / Back up to file & Restore from file (at bottom of Settings tab) in order to load the new legacy-specific rules.

I suspect FF 52.9's Github and Instagram video issues are both related to JavaScript bugs that are fixed in Serpent/NM/MyPal. Probably no easy fix, other than switching to one of those browsers. Edit: Turns out it's a CSS, not Javascript, bug - and there is a fix! See @mixit's post here: https://msfn.org/board/topic/178259-instagram-videos-not-working-in-firefox-52-esr/?do=findComment&comment=1161357

Well, yes and no; according to this somewhat cumbersome JavaScript test page I found, both FF ESR 52 (select "Show obsolete platforms" to see) and Serpent 52 ("current browser") and probably NM 28 too, support the ECMAScript 2017 standard for JavaScript. But Serpent & NM have a couple of fixes that FF ESR 52 doesn't: a couple of changes in the ECMAScript 2017 standard work on Serpent but not FF ESR 52. The features that differ on that page are very minor and probably unrelated to the Instagram video problem. But given what else I found ... ... I suspect there's another Javascript bug in FF 52.9.1 that was fixed in Serpent 52/NM 28/MyPal, which causes FF 52's Instagram video bug. If so, it probably isn't fixable on FF 52.9.1 without rebuilding FF from source after applying the fixes. (OT, but this probably also explains FF 52.9.1's problems with Github.com mentioned on another thread.)

Should be; I don't know of an easy way to confirm that though. Anyway, I may have been wrong above: it could be a difference in how Javascript works after all. Some of the changes between the NM that doesn't work and the NM that does seem to be related to Javascript.

At present the only known fix for the Instagram issue is to switch to @roytam1's New Moon or Serpent browser. Note that of those, only Serpent supports Adobe's Primetime CDM plug-in.

Github doesn't work in Serpent 52 either unless I override the user-agent to: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.9) Gecko/20100101 Firefox/60.9 If I do that, Github works fine. Can someone try that in FF 52.9.1?

Also works in Serpent 52, so probably not Javascript either. I don't think the PM team made any changes to Javascript since they forked FF ESR 52. (Unfortunately Instagram's pages are just an indecipherable mass/mess of Javascript.) Video appears to just be an ordinary .mp4 file, so you'd think the Primetime module would work. Anyone know the MIME type of these Instagram videos? I suppose one way to debug the problem would be to go back to @roytam1's first build of NM 28. If it doesn't work there, do a sort of "binary search" until we figure out where it starts working again, then see what was changed in that build. Sounds really tedious though. Edit: I've narrowed it down; NM 28 from July 14 shows the same problem as FF ESR 52; NM 28 from July 21 onward works. (Both 7/14 and 7/21 were beta versions of NM 28.) Here's a link to the 7/21 version in @roytam1's blog: one of those changes must have fixed it. https://rtfreesoft.blogspot.com/2018/07/weekly-browser-binaries-20180721.html

Well, I installed VSE 2015 on my home PC last night. Didn't yet get a chance to do anything else, though, because the installation took the whole evening! Man, that is a huge piece of bloatware - even including a Windows 10 SDK (which didn't even install for some reason - just as well - but nevertheless wasted about an hour trying, and I think the install file is still wasting space on my HDD)! Also, with VSE 2015 M$ now makes you create a M$ account in order to get a permanent license key . I'll do that if I have to, but I may give VSE 2013 a try on my work PC, just to see if it's a bit more reasonably sized and/or licensed and still up to the task.

To me, the Win 8 "Metro" UI reminded me way too much of the old Windows 3.1 Program Mangler, except updated with animations. I also didn't care too much for its "tiled" appearance - that reminded me of Windows 2! M$ actually could have gone "back to the future" with an improved PM. Back in the day, Symantec did it with their Norton Desktop, giving Win 3.1 an almost Mac-like appearance. But in this day and age where everyone makes copyright and patent claims on the most trivial grounds imaginable* I suppose M$ didn't want the legal exposure. So they ended up with Metro. Yuck. *AIUI Apple actually sued a company selling a Windows-like UI for PCs called Gem Desktop, because it had a "Trash Can" just like the Mac! Which is why Windows has a "Recycle Bin" instead - or at least, so I've heard.

Well, the Sword of Damocles has been removed from my VSE 2010 installation - I found a valid registration key - but I do have Win 7, so I'll give VSE 2015 a try. If it works, I'll still target XP but the build should work with later Python versions. I'll also add the libcrypto-static and libssl-static .libs to the build archives, so you can build Cryptography either with or without the .dlls.

I wouldn't think an outage would affect one browser but not another on the same PC. Appears it's not the user agent either. @FranceBB, I assumed you tested with NM 28. Was that assumption correct?

I assume you mean @roytam1's New Moon, or maybe you're testing on Win 7 - anyhow, in compatibility mode, New/Pale Moon both spoof FF 60.9. Have you tried setting general.useragent.override to "Mozilla/5.0 (Windows NT 6.1; rv:60.9) Gecko/20100101 Firefox/60.9"?

Almost. (I assume that unlike me, you have a full version that will not expire!) You also need Perl and NASM. I used Strawberry Perl, available from http://strawberryperl.com. NASM is available from https://www.nasm.us. Both are free. After installing them, make sure both are in your PATH. Edit: I forgot to mention; once you install Perl you need to install the "Text::Template" module. To do this, enter the command cpan Text::Template I created OpenSSL with all default options, except for forcing XP compatibility. VSE 2010 puts a "Visual Studio Command Prompt" on the Start menu. It runs a batch file that sets up the necessary environment variables. I selected that, then ran these commands: $ perl Configure VC-WIN32 -D_WIN32_WINNT=0x0501 $ nmake $ nmake test $ nmake install nmake is part of VS2010. The '$' above stands for the C:\> command prompt. The final build was placed in C:\Program Files\OpenSSL. Unix and OpenVMS support a "no-shared" config option. I didn't try that for this Windows build, but if it works, I assume everything would be built into the .lib files and no .dll files would be built, which I believe is how the Cryptography developers intended it.

That site has an expired certificate, so IE8 will give you a warning; you have to click "continue to this site (not recommended)" to load the page. Also, it seems to be misidentifying the supported cipher suites. In my case they should all be AES or 3DES; no idea where it's getting "MISTY1." But at least it proves TLS 1.2 is working: "This connection uses TLSv1.2 with AES256-SHA256 ...." It says IE8 doesn't send SNI (Server Name Indication). That may be why the other sites won't load.

@glnz: I think this thread has the best step-by-step instructions for enabling TLS 1.1/1.2: ... although as noted above, my IE8 seems to be broken at the moment

New one today: KB4462226. Seems OK (PowerPoint Viewer 2010 still works, at least).

Good question. My IE8 displays "Internet Explorer cannot display the webpage" (unless I use ProxHTTPSProxyMII, in which case it's showing my ProxHTTPSProxyMII's capabilities, not IE8's). As I recall it used to work without it. Is that what yours is doing too? Edit: howsmyssl.com is doing the same thing.

I think this is even better than the original! With the original Cryptography, we had to wait for the Python developers to release a new Cryptography version, incorporating the latest OpenSSL. With your version, we only need to replace the .dll's in C:\Python34\Lib\site-packages\cryptography\hazmat\bindings. Unfortunately, the copy of MS Visual Studio Express 2010 I used to build OpenSSL is set to expire in 25 days, and M$ no longer provides free registration for VSE 2010 or 2012. For VSE 2008, there was a simple workaround involving deleting a registry key, but it doesn't seem to work for VSE 2010. So I'll probably have to install VSE 2015 (along with Perl and NASM) on the Win 7 side in order to build OpenSSL when 1.1.1c comes out.

Win 10 is a rolling disaster. Win 8 (and, I assume, 8.1) aren't bad as long as you install Classic Shell so you don't have to deal with the "Metro" UI. With Win 8, you can get WMC for the Pro version, and IIRC there's even a Web site where you can get Win 7's "gadgets" back. (Gadgets were removed in 8 for "security;" IOW, M$ didn't want to deal with patching any security holes that might crop up, so they just dropped gadgets in Win 8 entirely. Ironic since Win 7 & its gadgets are supposedly supported for another year.) I think Win 7 Pro is the last version with "XP Mode" (XP in a VM), though. If you have 7 Pro, grab XP mode while you can; it's still the best solution for folks needing XP for older programs and 7+ for newer ones!

Trying to build it now. Despite the fact that I'm building on WinXP, I still had to explicitly tell it to build for WinXP: perl Configure VC-WIN32 -D_WIN32_WINNT=0x0501 Without the -D just about every test failed; apparently the stupid Configure script just assumes Win 7+ rather than grabbing the version it's actually running on . That may explain why so many of the "compatible with XP" builds aren't actually compatible with XP. Edit: Final (apparently XP-compatible) build of OpenSSL v1.1.1b is about 3 MB when written to a .7z archive file. You can download it from my company's Web site.