Jump to content

Mathwiz

Member
  • Posts

    1,728
  • Joined

  • Last visited

  • Days Won

    49
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. OK, maybe that makes sense to Micro$oft - but not to me! Why on Earth does their GitHub UI change if you sign in? I would expect the only change to be the words "Sign in" change to "Sign out." But, I guess not in Micro$oftLand. At any rate, given that Micro$oft has now made GitHub users jump through hoops just to "sign in," I doubt I'll bother myself any more with this. Follow-up: where are the defaults (if "Use Default" is checked) stored and can the defaults be modified?
  2. Hmm.... it seems I still have the old GitHub interface on St (both 52 and 55). IDK; maybe the trick is simply to use an old user agent? general.useragent.override.github.com;Mozilla/5.0 (%OS_SLICE% rv:None) Goanna/20170101 Basilisk/55.0.0 general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0 general.useragent.override.github.com;Mozilla/5.0 (%OS_SLICE% rv:4.8) Goanna/20170101 Basilisk/52.9.0
  3. Strange. It came up fine for me (latest Serpent 55). Even HTTPS Everywhere didn't interfere. It came up in plain HTTP. So I'm baffled why it doesn't work for you. Can you ping www.rw-designer.com? BTW, I would prefer an HTTPS version, if only to avoid the remote possibility of a MITM attack - but I don't insist on the absolute latest TLS 1.3 with 256-bit keys, GCM, SHA2, etc. This ain't a banking - or even an email - site! The move to make HTTPS ubiquitous was a good one, so that folks who do insist on their privacy don't fall under undue suspicion; but somewhere along the line religion took over, and now every lowly podcast has to be encrypted with the kind of security formerly reserved for nuclear launch codes, making HTTPS yet another obstacle to using older browsers, email clients, etc.
  4. I'm sure that's true. But there's no law against having both Googled and unGoogled versions of the same browser. And it's open source, so it doesn't have to be done by Supermium's author. Anyone can fork the code and apply the standard unGoogled Chromium changes. As delivered, no, they're not. But both can be made portable in the same manner as other Chromium browsers. With Firefox-derived browsers, portability is just a matter of telling the browser to store its profile directory in the folder it was launched from, instead of the fixed C:\Users directory the browser would use by default. That way, you can put the browser on a thumb drive, move it from PC to PC, and your extensions and settings all move with it. You can do this with a .cmd file (fka a .bat file) that you launch instead of the .exe, which is what Ed's suggestion does.
  5. I think you just need a portable loader: a small program that launches Mypal with a flag telling it to put the profile in its own subdirectory, rather than the default location on C:. @roytam1 wrote one for Pale/New Moon, but it's easy to modify for any Firefox-derived browser, including Mypal 68. I just changed the .txt file to launch "mypal.exe" instead of "palemoon.exe" and am attaching the loader below. As you can see it's pretty small. Extract both of the files in the .7z into the folder you have Mypal.exe in. Make sure Mypal 68 is not running, then copy your current "profiles" folder, which is probably something like C:\Documents and Settings\<your user name>\AppData\Roaming\Mypal68\Profiles\<some random name>, to the folder you have Mypal.exe in, and rename the folder "profile" (without the quotes) instead of the random name it has. Now you can put the whole thing on a thumb drive, plug it into any PC, and launch "Portable Loader.exe" instead of "mypal.exe." It will start Mypal 68 for you, using the settings in the "profile" folder on your thumb drive. You can also modify "Portable Loader.txt" to start mypal.exe with any other command-line arguments you want. Portable Loader.7z
  6. Looks like the OP's problem is solved. But to clarify for others: Version 109 is the last Chromium version to "officially" support Win 7, 8, or 8.1. I doubt you'll have any trouble opening Web sites with version 109, even though it's not the latest. Chromium 109 has also been patched to block the WebP exploit, if you're at all concerned about that. If you ever want/need a newer Chromium version, Supermium is an unofficial fork that allows the latest version (currently 118, I think) to run on Windows Vista and up (so 7, 8, and 8.1 too). You can make it portable too. However, Supermium currently doesn't provide an "unGoogled" version. (Someone needs to get on that!) The OP's issues with Amazon puzzle me. Amazon works just fine for me even in Serpent 55, which is one of @roytam1's XP-compatible browsers. Of course, on Win 7 you can use official Pale Moon or Basilisk, which should also work with Amazon. But I think unGoogled Chromium 109 will give most Win 7 users the best compatibility with modern Web sites.
  7. I think that makes some sense too - each open tab needs the chain of links followed to get to the current page so the back button (and forward button after you use the back button) will work. And saving those on disk preserves the chain even if the browser is closed or crashes. It even makes some sense to preserve the chain even after a tab is closed - that lets "Undo Close Tab" work without losing the closed tab's chain. But on many modern Web sites, you can rack up dozens, scores, even hundreds of clicks that lead back to the same page! (Think of a browser-based email interface, for instance.) Do we really need to keep every one of those in history, permanently? Is anyone seriously going to go back 100 clicks? There should be a pref to delete/reuse the oldest links once a chain gets over, say, 30 links. And consider this - you back up several pages, then follow a new link. The "old" forward chain from that point is now inaccessible; you can't get to it with the forward button any more. But it's still preserved in history (forever - or at least until your HDD dies - unless you use a history-purging add-on). I think FF combined the browser history and the chain of links functions into the same database, and that made it complicated to prune dead branches; so they just got lazy and said "keep everything," leaving database pruning and garbage collection to extensions. That's not necessarily a bad solution, but I suspect a lot of folks never even think to install such an extension. It would have been better if FF had included some basic database pruning/garbage collection functionality in the browser itself.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. I hope not - Serpent can certainly use all the speedups it can get! But in any case, at least it's fixed now.
  13. 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!
  14. 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/34.0.0.301 This is quite a mess.
  15. 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).
  16. 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?
  17. 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.
  18. 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.
  19. 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....
  20. 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)!
  21. 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.)
  22. 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.
  23. Thank you! I think you got it right, and upstream got it wrong, in this case. I wouldn't be surprised if they get complaints, since users can't reasonably set to false the way they implemented it. What's the point of a pref you can't change?
  24. But - but - but GitHub's site was written by professional Web developers! It has all those CPU-gobbling transitions! How could it not be interesting? Yes It has become a self-licking ice cream cone! Look at the massive boost in PC horsepower since 1980 or so. Back then, a 10 MB HDD was top-of-the line; today, it's more like 10 TB - a millionfold increase. RAM on the original IBM PC topped out at 640 kB, and some joker named Bill Gates said that was all anyone would ever need. Now, even a modest PC comes with maybe 8 GB - a several-thousandfold increase. The CPU clock in the original IBM PC ran at under 5 MHz; now CPUs are clocked at around 2 GHz - nearly a thousandfold increase. But are you getting a thousand times more work done on your PC now than you did 40 years ago? Is it 1000x faster or more responsive? Of course not! You have gotten more productive, but by nowhere near that much. I'd guesstimate that I'm about 10x more productive on today's PCs than I was back then. Maybe some of you are 20x or even 30x as productive, but nobody is 1000x more productive! So where did all that extra horsepower go? It's as if we took a cheap automobile and replaced the 4-cylinder engine with a nuclear thermal rocket - yet it only accelerates a little bit faster than before!
×
×
  • Create New...