Jump to content

Mathwiz

Member
  • Posts

    1,738
  • Joined

  • Last visited

  • Days Won

    49
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Actually I think @roytam1 should release a 64-bit build of MailNews. After all, as you said, Tobin releases 64-bit builds of Interlink, and modern hardware is all 64-bit nowadays. I think by the time you get to Win 11, there isn't even a 32-bit version of the OS available anymore. It may be simply that there hasn't been any demand for a 64-bit build until now. After all, a lot of his followers are still running on old hardware, and very few folks are using the 64-bit version of Windows XP. But he does release many other builds in 64-bit versions, so you might just ask Roytam and see what he says. I was just saying that, if a 32-bit program met my needs, I wouldn't let mere bitness stop me from using it! "It's perfect, and it runs fine on my system, but it's a 32-bit program, so I refuse!" That's where I would be getting a bit religious IMO.
  2. This vulnerability is interesting. The idea behind it is, someone sends you a malicious HTML document in (say) an email. You open it, thinking HTML documents should be safe - but the document uses Javascript to read other files in the folder the HTML document was downloaded to, and upload them to their server. For this to work, the malicious document has to know (or guess) the names of other files in the directory it gets downloaded to. If the email client (say) creates a unique directory for each email, then you're safe - the only thing in the download directory would be the email and attachments the attacker himself sent. But apparently some email clients and messaging apps aren't so careful, and put data from different emails into the same directory. Worse, they use easily-guessed file names, so a malicious HTML page can read your mail with some Javascript. This looks to me more like a vulnerability in certain email and messaging apps than a browser issue; nevertheless, Mozilla decided to "fix" the problem at the browser end, by treating every file:// URL as a unique origin. (I'm sure Chromium did the same.) That's why @luweitest's site didn't work when downloaded (until he changed the pref) - the browser blocked any Javascript from accessing anything in any other file! I presume it's also why @grey_rat recommended the "SingleFile" extension - if it had worked, it would've put the whole site in one big file, and the Javascript code would have been allowed to access it.
  3. Dude - the entire code tree is here: https://github.com/win32ss/supermium/tree/main/ The license is just the Chromium license, here: https://github.com/win32ss/supermium/blob/main/LICENSE GitHub users have forked Supermium already: https://github.com/win32ss/supermium/forks So I don't see what you think is stopping anyone from creating an "unGoogled" fork.
  4. I think that's news! AIUI when GMail announced the OAuth2 mandate, Tobin threw a fit and removed the early OAuth2 support he had written for Interlink. (Sort of understandable; since when did email providers get to require every email client developer to register their apps with them? Since Google, that's when.) @roytam1 kept it in his version, so there was a period when his version had (at least some) OAuth2 support but the official version didn't. At any rate, it sounds like Tobin eventually relented. No matter what you think of Google, you aren't going to make any money with an email client that doesn't work with GMail. So I guess OAuth2 is no longer an advantage for Roytam's version.
  5. This is a nitpick, but it's not x86 "emulation." Emulation is what you do when your CPU doesn't understand another CPU's instruction set: you use a program that reads the machine code written for the other CPU and does what the other CPU would have done, usually much more slowly. In contrast, the x64 processors do understand the x86 instruction set and execute x86 instructions natively, so x86 programs run at the same speed they would on a "true" x86 processor. Of course it still won't be as fast as x64 code, because you're manipulating data 4 bytes at a time vs. 8. So there's still a speed penalty compared to a 64-bit app. (Plus, 32-bit code also has that pesky 4GB addressable RAM limit.) So I can understand why you generally prefer 64-bit apps, even if your terminology was a bit wrong. OTOH, we're talking about an email client here, not an AI engine. How much RAM and speed could it need? Your preference for 64-bit apps is understandable, but I wouldn't make it into a religion.
  6. That's pretty good advice if it's just the cost of a new system that's holding you back. I think that's true for some. But I also know several XP users just prefer the XP UI to more recent Windows versions, and they don't even want to switch to Win 7 (to say nothing of 10!) I doubt they'd be very comfortable with a Linux UI; those folks may be willing to go to more extreme measures to stay on XP. There's also the intangible "thrill factor" of making XP (or even Vista or 7) run programs that Micro$oft, Google, etc. have tried very hard to keep them from running (like modern Chromium)
  7. I tried to install QT 7.7.9 on my Win 7 SP1 system, but for some reason it won't install! The prerequisite apps, Apple Application Support and Apple Software Update, both install (even if I uncheck the box to install the latter ) without problems. But installation of QuickTime itself always fails. The installer dialog just says "The installer encountered errors before the requested operations for QuickTime 7 could be completed." Not very helpful at all. Even unpacking the .exe and trying to install QuickTime.msi directly encounters the same problem. Running msiexec /i QuickTime.msi /l* QuickTime.log gives a bit more info. I get the same failure, but see the following in the log file: Action 21:32:25: CheckAndGrantAccessToRegistryKeys. Verifying registry key security Action start 21:32:25: CheckAndGrantAccessToRegistryKeys. CheckAndGrantAccessToRegistryKeys entered. Exception 80000003 executing DoCheckAndGrantAccess(hInstall, REGISTRYTABLE) Exception 80000003 executing DoCheckAndGrantAccess(hInstall, REMOVEREGISTRYTABLE) CheckAndGrantAccessToRegistryKeys exiting. ==>1723L DEBUG: Error 2769: Custom Action CheckAndGrantAccessToRegistryKeys did not close 6 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: CheckAndGrantAccessToRegistryKeys, 6, CustomAction CheckAndGrantAccessToRegistryKeys returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 21:32:25: CheckAndGrantAccessToRegistryKeys. Return value 3. Action ended 21:32:25: INSTALL. Return value 3. So apparently there's something funky about my registry. Of course it doesn't tell me which registry key(s) it's having trouble accessing. Oh, well, I don't really need it; I just wanted to try to help @luweitest....
  8. I tried 2023.10.12 today and it too works fine. So that narrows the issue down to one of the last two versions. I'll try the remaining version as time permits.
  9. @roytam1: I seem to have encountered a small bug in Serpent 55, version 2023.10.26. File downloads never complete when using the "open file" option. The file seems to download, but once it "should" be completely downloaded, the download freezes. The downloaded file shows 0 bytes in the temporary directory. You can't even cancel the download except by closing the browser. "Open file" is one of the conveniences FF-derived browsers like Serpent provide over Chromium-based browsers. It downloads to your temporary directory, opens the file, then (if the file isn't still open) deletes it for you when you close the browser, so it would be nice if this worked. Downloads via an add-on, such as DownThemAll, work fine. Serpent 55 version 2023.10.06 also works fine, so the bug seems to have crept in quite recently. Trying to download the 7-Zip installer is a simple way to reproduce the bug. On 2023.10.06 the installer downloads, runs, and installs 7-Zip. On 2023.10.26 the installer downloads, but then the download freezes as described above.
  10. I'm no Javascript expert, but I think all that code does is write out an HTML page. The key, I think, is in these snippets from the HTML page it writes: <OBJECT CLASSID="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" WIDTH="200" HEIGHT="16" CODEBASE="http://www.apple.com/qtactivex/qtplugin.cab"> <embed src=',Sound,' height="16" width="200" autoplay="true" PLUGINSPAGE="http://www.apple.com/quicktime/download/"> That looks to me like it uses Apple's QuickTime plug-in to play the audio - hence the message you reported getting. (It's also very old code: http: not https:.) At one time, QuickTime was very popular, but I haven't seen it used in years. Seeing this today is about as surprising as seeing a site that still uses Adobe Flash. Apple still provides QuickTime but no longer supports it, and the latest version requires Windows Vista or 7. If you have XP, I'm not sure where you might find the last XP-compatible QuickTime version appears to be version 7.6: https://support.apple.com/kb/dl762?locale=en_US Now, why VLC works, I have no idea, unless it emulates the QuickTime plug-in somehow. Nevertheless that sounds to me like your best option.
  11. Something I've long advocated for official Firefox, Chrome/ium, Edge, etc. Enough already with these silly "my version number is bigger than yours" wars! All it accomplishes is a "new" version every few weeks that barely differs from the previous one, except of course for whatever Googlisms or Mozilla-isms someone decided CSS or Javascript just had to have added this month.
  12. To be clear, "Xitter" was just a mashup of X and Twitter. I didn't intend to bring up geopolitics; only to use President Xi's name as a pronunciation guide Meanwhile, back in Serpentland: I wonder if a FF 52.9 user agent is all that's needed to dissuade Facebook from sending all the Googlescript that slows UXP down so badly? I've seen this elsewhere; e.g., office.com runs much faster, although you lose some features (and Micro$oft will show you an annoying "update your browser" banner )
  13. I just call it Xitter now. "Xi" pronounced as in Xi Jinping, President of China.
  14. Yes, I think that's the case; that's why I limited my polyfill to chase.com. Everyone else gets the built-in support, which I assume handles object types that JSON.stringify doesn't.
  15. Done. But there's so much output in the js console, including many from the console.log added to the structuredClone polyfill, it's really hard to know which one is the problem. And oddly, I can't seem to find the [Circular ~] part anywhere in the output. Perhaps try cloning this simple self-referencing array and see if it triggers a failure. I'm pretty sure @UCyborg's version looped on cloning an array: var arr = []; arr[0] = arr;
  16. One more polyfill from the 360EE threads: // ==UserScript== // @name Inject Object.hasOwn Polyfill // @version 0.0.1 // @match *://*/* // @run-at document-start // @grant none // ==/UserScript== if (!Object.hasOwn) { Object.defineProperty(Object, "hasOwn", { value: function (object, property) { if (object == null) { throw new TypeError("Cannot convert undefined or null to object") } return Object.prototype.hasOwnProperty.call(Object(object), property) }, configurable: true, enumerable: false, writable: true }) }
  17. Warning: this version predates the WebP buffer overflow bugfix by nearly two months. I tried running later versions (known to run on Win 8.1) with the help of VxKex, but had no luck. As a result, I'm sticking with 115 ESR. Of course, if someone's willing to download the source code, apply the WebP fix, and rebuild this nightly release, I'd have no objection to that.
  18. That's helpful. I had forgotten that the WebP bug wasn't even publicly acknowledged until 9/11. That makes 117.0a1 even less desirable, even if it (technically) runs. Sorry for the OT; we now return you to your regularly scheduled @roytam1 browser coverage....
  19. OT: MSFN's Win 7 forum has a link to a Nightly version of FF 117 that runs on Win 7. Presumably, it has the WebP fix, but I don't know how to confirm that for sure. 117 Nightly might not be worth keeping anyhow, though, by the time we get to 115.9 (or wherever the ESR release tops out), unless it happens to support some new Googlism or Mozilla-ism that becomes ubiquitous. Probably won't know either way for a few years.
  20. Well, I stand corrected. Chase is fine with SMS (or even a browser cookie, which isn't actually all that secure, since it can be moved from one machine to another relatively easily, at least on Firefox-based browsers) being the second "factor," and I think most US banks are similar. They want security, but not at the expense of convenience for their customers, and this is the compromise they arrived at. But it probably varies from country to country since banking regulations would also vary. Chase is also not very consistent. I have an old Android 6 phone. Chase long ago blacklisted their Android 6 app (presumably because Android 6 was deemed "not secure enough") but they're perfectly fine with Chrome 106 on that same phone. All that said, I still believe that making it a hassle to sign out and back in was a motivating factor behind Github's decision to require what I call "burdensome" 2FA. Yes, I get that message too, plus "caches is not defined." (At least it's not "define is not defined" as I was getting for a time at Chase!) But isn't that the M$ app store? Yeah, it'd be nice if it worked, but not much use for it on XP or Vista (or even Win 7, for that matter). OT: M$ "apps" are yet another step in the "Androidification" of Windows. So much of Windows 11 was redone to resemble Android (e.g., the new "Open With" dialog), I'm just wondering when Google and Micro$oft will officially announce the merger. Since I'm the one who raised the issue, I'll perform the test, although it appears @tvholic already tried without success. But maybe I can shed more light on the issue. Edit: Looks like the same message as before: Those fixes didn't seem to cause any harm, although they didn't fix the Chase issue. So they still may be worth including in the next release. OTOH, they may complicate things if upstream actually does fix the Chase issue at some point.
  21. Wow - I'm famous! It is admittedly odd that to date, no one has encountered this issue at another site. Self-referential Javascript objects can't be that rare; otherwise Andri Möll wouldn't have felt the need to create the code necessary for the fix in the first place. Since their merger with JP Morgan, Chase has been one of the biggest banks in the US, so I'd be surprised if no one with the necessary expertise has an account there. (Internationally, I understand, is a rather different issue.) Perhaps the polyfill I cobbled together from Möll's and @UCyborg's code, or at least the ideas behind it, could be rewritten in C++ for a native structuredClone implementation, and then tested by other Chase account holders who frequent the official PM forums.
  22. I suspect that may be the true reason for GH's particularly burdensome form of 2FA: to increase the "hassle factor" of signing in so much that folks just stay signed in, and as a result, any GH link you click is logged to your user ID. I never bought the excuse that 2FA using email or (especially) SMS just wasn't "secure enough." They're secure enough for banking and Web mail sites! But this is the sort of thing Serpent's container support can help with. You can have a GH container, with those signed-in GH cookies, while your "regular" Web browsing is signed out and GH-cookie free. (Just don't make the mistake of signing in to GH while not in a GH container tab - you'll have to go through 2FA - then it will mess your cookies up! If you need to sign into GH, right-click the GH link and open it in a GH container tab, and you'll already be signed in.)
  23. Finally, here's my stucturedClone polyfill specifically for chase.com. Should be good on both Chrome (prior to version indicated) and FF-derived browsers. // ==UserScript== // @name Inject structuredClone() Polyfill [98] // @version 0.0.1 // @match *://*.chase.com/* // @run-at document-start // @grant none // ==/UserScript== function stringify(obj, replacer, spaces, cycleReplacer) { return JSON.stringify(obj, serializer(replacer, cycleReplacer), spaces) } function serializer(replacer, cycleReplacer) { var stack = [], keys = [] if (cycleReplacer == null) cycleReplacer = function(key, value) { if (stack[0] === value) return "[Circular ~]" return "[Circular ~." + keys.slice(0, stack.indexOf(value)).join(".") + "]" } return function(key, value) { if (stack.length > 0) { var thisPos = stack.indexOf(this) ~thisPos ? stack.splice(thisPos + 1) : stack.push(this) ~thisPos ? keys.splice(thisPos, Infinity, key) : keys.push(key) if (~stack.indexOf(value)) value = cycleReplacer.call(this, key, value) } else stack.push(value) return replacer == null ? value : replacer.call(this, key, value) } } self.structuredClone = function (value) { return JSON.parse(stringify(value)); } This correctly deals with self-referential arrays and objects, but has other restrictions, so I use it only when a site (like chase.com) needs it.
  24. And here's @UCyborg's polyfill for structuredClone (Chrome before v.98; K-Meleon, New Moon 27, FF 45; not needed on UXP-based browsers or Serpent 55) // ==UserScript== // @name Inject structuredClone() Polyfill [98] // @version 0.0.1 // @match *://*/* // @run-at document-start // @grant none // ==/UserScript== if (typeof self.structuredClone !== "function") { self.structuredClone = function (value) { if (Array.isArray(value)) { const count = value.length; let arr = new Array(count); for (let i = 0; i < count; i++) { arr = self.structuredClone(value); } return arr; } else if (typeof value === "object") { let obj = {}; for (const prop in value) { obj[prop] = self.structuredClone(value[prop]); } return obj; } else { return value; } } } This will fail if an array or object property references itself, but works well in most cases.
×
×
  • Create New...