Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

VistaLover

Member
  • Content Count

    670
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by VistaLover

  1. 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
  2. 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
  3. 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... )
  4. Machine translation to English for those lacking access to on-line translators:
  5. 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
  6. 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... )
  7. @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...
  8. ... 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...
  9. If my understanding is correct, it might be already in with the latest 2020-01-11 build: "above" refers to https://msfn.org/board/topic/180462-my-browser-builds-part-2/?do=findComment&comment=1176055 where it's stated: The "patch" you refer to is platform wide, so it should be present in all latest UXP applications (NM28, St52, MN, BN); Moebius (St55) had to be treated separately...
  10. I'm on v1.16.4.14b2 since yesterday My installation was on an extremely heavy New Moon 28 profile: tens of extensions, many userstyles installed (within Stylem), many userscripts installed (within GM-for-PM), that means it's not a "snappy" profile to begin with ; so I can't make any remarks regarding uB0 related performance issues... I guess the proper thing to do is to install ONLY the beta on a fresh NM28 profile and then submit it to various benchmarking tests; but I couldn't be bothered, to be frank For more info, I'd keep an eye on https://github.com/DandelionSprout/adfilt/issues/7 https://github.com/uBlockOrigin/uAssets/pull/6808/ https://github.com/gorhill/uBlock/pull/3765
  11. Special message from upstream: https://forum.palemoon.org/viewtopic.php?f=1&t=23605 (and https://forum.palemoon.org/viewtopic.php?p=181666#p181666 )
  12. ... Trouble's in the air for uB0-legacy : https://forum.palemoon.org/viewtopic.php?p=181590#p181590 ... and following posts... Betas of v1.16.4.14 : https://github.com/JustOff/misc-pm-stuff/releases/ (... but the "on-the-fly" rule conversion to the old format, supported in uB0-legacy, does result in performance degradation... )
  13. ... However, you can delay its installation for as long as you like : https://www.askvg.com/windows-10-tip-block-or-prevent-automatic-installation-of-microsoft-edge-browser-via-windows-update/ (... but this would not be a smart move security wise, as M$ will no longer release security patches for the "original" (EdgeHTML/Chakra) iteration... )
  14. Whatever you do, please don't re-block ATI radeon drivers. I'm even getting good acceleration in an old W2k box ... Please understand Roytam1 doesn't block graphics drivers on his own, only upstream do... FWIW, https://github.com/MoonchildProductions/Pale-Moon/commit/b7841e5 was pushed to mitigate crashes on Linux, as reported in https://forum.palemoon.org/viewtopic.php?f=37&t=23512 But previous commit was reverted by Moonchild on Jan 10th, via https://github.com/MoonchildProductions/Pale-Moon/commit/b4a6053 ... which @roytam1 might've missed by a narrow margin (was published on GitHub at 202001101821UTC) ; in any case, nothing to fear on Windows...
  15. Thank you, - I've set now New Name, boolean, in Moebius 55. Some relevant Firefox documentation, for the curious... which links to the corresponding Bugzilla bug number: https://bugzilla.mozilla.org/show_bug.cgi?id=967977
  16. Oh my God, am I turning into a Matt A. Tobin clone?
  17. "safebrowsing" (as well as Tracking Protection) was/is a Mozilla Firefox feature that is reliant upon Google APIs/services; Mozilla, as is vastly known, rely heavily on Google to collect revenue, so they had agreed on "gluing" this feature onto their browser... It is currently only relevant to FirefoxESR 45.9.x & Serpent 55/Moebius forks and it's still present in (forked) Moebius because MCP had abandoned the platform before taking the time to remove it... In UXP browsers builds, these Google provided services (i.e. Block dangerous and deceptive content => Block dangerous downloads + Warn me about unwanted and uncommon software) have been removed by MCP and, if you ask me, that is a blessing in disguise... This is just me, but I consider (evil) Google to be a malware by definition, so I wouldn't want to be given advice by them on what web page to visit and what file to download... The average Joe, using the latest Firefox (in Win10, no doubt...) only gets a (false IMHO) sense of security because all-knowing Google are taking care of him in the background ( ) ... Common sense is to be exercised here, of course backed-up by an otherwise updated/secure browser engine, a set of updated privacy/security extensions, including in-browser content blockers (but not a myriad of them...), a supported and up-to-date Security Suite OS-wide and I humbly think no-one's in need anymore of the ever spying/tracking Google... You are entitled to a different opinion, of course ; as said, these are only my own views...
  18. Another common mortal here, but I think we've had enough of that same ol' mantra of yours ; you keep revisiting/reciting the same demands, and I imagine you'll keep doing so unless you have it your own way, pretty much like a spoiled child that keeps crying to have its needs met ... Common/mere mortals as in browser users (and, mind you, common/mortal browser users are only using the latest Google Chrome version on Win10/Android these days...) are expected to follow and apply detailed and easy to understand instructions others have compiled to mitigate known issues in the niche browser builds they're using in their niche (as in outdated/unsupported by vendor) Windows OSes; those instructions aren't meant for developers, just users! FirefoxESR 45.9.x and patented decoders support => detailed instructions posted (by me and others) to enable it via Adobe Primetime CDM or LAV Filters DLL files (takes 5min of your time, max...) Arctic Fox and patented decoders support => this fork is originally meant for MacOS, where h264/aac support is native to the OS; added code is probably needed to accomplish this for Windows, especially for XP... uBlock0-legacy on BNav => you need only a code/text editor to open/modify/save its "install.rdf" file according to instructions given; other mere mortals here in these forums can, why aren't you willing to? Doesn't take more that 1min, max... ... "Without your intervention?" This comes across as quite disrespectful to the massive effort exerted by the maintainer of several browser forks; aren't you willing to make yourself even the slightest of efforts? It appears you only want to be spoon-fed, so that your stomach is kept full without "your intervention"... Grow up! To all others: I apologise for the rant-ish nature of my post, but I had to vent...
  19. uBlock0-legacy 1.16.4.13 has just been released: https://github.com/gorhill/uBlock/releases/tag/firefox-legacy-1.16.4.13 Once again, we have to thank Ukrainian developer @JustOff ( ), who is part of the MCP devs team (though not inside Moonchild's immediate circle...): https://github.com/gorhill/uBlock/commit/0f3c467 If you prefer to let his extension, uB0-updater, do the update for you, make sure it's in its latest version, 1.6.8
  20. Thanks for that! Thanks for that second confirmation ; it isn't that I doubted @WinClient5270 's initial report (of course not! ), just that I began questioning the validity of what I had learned via Qt's official documentation on supported Windows OSes... Added thanks for your attempt at explaining this (still considered by me as) oddity; FWIW, any (other) application built on Qt 5.7+ has more chances not running under Vista than the opposite... Festive greetings!
  21. ... But mere mortals running Vista SP2 32-bit are, once again , excluded from even trying to run that application on their Vista copy... If you had tried on (regular) Windows XP SP3 32-bit with lowering the subsystem version in the PE header to 5.1 (it's set to 6.0 by default), I guess a similar error, pertaining to win32 apps, is to be expected, as the application is NOT win32, compiled to be only runnable in the 64-bit architecture... What I can see , based on your attached screengrab, is that the app was compiled using version 5.9.7 of the Qt Framework, which in itself provokes major surprise on yours truly... ; I have always known, and that knowledge is based on official Qt documentation, that the last Vista-compatible version of the framework was 5.6 (5.6.3 to be exact!), and only on client machines : https://doc.qt.io/archives/qt-5.6/supported-platforms.html ... whereas v5.9 of Qt has zero support for Vista (and, of course, XP): https://doc.qt.io/qt-5.9/supported-platforms.html Any explanation as to how a Qt 5.9 built application is able to launch under Vista SP2 64-bit is highly welcome (if somebody can provide one ) ... For official system requirements, see @win32 's post; so, your assumption is not correct, as Vista (64-bit only) isn't officially supported! Given that the PE-header in the main executable is set at a subsys version of 6.0, at least our beloved OS was taken into consideration in that regard, but who can say which NT version the actual build-time compiler optimisations were targeting? As detailed above, I remain quite sceptical this is indeed running under Vista SP2 64-bit... OT: I hope you all had a great Xmas Day, surrounded by your loved ones; best wishes for the New Year, too!
  22. The site maintainers do not support the UXP-based browsers; use a pure Firefox based SSUAO, if on New Moon 28/Serpent 52.9.0 (though you did not provide any clue yourself regarding which browser you encountered this artificial block with ; why are help seekers always being stingy in giving out details about their configuration?... ). E.g. FirefoxESR 68 (the latest supported ESR) on a Win7 64-bit host: general.useragent.override.vintom.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Firefox/68.0 Proof on New Moon 28 32-bit run on Vista SP2 32-bit:
  23. @Cixert : The "Preferences" (no file extension there!) file is the one that stores your custom browser preferences (modified from their original default values) and, as posted, should be found within your "Profile" folder, usually under ".\User Data\Default" First, BACK UP that file to a secure location in your disk, before you attempt messing with it manually; any such attempt should be made with the browser exited! The file itself is in a human-readable "pretty-printed" JSON format; open with a proper text/code editor; search for string "accept_languages" It should be there (with, I suspect, zh-CN as the first/default choice in the official Chinese version of 360EEv11); if this JSON block isn't there in your case (but it should be in an already used profile where the user has selected the English language pack), then you should create yourself a nested JSON block for it... I opted to display pages in the Greek language, if available, first - for example, the Google Web Store[GWS], so my manually modified setting inside the "Preferences" file looks like below: "intl": { "accept_languages": "el-GR,el,en-US,en" }, That code means that whenever the page hasn't got a Greek version available, the browser will fallback to displaying the American-English localization of it, and so on (if you add additional locales in that line) ... (Save the modified file while the browser is closed, then launch the browser anew and check for the effect of your new "custom" preference!) Hope I've helped
  24. Most sadly, the author no longer provides a 32-bit Windows installer, so Vista x86 users (like yours truly) are scr**ed ; last 32-bit installer for Hugin is from two and a half years ago, for version 2017.0 : https://sourceforge.net/projects/hugin/files/hugin/hugin-2017.0/Hugin-2017.0-win32.msi/download Merry Xmas to all (that observe it, since this is an international forum )
  25. @msfntor : Have you ever heard of the saying: "Half-knowledge is more dangerous than no-knowledge at all" ? Because this is what's happening here: you dismissing/discounting what I post by presenting your half-knowledge... For the rest of you (I take it you don't want to be fully informed yourself, else you'd have already taken the needed steps to do that before displaying here your ignorance...): Except for the Safari desktop browser on Mac OS and its (Safari's) versions on the rest of the Apple devices, no other major browser brand/engine natively supports (yet) direct playback of AppleHLS streams inside an HTML5 player; this is true for both Webkit (Chromium and forks) and Gecko (Firefox and forks) based browsers. You can verify this fact by taking the HTML5 test in your browser (look in the Streaming section). Be that as it may, AppleHLS streaming methodology is very popular with streaming sites, in its various formats (there exist iterations with unencrypted fragments, AES-128 encrypted fragments (HLSe) and fully DRMed fragments (Apple FairPlay DRM); also, while initially fragments were placed inside the MPEG-TS container, in later implementations fragments can also come inside the MP4 container; of course there's ample info pertaining to HLS streams on wiki and elsewhere, use your search engine and become informed yourself, don't just take my word for it... ) Media streaming sites wishing to deploy HLS streams to the majority of non-Safari browsers (not inherently supporting those streams in HTML5) while still staying away of Adobe Flash NPAPI/PPAPI (a technology soon to be obsoleted), have to resort to using a third party library in their embedded HTML5 players, most notably some form of hls.js ; through this library (sometimes wrongly called HTML5-player "plugin"), a browser which supports 1) native media playback in HTML5, 2) native h264/aac decoding (either via WMF+OS codecs or some other implementation), 3) Media Source Extensions (MSE), can perfectly play AppleHLS streams inside a specially crafted HTML5 embedded player that the streaming site loads in the browser. Now, let's revisit Twitter in @roytam1 's Nightly ESR 45.9.18 that started all this... In my copy of the browser, h264+aac decoding support is enforced via the Adobe Primetime CDM v15 (see previous posts of mine, media.gmp.decoder.enabled;true); the browser does support HTML5 native playback (media.navigator.enabled;true) as well as MSE (media.mediasource.enabled;true). When you first access the Twitter sample page in a tab, you can switch-on Web Console (CTRL+SHIFT+K) so you can inspect what the Twitter page loads inside that browser tab; since the browser meets all 3 requirements for HTML5 HLS playback, Twitter sends it first its HLS-enabled embedded player, in the screengrab below it's the URI that contains the *.PlayerHLS11.en.* string. Once that is fully loaded, it requests from the media CDN the appropriate HLS master playlist, it's the first URI that ends in *.m3u8; the master playlist is then parsed and a suitable (depending on network+bandwidth conditions) variant playlist is requested from the CDN; it's the second URI that ends in .m3u8 in the screengrab, as you can see it'll fetch a 320x568p video resolution; when that variant playlist is loaded and parsed, the CDN will start sending HLS fragments inside the MPEG-TS container, see the first one represented in the first URI that ends in *.ts (and so forth...). SO WHEN I POST THAT TWITTER SENDS TO FIREFOX ESR 45 "APPLE HLS" STREAMS, I have the knowledge and means to back up my claims; but I thought I would never have to post such verbose proofs to convince the half-ignorants, who only know how to dispute what already posted... It's a pity really , given my helping record in these forums... So be it then...
×
×
  • Create New...