VistaLover

Can confirm ; about:support is mostly kaput: The fact is upstream develop on Australis, while original Tycho is pre-Australis (just a guess of mine, hadn't taken the time to investigate further, as I've weaned myself from Tycho... )

Though a faithful uB0 user since its infancy, I don't consider myself an authority on it; besides, many other people here use it as their main adblocker, this is an open/public forum, everyone else (besides me) is invited to chime in and give a helping hand to those that might need it... My dear friend (and this is not meant strictly at you ), I, as much as the rest of the members here trying to offer solutions to other people's predicaments, post on a voluntary basis and to the extent other personal engagements (RL and digital one!) permit ; I'm not running a helpdesk service here, please acknowledge that, people ; thank you all in advance! Which browser is this happening on? I have to guess by a process of elimination, why are you being stingy in providing more details? FWIW, recent St52 builds do not connect any more on AMO to check for extension updates (and uB0 is not present in http://addons.basilisk-browser.org/ that is being checked); if one is at version 1.17.4[WE], then export all its current settings to a file, uninstall it, restart the browser and then install the latest legacy version from GitHub (1.16.4.16); import back your settings from the previously stored file... As for FxESR 52 and St55, these two browsers do still check for installed extensions updates on AMO; it is unfortunate that both the legacy and WE versions of uB0 have the same extension ID, so the XUL version gets updated automatically to the compatible WE iteration of it... ; but this is a known issue in these forums , it has been reported and described in the previous thread and solutions offered by several people, including both yours truly and @Mathwiz ... If you want to stick with 1.17.4[WE], then, for the WP site to work, apply the "fix" I already posted some posts above (which you appear to have disregarded : enable service workers! ) If you want to revert to the XUL (legacy) version of uB0, do as instructed for St52 - but make sure to first install the companion extension offered by @JustOff (a member of MCP and the Waterfox team): https://github.com/JustOff/ublock0-updater/releases/tag/1.6.9 This extension accomplishes two things: 1. Blocks update checks on AMO, thus preventing the unwanted update to the WE version 2. Directs update checks on the GitHub repo of the legacy version, making sure you get the latest legacy version; GitHub have a tendency of messing with this addon (by changing GitHub pages' source code ), so make sure you have that addon at its latest version, to be able to get the latest version of uB0-legacy. Then, for the WP site to work, you don't have to touch the service workers browser pref, the legacy version works out of the box! ADVICE to all: Your browser does have a bookmark feature, please use it to bookmark this post or any other one in this (long) thread you feel you might revisit later... My experience, based on using uB0 for many years, is that no adblocker is immune to detection, especially in recent years when advertisers and independent companies have developed dedicated anti-adblock solutions that are sold to webmasters ; it's a cat and mouse game really; uB0 offers an Adblock Warning Removal native filter list that you should enable, but, sadly, it's not enough Several other specialised adblockers have been created to combat the recent anti-adblock scripts (e.g. Nano Defender), but sadly, these come only as versions compatible with latest Mozilla Firefox and Google Chrome...

I have always felt that extension signing by Mozilla (another move of theirs to ape Google Chrome) just gives the user a false sense of security, certainly the non-advaned ones; I found it a real nuisance myself, so I would choose to use unbranded Firefox builds and/or switch to esr/aurora/dev/nightly channel, where the signing can be disabled via a pref... As such, I applauded MCP in their choice of not implementing it in their UXP browsers... And I can't help remembering the whole debacle some months ago involving an expired intermediate certificate, that caused most installed Fx extensions to be disabled, with no possibility to re-enable... Though signed, one can't be 100% sure an extension doesn't include malevolent code, this is true for both the Google Web Store (GWS) and AMO ; signing is basically an automated process now, I doubt addon reviewers manually inspect every new extension update (for existing ones) along with the truly new ones on AMO... This is slightly OT, but now Mozilla have segregated signed extensions on AMO to "recommended-by-Mozilla" and to the "not-recommended" ones (probably ones poorly reviewed, if at all), and the prospective user should exercise caution when installing one of the second group... So much for the value of the contained signature... Returning to uB0, I believe the version on AMO compatible with UXP is still signed; as for the legacy version on GitHub, this is indeed unsigned, but, unlike you, I trust gorhill (a Canadian, BTW) more that what has become of Mozilla these days; the code is still open source, let alone when a broader community of developers/advanced users, without hidden agendas (I can't, in all honesty, say the same about Googlezilla), keeps a vigilant eye over it... There's always a slim chance GitHub hosted files (now owned by M$) get hacked, but this is true for everything hosted on line (even Moonchild's ftp archive got hacked...). In any case, I'm not passing judgement in the slightest, anyone is totally free and independent to make one's own choices here - what works best for you, as long as varied choices remain available... Best regards

... My bet is @caliber is using the WE variety of uB0... (and, as such, he has to enable service workers in St52... ) Out of curiosity, what brand of ad blocker is it you're using? (I'd be surprised if you didn't use any, though... )

OK, when I visited that specific link in my "dirty" FxESR 52.9.1 profile, I found I could freely read the article and subsequently browse the rest of the WP site; once I fully disabled uB0-legacy, however, I could replicate the reported issue... Then it was a matter of finding out which specific filter list is responsible for lifting the WP imposed nags/limitations; below findings are the distillate of close to 45min of experimenting/troubleshooting: 1. The specific filter list in LEGACY uB0 (currently at version 1.16.4.16, to be found in its own repo now) which allows for uninterrupted WP browsing is a native one, uBlock filters, which contains the following code: ! washingtonpost.com##+js(abort-current-inline-script.js, Promise.all, _0x) !#endif washingtonpost.com##^script:has-text(adblocker) @@||securepubads.g.doubleclick.net/gampad/adx$xhr,domain=washingtonpost.com washingtonpost.com##div:has-text(We noticed you’re blocking ads.) washingtonpost.com##.db-ns[style="height: 1250px;"] washingtonpost.com##html[style="overflow: hidden;"]:style(overflow: auto !important;) ! https://github.com/NanoMeow/QuickReports/issues/1499 washingtonpost.com##section > div:has-text(/^AD$/) washingtonpost.com##:xpath(//*[(text()='AD')]/..) This is valid for uB0-legacy, which is compatible with all flavours of the UXP browsers, plus St55/Moebius (and FxESR 45 SSE, NM27 SSE/SSE2, but I don't normally use these... ) 2. In the off-chance someone is using the WebExtension flavour of uB0 on FxESR52 or St52 (probably 1.17.4)/St55 (1.18.x?), then, again, native filters inside uBlock filters allow for the nag-free browsing of the WP site; but there's a catch: for some reason I'm not familiar with, uB0-WE demands that service workers are enabled in the browser (they are OFF by default, at least in UXP); so, in order for the "Private Mode" sidebar nag to disappear, you have to set dom.serviceWorkers.enabled;true in about:config and make sure "uBlock filters" is selected in uB0-WE's third-party filters settings tab: FWIW, that WP site is a privacy nightmare, a veritable menace ; not only does it set a preposterous amount of standard and HTML5 cookies, just take a look at uB0's badge, where more than 1,000 requests are being blocked... Surely, there exist other avenues to learn the current affairs...

@ClassicNick : Fixed

... You're right, of course; I hadn't noticed, since I only attempted to fetch palemoon-26.5.0-20180718.win2000.7z I've taken the liberty of correcting them myself below: phoenix-0.5-cl933-tls12.7z classilla-9.3.3-win32-tls12.7z rzbrowser-tls12-20200127.7z retrozilla-suite-tls12-20200131.7z K-Meleon1.5.4en-US.tls12.7z KM74-g22-20180718.win2000.7z palemoon-26.5.0-20180718.win2000.7z

@caliber , @Vistapocalypse : I can't reproduce here reported issue, either in St52 nor FxESR 52.9; FWIW, the Free mode of the WP site requires you consent (and allow in browser settings) third party cookies and tracking: Additionally, since I am located within the EU (and so is @caliber ), you have to also consent to GDPR: Ticking the "I agree" box and then clicking the "Continue to site" button, I see no nags while browsing the WP site in Free mode: This is on a dirty profile with uBlock0-legacy 1.16.4.16 and several filter lists enabled...

... yields KM74-g22-20180718.win2000.7z

@roytam1 : In your custom UXP branch, the one you build the UXP browsers on, hence Serpent 52, you have included the following (upstream) commit: https://github.com/roytam1/UXP/commit/690fb973929d5560fc4546885b5f39330161be9e ... But we do still have this interface (i.e. the WebExtensions Addons Manager, WebEx AOM) in St52, so probably that should be reverted? FWIW, original discussion in official forums: https://forum.palemoon.org/viewtopic.php?f=3&t=23362

... Actually, I'm currently using a slightly older, less bloated, paid-for version of KIS, for which I had bought (at a bargain price) a legal 3-year/2 PCs licence; that - slightly older - version continues to receive definitions updates and, before you suggest so yourself, passes with flying colours all the tests at your favourite AMTSO site ; but that 3-year long licence expires this coming June 2020; so I may have to revise my AV options by that time... Chances are this almost 13-year old Vista laptop will be decommissioned by then - I am the (un)proud owner of a newly bought (over the January sales period) modern era 17'' laptop, coming, of course, with Win10 64-bit; it is my plan to transition to that over the next months as my main machine, but this depends on a lot of factors at my end, mostly getting to grips with Win10 itself (which, at this moment, looks so alien to me... ); that hardware, of course, doesn't support Vista in the slightest, but, for nostalgia reasons, I may install it in a VM there (and that's the reason I made sure the new machine has ample RAM, 12GB to be exact...). I hope your curiosity is satisfied now @Vistapocalypse, apologies to the rest for the off-topic nature of the post

... In case you were not made aware of recent revelations... https://bgr.com/2020/01/28/avast-selling-user-data-privacy-scandal/ https://www.dslreports.com/forum/r32641717-Leaked-Documents-Expose-Avast-Selling-Users-Web-Browsing-Data

I believe that is the "new layout" mentioned there (but, God forbid, I'm not a twitter user )... It appears you're on Win7 or higher (since you can run FxESR 68); in "about:config" disable native forked-UXP's decoders by setting "media.ffvpx.enabled;false" and make sure "media.wmf.enabled;true" ; restart NM28 (or St52; what is it exactly you're using?) and then see if the audio on Twitter is OK... If Twitter gets also broken in the official UXP browsers (you can also check this yourself, if on Win7), then I suspect upstream will have to deal with that, eventually; there's one report already on the official forums, https://forum.palemoon.org/viewtopic.php?f=37&t=23597&p=181680 however the OP has not indicated yet whether offered remedy cures the issue for him...

... Recently discussed, only four pages ago... Starting post is this one: Please read relevant posts that followed it; I assume you're on XP (the setting under your forum avatar just says "OS: none specified" ), it might be necessary to switch to APCDM in St52 for Twitter (along with an IE SSUAO); also, everyone using XP here should realise that the major "trendy" social sites (youtube/facebook/instagram/twitter etc.), laden with heavy scripts and rich embedded media content, are constantly evolving to cater to (mostly) mobile platforms and, for desktop, to what is the Win10 version du jour... Roytam1 did try successfully to mitigate the lack of WMF and OS patented decoders under XP, but those ffmpeg decoders inside his custom ffvpx library (in UXP browsers) can only cope as much; FFmpeg itself has long ago abandonned XP support, so, if I'm not mistaken, current decoders are based on an older, XP compatible, FFmpeg branch (3.x.x ?) ... OTOH, those social/media sites (especially twitter & instagram) use encoding profiles & new methods of stream delivery that are not guaranteed to remain compatible with forked-UXP's media decoders...

Isn't it ironic/cheeky they still mention Vista SP1+ as a supported OS, though? ...

... ESU start dates for Windows Embedded Standard 7 and Windows Embedded POSReady 7 are Oct 13th, 2020 and Oct 12th, 2021 , respectively; only Windows 7 Pro for Embedded Systems entered ESU period on Jan 14th, 2020 https://support.microsoft.com/en-us/help/4497181/lifecycle-faq-extended-security-updates

... Adding to what my friend @Vistapocalypse posted, MCP dropped Vista support in Pale Moon with the release of v28.0.0 on Aug 16th 2018, a mere 16 months after Vista's own EoS (end of Extended Support by vendor, which was Apr 11th 2017); so yes, XP diehards shouldn't be moaning over this... Would I have wanted official Vista support to have continued past Tycho (v27.x.x) (and that would've been at a minimal cost, considering how much similar Vista & 7 are, both NT6) ? Of course yes ... But when MCP started developing UXP (forked off FxESR 52, both XP/Vista compatible), Vista had already reached its EoS, so, in his own words, he didn't want to implement support for a "dead" OS in his "new" application platform... https://forum.palemoon.org/viewtopic.php?p=134148#p134148 Addition: In a now hidden () GitHub comment of mine, my own view on the matter: Just for the sake of clarity, Moonchild's response(s):

That's all good, but the OP reported issues accessing Roy's server over plain HTTP: the o.rths.ml site is currently not working FWIW, I can access the referenced link both over plain HTTP and HTTPS (TLS 1.3 used in the latter case) in NM28: BTW, the extension used is SSleuth v0.5.4 https://repo.hyperbola.info:50000/other/iceweasel-uxp/addons/sslsleuth/ssleuth-0.5.4-fx.xpi

All is OK on my side, FWIW... fl=20f353 h=o.rths.ml ip=(redacted) ts=1579888977.859 visit_scheme=http uag=Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Goanna/4.2 Firefox/52.0 PaleMoon/28.6.0a1 colo=AMS http=http/1.1 loc=GR tls=off sni=off warp=off

One such occurrence of an application compiled in Qt 5.7.1 but still working under XP/Vista x86 is DB Browser for SQLite v3.11.2 : (As you said, the app doesn't seem to use the Qt5WebEngine.dll module... )

Machine translation to English for those lacking access to on-line translators:

They should've been disabled by default, according to the Wiki: "Experimental filters" is now, of course, a moot point, as, if you did leave them at their default setting (disabled), they'll soon vanish altogether from available filters... FWIW, manual re-introduction is possible via URI: https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/experimental.txt

uBlock Origin "Legacy" v1.16.4.14 (stable) has been released: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.14 (uB0 updater worked OK at the time of posting, I did not have to upgrade manually... )

@Mathwiz : Hope you're doing fine in the new year ; when you first posted this some days ago, I was genuinely puzzled, but since I was occupied with other matters, both in digital (!) and real life , I left it aside for future investigation; my contribution to the subject at hand was simply which basically links to the old Bugzilla bug #967977 Today I had some extra time and decided to search the official UXP GitHub repo/issue tracker, to find proof which substantiates the report that: (them in that context refers to TLS Session Tickets/TLS cache); I've searched specifically for code that sets the hidden pref security.ssl.disable_session_identifiers to true, but my search was, alas, fruitless... I then browsed @roytam1 's forked UXP repo, both branches (master+custom), for similar code signs, but to no avail, again ... So, by simply going with public source code, I found no clues that the default behaviour in either (official) PM28 and/or (forked) NM28 is to disable TLS session tickets, as you suggested... But you are not to blame yourself , I have myself in the past "slipped" in a similar fashion... ; the blame lies on the OP, for causing undue confusion over a "supposedly" new-found issue, most likely self-inflicted: ... was the post that started all this ; as part of my investigation, I have downloaded said NM28 build (BuildID=20200104010047), as well as the one after it (BuildID=20200110230556) and guess what one finds by visiting https://www.howsmyssl.com in a brand new/fresh (browser) profile: and So, nothing has changed in NM28 with regard to TLS Session Tickets, they are enabled by default (which yields the green "Good" button in that test page) ... Once more, it was simply @msfntor 's troll-ish behaviour in posting unchecked/unverified untruths, which ended up wasting people's time...

... According to: https://nakedsecurity.sophos.com/2020/01/09/browser-zero-day-update-your-firefox-right-now/ disabling IonMonkey JIT by setting: javascript.options.ion;false will get you covered , but with a (slight) performance penalty, of course... The linked article mentions that mitigation only in relation to the Tor Browser (and until the time it gets updated, which it did), but that same "about:config" pref is apparently present in FxESR 52.9.x, which, as we all know, won't be patched...