VistaLover

... But he did already : The command prompt is in Italian, but I can tell you he passed the test (which is even more peculiar, given he can't access the hostname in a browser ); only difference to mine is I pinged IP 104.27.137.100 (from Greece), while he pinged the alternate IP 104.27.136.100 (from Italy) ...

Expected results here:

... I suppose politics isn't allowed here in MSFN (yes, according to rule 2.b: ), so I'll only skim the surface of things, limiting myself to the "technology/physics" of the issue: 1. The USA are a vastly industrialized country, its huge industry sector is responsible for a considerable percentage of global warming/climate change emissions. 2. The current US president, to my knowledge, has withdrawn the US from any global CO2-emissions control treaties, while "poor" Europe still has to honour them. 3. Global warming inducing emissions in one continent contribute to the whole planet getting warmer, as the "butterfly effect" applies here. 4. Using an air-conditioning device consumes major amounts of electricity, to produce this, more emissions are disseminated in power plants, especially if they are of the thermo-electric type (combustion of fossil fuels is used to generate steam, to drive generators). 5. Using an air conditioning device lowers the temperature in the inside, but excess heat is transferred to the outside, resulting in a change to the micro-climate of the area/town/city you live in (surrounding air gets even hotter). FWIW, I am poor (literally, i.e. I have only a reduced/unstable income), a European, but I do have AC in my apartment; for the record, highs up to 38°C are forecast for today, July 28th, where I reside, plus another spell of an African heatwave is about to strike, starting next Wednesday... This was not meant as an inflammatory post , I know what @glnz posted had a joking flavour into it ; still, I posted what I did as food for thought...

Thanks for the correction by @Mathwiz ; I guess I was too quick to suggest a disabled cipher suite ... Looking more closely at the screenshot posted: it may actually be an issue between the local (Italian, in Rome) Cloudflare node and the hosting server, o.rths.cf (IP check of 104.27.136.100 suggests another Cloudflare node in the Northern US); @Sampei.Nihira, can you perhaps try accessing the file via a non-Italian IP, acquired via a Proxy/VPN? Just another wild thought here (?)

@Sampei.Nihira No issues whatsoever here fetching file http://o.rths.cf/palemoon/palemoon-28.7.0a1.win32-git-20190727-9b0ff0e8b-xpmod.7z I suspect you may have to loosen up a tiny bit the tight security implemented in your browser configuration, probably some supposedly "weak" cypher suite needs to be re-enabled; just my 2 eurocents, of course https://www.ssllabs.com/ssltest/analyze.html?d=o.rths.cf e.g. https://www.ssllabs.com/ssltest/analyze.html?d=o.rths.cf&s=104.27.136.100

??????? (Help us to help you ; to pinpoint the culprit extension(s), apply binary search or install them one-by-one, until you discover the infringing one)

... Couldn't have said it better myself ; been a Firefox user since v2.0.0.16, up until v52.9.1ESR, when the Mozilla wizards cut support for my old OS (Vista SP2); have to use FxESR 60.8.0 for WidevineCDM enabled services, on my sister's Win7 SP1 laptop; has any of you trialed the new FxESR 68.0? How much worse is it to FxESR 60.8.0 (soon to be EoS'd)? ... and I say worse knowingly, because, currently, with each new Fx release useful features/functions are being axed ; e.g. does Fx 68.0 support userContent.css customisations?

This was a @roytam1 implemented "fix": https://github.com/roytam1/mozilla45esr/commit/0eaa212 (8 Jun 2018) "Nightly" in this case is the generic app name given to the browser when Mozilla Firefox forked code has been built as an unbranded build; much like New Moon is the default "unbranded" name for Pale Moon forks; so "Nightly" doesn't necessarily always designate a nightly development branch... I recollect reading/studying most SSUAO-related Bugzilla bugs one year ago or so, but blame the summer heat for me not wanting to search for/ track them down/ post them here ; what I distinctly remember is that the SSUAO feature in desktop stable & ESR releases of Firefox was re-enabled starting with Firefox 55.0.x and is still present (with possible limitations) in Firefox Quantum (I remember ESR 60.x.x did work when I tested it on a borrowed Win7 machine...); since @Mathwiz has ready access to Win7 SP1, perhaps he could verify my recollections!

... Only wget.exe needs to be in %PATH%; hence, you could have left the batch file (*.cmd) inside a directory of your choice (or place it on the desktop); but whatever tickles your fancy...

... But @dencorso did provide usage hints: When you unpack the attachment, you'll find a wget.exe binary; the way the batch file is written, wget.exe needs to be in your %PATH% (... environment variable, read more in Wikipedia ); if you don't want to manually add it to %PATH%, you can place that binary inside a directory already in %PATH%: @dencorso's suggestion was %windir% = %SYSTEMROOT% which should default to "C:\Windows", if your OS is indeed installed in the C drive... The second line of the .cmd file changes your working directory to your %TEMP% folder ("Temporary Files" folder, should default to "C:\Users\<YourUserName>\AppData\Local\Temp"), where, of course, there's no wget.exe to be found : pushd %temp% This is why it is imperative you place wget.exe in a directory Windows already has in %PATH%, so it would know where to invoke it from... Apologies for possibly sounding a bit harsh (... rest assured I mean well), but, unless you have some sort of learning disabilities (which if true, I profusely apologise for), almost everything new one wants to learn about is already there in the web, accessible with a bit of searching... Hope I've helped!

Very much like MSE 4.4.304.0 (manually) installed on Vista SP2, the native anti-spyware implementation, aka Windows Defender, ceased receiving definitions update via Windows Update itself sometime after the July 9th deadline; as posted here, the last def update (v1.297.531.0) I got through WU was on July 6th... Similarly, invoking a manual definitions update via the WD GUI: always results in So, currently, the ONLY way of updating WD def files on Vista SP2 is by manually downloading file mpas-fe.exe and then running it (probably "as administrator", but I wouldn't know differently, as I am already the unique admin of the machine!). The location for fetching the file is again https://www.microsoft.com/en-us/wdsi/definitions but in WD's case, it's the "Windows Defender in Windows 7 and Windows Vista" entries... Have you noticed the "Windows Vista" mention? Unlike Windows XP, M$ have still kept file mpengine.dll (inside file mpas-fe.exe) Vista compatible, so they kinda "silently" have continued to support Vista even past its Extended Support EoS, so I was genuinely taken aback (and then miffed) they broke automatic updates for Vista's WD... I have Vista SP2 Home Premium x86 (without the very recent ".6003" WS2008 updates) and hovering over the win32 link I see the following URI: https://go.microsoft.com/fwlink/?LinkID=121721&clcid=0x409&arch=x86&eng=0.0.0.0&avdelta=0.0.0.0&asdelta=0.0.0.0&prod=925A3ACA-C353-458A-AC8D-A7E5EB378092 What's really weird is that clicking that link (during the last 2 weeks or so) has not always fetched the version claimed to be the latest in the page; e.g. the page may announce v1.299.301.0 as available, but downloading from the win32 link may get me an older version on disk (usually 3-6 "units" older, e.g. 1.299.296.0 etc.). To mitigate this, I have found the link in article https://www.askvg.com/how-to-update-windows-defender-offline-install-latest-virus-definition-files-manually/ to be very reliable in faultlessly fetching the version advertised as the most current : https://go.microsoft.com/fwlink/?linkid=70631 Alternatively, I would manually construct https://definitionupdates.microsoft.com/download/DefinitionUpdates/VersionedSignatures/AM/1.xxx.xxx.0/x86/mpas-fe.exe getting the "1.xxx.xxx.0" string from the downloads page... @dencorso: Many thanks indeed for your .cmd file ; however, be advised you only considered the x86 flavour of the definitions update file; it won't do for MSE 64-bit, the preferred default on Vista x64 installations... I also took the liberty of mimicking it for my own purposes, creating a WDUPD_Vista.cmd variant: @echo off ::pushd %temp% if not exist mpas-fe.exe start /min /wait wget -O mpas-fe.exe http://definitionupdates.microsoft.com/download/DefinitionUpdates/x86/mpas-fe.exe if exist mpas-fe.exe start /min /wait mpas-fe.exe del mpas-fe.exe ::popd I commented out your second line, because that way one doesn't have to place wget.exe in the %PATH% variable, just leave it be adjacent to the .cmd file, both in a user writable directory! Again, this is for the 32-bit architecture only... Thanks a bunch !

... Just being pedantic here, but usually an SSLlabs Server test will reveal what's really wrong with https://tipsterarea.com/ https://www.ssllabs.com/ssltest/analyze.html?d=tipsterarea.com ... i.e. the server does support old TLS 1.0 protocol (so "TLS 1.1/1.2 checked" is irrelevant here) with 4 cipher suites, TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH sect571r1 (eq. 15360 bits RSA) FS WEAK 128 TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH sect571r1 (eq. 15360 bits RSA) FS WEAK 256 ... 2 of which don't use ECC, but the real breaker here is to be found, as correctly pointed out by previous posters, under the Handshake Simulation section: IE 8 / XP No FS No SNI Server sent fatal alert: handshake_failure

Well, actually "my" fault was my query arguments were simply worded as "change system drive letter" and the two links posted were harvested from only the first two result pages Google came up with... The original Microsoft help article you linked to uses the verb "restore", so that's probably why it was not suggested to me right away ... Once again, many thanks for a very erudite/informative post on the subject at hand!

... Does this mean Vista will be left out? Was the 7GB figure for both 32-bit/64-bit architectures? If affirmative, perhaps separate standalone uploads for only x86 and only x64 should be attempted... Thanks, regardless...

... NOT possible via Disk Management! Your search engine of choice is usually your friend in cases like these... Possibly helpful: https://www.itprotoday.com/compute-engines/changing-windows-system-drive-letter https://www.petri.com/change_system_drive_letter_in_windows_xp As stressed in the articles themselves, "make a full system backup of the computer and system state."

Mea culpa, then (memory betrayal to be exact) ... ... thanks for explaining!

If I may ask, how do you upload updated binaries there every Saturday, if not by an internet connection? Or, did that mean (only) you have physical access to the server and you upload files locally (e.g. via USB external drives)? Also, from a forum exchange some months ago, when the previous hostname (o.rthost.cf) was revoked, it emerged that you were/are employing a free VPS service; so, aren't you in fact dependent on the security measures enforced by this VPS provider? I am not being paranoid here, just inquisitive...

NM27 binaries, as well as other browser binaries offered by @roytam1, are hosted on a completely different VPS infrastructure and on a (naturally) different hostname, o.rths.cf; unless the same hacker team that targeted archive.palemoon.org, for their own perverse agenda, also targeted o.rths.cf, we should be OK... This latest security breach, which managed to remain undetected for more than 18 months, demonstrates that: 1. Server administrators/owners must always stay alert for such an eventuality, keeping an eye their hosted files remain intact. 2. Users accessing servers with the prospect of downloading files must always exercise due precautionary practices (e.g. scanning files with updated and reputable AV solutions) ... Official PM forum entries: https://forum.palemoon.org/viewtopic.php?f=1&t=22528 https://forum.palemoon.org/viewtopic.php?f=17&t=22526 https://forum.palemoon.org/viewtopic.php?f=1&p=170828#p170828

Welcome to MSFN forums The most recent WD defs file update that came through WU here was on July 6th: As you can see, the update frequency interval is between 2 to 3 days; I also haven't installed any of the SHA-2 updates yet; I usually tend to update WD manually, though, due to more frequent updates delivered that way (3 to 4 during a day...). I guess you could test yourself by leaving WD not (manually) updated for more than 3 days, while keeping WU itself enabled (e.g. notify but not auto-install updates); if nothing turns up after, say, 4-5 days, then you'll get confirmation WU it's broken... As for previous Vista updates, a more ominous rumour is flying around, that dedicated XP and Vista MS Update servers will be permanently shut down; see the relevant XP thread: https://msfn.org/board/topic/178377-on-decommissioning-of-update-servers-for-2000-xp-and-vista-as-of-july-2019/ XP die-hards have already started archiving XP updates from the Catalog, Web Archive and elsewhere, for future usage; haven't seen a similar effort undertaken from Vista communities; but I personally think we should be OK until Jan 2020, when both Server 2008 SP2 and Win7 SP1 reach Extended Support EOL; but I might be wrong...

Only people in the same position as yours can answer that; the maintainer stated already he doesn't have access to an SSE-only machine, so he can't test it himself The installer comprises several binaries and batch files - it can be extracted to a folder with 7-zip (in your case, you'll have to use an SSE compatible 7-zip version, you probably already know what that is...); then try to run the binaries (7z.exe, choice.exe, choice16.com, wget.exe, xxmklink.exe), via command line, on your machine; if they run, good bet is the installer itself will also work... By studying the .bat files in a text editor, you can get a pretty good idea as to what the installer does and where it installs files... Hope I've helped (in an otherwise off-topic post ) No; question is in what way is your video-downloading query relevant to this very thread? ...

Thanks for your vote of confidence ; IMHO, that way we can safely stay clear from any future conflicts between respective official applications and "our" forks... I think not, because, as I said, roytam1/UXP/master is practically a mirror of MoonchildProductions/UXP/master, as such it doesn't contain the patches for XP/Vista compatibility, nor any of the other patches currently present in the custom branch... So that means you'll merge https://github.com/MoonchildProductions/UXP/commit/f7f7224 into roytam1/UXP/custom, with the side-effect being: I'm not using e10s in Serpent 52 myself, so I won't be affected, but that change should be made perfectly clear to those that do... Regards

Some potentially new trouble over the horizon, caused by upstream changeset below: https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499 As most of you know, official Basilisk no longer supports Web Extensions, because what limited support there was (somewhat inferior to the one present in Firefox ESR 52.9.x) was decided by MCP to be removed, purportedly for "security" reasons - that change was reverted by @roytam1 and so WE support in Serpent 52.9.0 has been kept. With WE support removed, MCP proceeded to also remove some latent e10s code still present in platform (UXP) level; this was UXP issue #1130, resolved by upstream commit git-19c0f5e Because "we" have kept WE support, that change was also reverted in Serpent 52, so that one can still force-enable e10s in that fork... At the time, I commented that perhaps the upstream change was favourable for implementation on New Moon 28 alone, because if one force-enables e10s on NM28, one will end up with an unresponsive browser and/or profile corruption (e.g. previous session is mangled ); this is because, and that was stated previously, PM28/NM28 as applications have no code at all to support multiprocess (e10s); Serpent 52, OTOH, does have such support, so force-enabling e10s there doesn't cause havoc... But, since the upstream change was at platform level, I was told it wouldn't be feasible to selectively implement it on NM28 but revert it on Serpent 52, so I didn't pursue this further... Having thought about it in a later instance, this is still feasible, perhaps not very practical: https://github.com/roytam1/UXP/ has two branches currently: 1) master, which in essence mirrors the upstream UXP master branch and 2) custom, which encompasses all @roytam1's custom changes and it's used to build both St52 and NM28, probably the Binary Outcast forks, too... One could create a third branch, e.g. NM-custom, initially as a custom branch clone, implement the upstream changes (19c0f5e + f7f7224) just there and use this branch to compile NM28, while the original custom branch can continue to be used for Serpent 52 compilations! The latest MCP change modifies two language pack files: toolkit/locales/en-US/chrome/global/aboutSupport.dtd https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-3f6259650a01247c84ac14224308b455 and toolkit/locales/en-US/chrome/global/aboutSupport.properties https://github.com/MoonchildProductions/UXP/commit/f7f7224dedd63809fbf5532b7ac843cea22d9499#diff-7e2b1f36d16b447ed465c9f234751864 Since UXP/custom still supports force-enabling e10s, come next Saturday, the platform-wide upstream change must be reverted by @roytam1, because if not, Serpent users who have force-enabled e10s there won't have an easy indication it's being active, apart from chasing basilisk.exe processes in Task Manager - and there's an additional possibility the about:support tab in St52 won't load if the change isn't reverted (?).. If reverted, then future official Pale Moon language packs will cease to work with future New Moon 28 builds (because the official localisation team will soon remove those localised strings and about:support tab will get broken in NM28 with an official LP installed); I'm sure many non-English users of NM28 (I can think of several Polish speakers, one or two Italian speakers etc.) wouldn't want that to happen ... So, what will the course of action be? We've reached that place before in the past, when some people asked that WebRTC support be enabled in NM28 (it's non-existent in PM28), and in the end language pack users "won" (for lack of a better word, it was not a "contest" as such...); what will it be now? Mind you, this hurdle can be circumvented by the UXP 3-branch "method" I detailed above...

... No!

In the original repository, you probably mean the following code in the "about" box: https://github.com/binaryoutcast/binoc-central/blob/c6c62f93930f4809de4b63cd91ef83412e7e299f/projects/mail/base/content/aboutDialog.xul#L57-L59 <description class="text-blurb" id="communityDesc"> &community.start2;<label class="text-link" onclick="openURL('http://binaryoutcast.com/');" oncommand="openUILink(this.getAttribute('href'), event);">&community.mozillaLink;</label>&community.middle2; </description> Disclaimer: I'm not using MailNews myself...

... Wouldn't all this new hardware cost a fortune?