Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won

  • Donations

    0.00 USD 
  • Country

    United States

Mathwiz last won the day on June 18

Mathwiz had the most liked content!


About Mathwiz

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mathwiz's Achievements



  1. I think that makes sense, except ... if FF is written to display only the last visit to a given site, why then does it store previous visits at all? Seems like a huge waste of storage - not to mention a "treasure trove" for anyone with access to your PC who want to check up on you. (Think boss, spouse, police in countries or states with poor human rights records....) There can be a big difference in how much trouble you get in for visiting a Web site once vs. visiting it repeatedly, and I suspect most FF users are completely unaware that their history includes all visits to a Web site, complete with time stamps! I know that you can avoid all this by using a private browsing window, but you may not think a site you're visiting is a problem - until you find out your boss or the cops disagree! Methinks it would be best for FF to err on the side of caution and only record the last visit to each site, unless they have some compelling reason not to.
  2. Since 86 won't be patched, I think this is the best solution. Dixel's fix tells Web sites you don't want WebP, and if a server gives you a WebP image anyway, Proxomitron dumps it. Of course a Microsoft-owned Web site is very unlikely to host a malicious WebP image. But that was just an example to show that a (possibly malicious) WebP image could be served even with Dixel's fix. I agree with your decision (if not your reasons). It should be up to each individual to evaluate the risk and act according to their own best judgment. If someone wants to take preventive measures, @Dixel has published his patch and Proxomitron is readily available. Personally, I only use 360EE for a few sites, so I haven't taken any precautions myself. If I used it for general browsing, I'd probably be more proactive. On patched software, I see no reason to distrust WebP. I know some don't like it but there's nothing inherently wrong with the format. It's just that, due to the complexity of decoding it, everyone has been copying Google's open-source decoder, which is actually quite efficient - it just happened to have an exploitable bug. As I said on Roytam's thread, I don't think in the least that this bug was due to ill intent - anyone writing code (me) can make a mistake like this. I wouldn't categorize these concerns as "propaganda" though - that sounds as if we're being a bit dishonest by raising them.
  3. For example, not long ago we discovered.... The only known way to stop Bing from sending its home page image in WebP format is to pretend (via the user agent) to be Internet Exploder! Then you'll get a JPEG, but otherwise, it'll be WebP irrespective of the image format header.
  4. Proxomitron is a good solution, although sites affiliated with Google (e.g., YouTube) will be very image-poor. Dixel's fix changes the HTTP header that's sent on image requests. It tells the Web server which image formats your browser will accept (and also which ones are preferred). Unfortunately many Web sites don't respect the header and send WebP images anyway. Certainly a malicious site wouldn't respect the header! So, Dixel's fix isn't a sure-fire WebP block by itself. And since the 360EE browser does accept WebP despite what the http header claims, you can still be victimized. But, both solutions can be used together! Proxomitron can block any WebP images, and changing the header should tell the server to send a different image format, so you don't lose your images altogether.
  5. I hope not - Serpent can certainly use all the speedups it can get! But in any case, at least it's fixed now.
  6. Good to see @roytam1 once again found the problematic commit (presumably, "Make Gecko Media Plugins optional when not building EME or WebRTC" - it must be that one, which he couldn't port to St 55, because e10s is still working for me.) I know Moonchild doesn't believe in those things, so PM is built without them, but St and (I think) Basilisk are built with them, so whatever this massive commit is supposed to accomplish is irrelevant to St/Basilisk anyway. (Of course, EME and WebRTC are themselves pretty irrelevant to St/Basilisk nowadays, since Google has blacklisted the only Widevine versions they'll run, nobody uses Adobe Primetime anymore (except perhaps as an alternative h.264 decoder), and their WebRTC implementation is very outdated.) Roytam1 will probably have to add testing for e10s breakage to his weekly checklist. I'm actually rather surprised that it took this long for e10s issues to start appearing! But the big test is yet to come: what will we e10s fans do when a commit is released that we really need (because, say, it fixes some increasingly common Googlism), but which also breaks e10s? There are things I like about Google, and lots of things I don't, but I'm not that suspicious of them! But as with the above issue, what surprises me most is how long it took for someone to realize there was a problem! I think I read that the bug was introduced when the WebP decoder was optimized for speed back in 2014!
  7. GitHub has a mirror of libwebp at https://github.com/webmproject/libwebp. You should be able to pull updated code from there. What's scary about it is, you don't even have to download and run anything. Just visit a Web page with a malicious image and bam - you're infected. And a malicious image could even be on a legit Web site if the site owner were hacked. Browsers generally trust images and download them automatically; after all, downloading an image should be safe (even if not safe for work). Heck - someone could just email you a malicious WebP image. Most email clients will block connecting to the Web to download an image, for privacy reasons, but if the image is embedded in the email itself and your email client isn't updated, you're screwed. Right. Per Mozilla, Security Vulnerability fixed in Firefox 117.0.1, Firefox ESR 115.2.1, Firefox ESR 102.15.1, Thunderbird 102.15.1, and Thunderbird 115.2.2 (the ESR 102 version fixes are for Win 7/8/8.1 users) Yes, I saw that and downloaded it. LibWebP 1.3.2 has the fix. Unfortunately it didn't help me with GIMP. Their DLLs are somewhat different, so I couldn't just copy over. Cygwin just updated their libWebP to 1.3.2. Theirs might work with GIMP.</offtopic> One more. Not many folks use the Adobe Flash browser plug-in any more, but if you do, you'd better update it too: https://gitlab.com/cleanflash/installer/-/releases/ This is quite a mess.
  8. Yeah, this is crossing-the-streams bad. It doesn't just affect browsers, and it doesn't just affect Windows. I just updated two iOS devices, but my old Android 6.0 phone appears to be SOL. I disabled image.webp.enabled in FF on that phone. Despite recent withdrawal of support, Win 7/8/8.1 users are mostly OK. M$ Edge 109 was updated (and the update was somewhat spookily pushed to my PC); I haven't checked but I assume Chrome 109 was updated too. Mozilla published an update to FF 102 ESR. And official Pale Moon was updated. Outside the browser world it's tougher. I found no Win 7 update for GIMP, or libwebp-7.dll, the afflicted code library. Edit: IrfanView may have an updated version. I'll check it out. On XP/Vista, our FF/PM-based browsers are updated thanks to @roytam1, but Chromium users won't be so lucky. Supermium was just patched for Vista users though (version 118).
  9. Will we 360EE users have a fix for the libwebp vulnerability? I suspect not. The "big boys" are only fixing the latest versions of their browsers - and they all require Win 10 now. Edit: Despite lack of official support, this vulnerability is so bad that Edge and FF (and Chrome, I suspect) have published fixed versions of their last Win 7/8/8.1 versions. Thorium (for Win 7/8/8.1) will probably get a fix, but XP/Vista users are SOL. Edit: NHTPG noted that Supermium runs on Vista and is at the current version (117) so Vista users will probably get a fix too. Edit 2: Sure enough, version 118 is out now with the fix. There's no "unGoogled" version of either browser yet, though. An alternative might be to disable WebP images in the browser entirely. That's possible in FF but not in Chromium; WebP is Google's own creation (and not a bad format, despite this vulnerability in their decoder). And I bet a lot of Web sites would look terrible without WebP image support anyhow! A better solution would be to scan downloaded WebP images and block any that would overflow the buffer. That would slow things down, but wouldn't block legit WebP images. Maybe Proxomitron could be leveraged somehow?
  10. Hmm ... looks like GIMP is likely affected too - I'd better check for an update. BTW the above link does not open correctly in my browser (St 55). St 52 didn't work for me either. I just get a pageful of Javascript source code in both browsers.
  11. It does work with St; I use it myself. PM/NM will require the legacy version, of course. Straw man! You know that's not the same thing. The idle loop is there because the CPU has to be doing something even when there's literally nothing to do, so the lowest-priority process is a simple loop that doesn't take cycles from anything else running. Your Web browser isn't the lowest-priority process in the system! Even if animations are (hopefully) the lowest-priority task within the Web browser, they still take CPU cycles away from non-browser tasks. Your computer does more than just run a Web browser, right? Chromium can get around that (don't know if it does, but it can) by creating a low-priority process for animations, but FF 52/53-based browsers like PM and@roytam1's are stuck. Even e10s doesn't create a separate, low-priority "animations" process. To be fair, there are negative "side effects" from setting layout.css.animation.enabled to false, but they're mostly minor. Spinning "wheels of death" don't spin while you wait, for instance. I can live with that.
  12. Although I'm not very concerned about the lack of sec fixes, for me the bigger concern is, as we go forward, further breakages like the one in the 20230902 build. Since e10s is a "relic" that hasn't been part of "official" UXP in ages, MCP obviously won't be testing their changes in that environment! This time, it was easy to revert the change that broke e10s. Next time we might not be so lucky, and I'll have to start running the 64-bit version so I can have one gargantuan process....
  13. Good to learn that GPU acceleration works, but "little below 70%" is still super high for something purely cosmetic! Luckily we now have: To clarify, the new prefs @roytam1 added are: layout.css.animation-long-names.enabled layout.css.transition-long-names.enabled It appears these prefs are the equivalent of MCP's prefs (setting them false breaks MSFN), and the prefs with the original names: layout.css.animation.enabled layout.css.transition.enabled ... are @roytam1's from the 20230825 version of Serpent that have a narrower effect (MSFN basically OK). So good work! Now we can have either, or neither, as preferred (which is what prefs are supposed to be)!
  14. Well, I stayed on 20230825 for reasons unrelated to e10s, so I didn't realize that e10s is essentially broken in 20230902 - at least if you want to upload files. I thought it was specific to the web site @Mehmed mentioned initially - and I thought that site was broken on all browser versions if e10s was active! I did suspect @roytam1's fix would cause a memory leak - I didn't realize he's reverting not only his own fix but also the change that made a fix necessary in the first place (well, since I didn't realize the breakage was specific to 20230902). Moonchild has strong opinions, one of which is that e10s is always a bad idea. And, to be fair to him, it's not particularly necessary if you're running 64-bit code on a 64-bit OS, where your address space is essentially unlimited. But I suspect most users of @roytam1's browsers are running the 32-bit versions, and e10s is much more helpful in that environment, at least if you have lots of RAM and/or a fast swapfile device. (It does have its downsides though.)
  15. Of course MCP hasn't bothered porting e10s fixes to UXP. It would obviously be a pointless waste of time for them to do so, since neither Pale Moon nor official Basilisk (no longer a MCP property, but still dependent on UXP) supports e10s. As a satisfied e10s user, I'm not terribly worried about the security concerns; UXP browsers using e10s are a pretty tiny target for hackers! But that (and Mypal 68) aside, @Mehmed appears to have discovered the first Web page that out-and-out crashes UXP under e10s. @roytam1's unsuccessful fix attempt suggests to me that the Web site is causing UXP code to run that destroys an object in use by other processes. I'm guessing a true fix would require maintaining a count of processes using the object in question so that only the final process calling that code would actually destroy the object. That may require more extensive surgery on UXP than we were hoping for. As a workaround, since the problem currently affects only a single Web site, how about a bookmarklet? It's quite a bit above my level of expertise, but the Classic Add-Ons Archive has some Javascript code (intended for Waterfox Classic) that I think could be borrowed to open the problem Web site in a single-process browser instance.

  • Create New...