Jump to content

Mathwiz

Member
  • Posts

    1,841
  • Joined

  • Last visited

  • Days Won

    50
  • Donations

    0.00 USD 
  • Country

    United States

Everything posted by Mathwiz

  1. Wow - I didn't expect even one reply to my puzzlement about the standard search icon having become the magnifying glass, let alone two! But yes, I am quite familiar with the image of Sherlock Holmes searching for clues with a magnifying glass. It's become (ahem) iconic. And yes, I'm sure that image is why a magnifying glass has become the standard icon for "search." But detective work is rather unique: you generally know where to search (the crime scene); it's just that many important clues are tiny, hence the need for a magnifying glass. For more mundane searches, though, such as searching for misplaced car keys, a magnifying glass is pretty useless. So when I see a magnifying glass, my first thought isn't of Sherlock Holmes searching for clues; it's of (duh) magnification! As @Ascii2 said, Which I think is the mistake filterlists.com made: you don't know their magnifying glasses mean "search" until after you click them!
  2. For better or worse, the magnifying glass and funnel have become de facto standard icons for "Search" and "Filter/Select," respectively, both on Web sites and standalone software. I always found the magnifying glass a bit puzzling. When I search for something, I certainly don't use a magnifying glass! I think this came from an old Windows animation that showed a magnifying glass being moved around when Windows was searching for a file, but that animation never made much sense to me either. Methinks a magnifying glass would be a better icon for "Details" or "Enlarge" than for "Search." To me, a flashlight/torch would've made more sense as a "Search" icon. (There's even a different old Windows search animation that shows a flashlight being moved back and forth.) But, I understand it's hard to come up with a good icon. The funnel makes more sense to me than the magnifying glass, although to be nitpicky, a filter is placed in a funnel - it's not the funnel itself! Still, I can at least understand the connection. My biggest problem with the funnel icon was that it wasn't immediately obvious what the icon is! It looked to me more like an upper-case Y! It took me some time to realize that it was intended to be a funnel.
  3. From the discussion @VistaLover linked to above: It puzzled me too. It sounds to me like the CSS was written to work even if aspect-ratio: 1 isn't supported; yet the browser compatibility testing script (at least they did it with feature detection vs. UA sniffing) insists on such support anyway. Sounds to me like the CSS and JS developers weren't communicating with each other. At a minimum, the script should provide the "modern" Web site if that's the only feature the browser lacks, perhaps with a "We'll stop supporting this browser soon" banner (with a clickable X to remove it) if there are plans to "upgrade" the CSS to require that support in the future.
  4. Yes, and it happened again to @DanR20! What I'm saying, though, is that if any extension crashes the browser, that has to be the browser's fault! Unlike Flash and other plug-ins, extensions don't have their own machine code. (Well, a tiny few do, but those "helpers" have to be downloaded and installed separately from the extension itself, so at least you're aware of them.) Extensions are just CSS, JavaScript, HTML, etc., and it's the browser's job to read and interpret those things, and handle any errors therein. Of course, as a practical matter, if an extension is crashing your browser, the best course of action may well be to remove and replace the extension, rather than waiting for the browser developer to fix the crash. After all, even if the crash is fixed, the extension still may not work properly. We're lucky (and a bit spoiled) to have @roytam1 able to deal with issues like this so quickly.
  5. I always think it's strange when an issue can be fixed with an SSUAO! But I see it all too often.
  6. I don't use NoScript either, so I'm no help with @DanR20's issue - but to be fair, we aren't using "their" browsers, so upstream wouldn't support any of us whether NoScript is in use or not! Thus I wouldn't let "upstream" dictate my choice of extensions. Maybe - but I don't think even an old, unmaintained extension should be able to crash the browser! Looks like @roytam1 may have found a solution though.
  7. Yeah, it's an arms race. Folks like gorhill, justoff, and yourself provide ad blockers; the ad-supported sites come up with ways around the ad blockers; you all update the ad blockers to block the workarounds; the sites come up with new workarounds; etc., usw. Anyway, you've done a lot of good work bringing modern ad-blocking to our browsers!
  8. The forum software appears to have scrambled that link; luckily, it works if you copy and paste instead of trying to click it! But maxVersion does seem to prevent CAA from offering an "install" button. You have to download it someplace, then drag-and-drop to the add-ons manager page. Not a big deal, but it is an extra step.
  9. Maybe @AstroSkipper can modify the source to retrieve the list from https://raw.githubusercontent.com/uBlockOrigin/uAssets/master/filters/filters-2024.txt instead. It does exist there. (Has only 2 filters in it so far, but the year is quite young.)
  10. I don't think that's it - the above resource doesn't exist, yet "uBlock filters - ads" loads without error in uBO 1.54 (in Edge 109). Perhaps that could help us narrow down the issue. Could you figure out which specific filter (in the working uBO) is blocking the YT video ads, by switching filters off and on? If identified, we could add it as a custom filter to the new version.
  11. That's a good question! My guess (that's all it is) is that elektroda.pl is downloading an HTML page, but (as is so typical nowadays) a blank one with a bunch of Javascript that downloads the "real" page data asynchronously and builds the page dynamically. And if the Javascript closes the connection prematurely, you get the "secure connection failed" message. That could be totally wrong but that's all I can come up with. But it would explain why @adata has problems a minute or two after successfully getting in. (BTW, an unsupported cipher returns a somewhat different error page - one I'm way too familiar with.)
  12. I'm not entirely sure what's going on, but as with Xitter, @mina7601's test implies there's more going on than just UA sniffing. If it were just the UA, it wouldn't matter whether you used Serpent 52, 55, PM, NM, or what-have-you. My best guess: first they check the UA, then based on the browser they think you have, they do other Javascript checks. If those fail, they just drop the connection, leading to the "Secure Connection Failed" error screen. If so, apparently our browsers are better at passing a "generic Chrome" test than a "generic Firefox" test! Edit: BTW, that Chrome 109 UA works with 360EE (Chromium-86-based), but not Serpent 52 (well, I haven't tried a clean profile yet; that's yet another variable to consider). Edit 2: Well, this is a first; for Serpent 52, the maximum Chrome version that works is 88! (The minimum version is 75.) If I put anything newer in the UA, "secure connection failed." I must admit I've never seen a browser rejected for being too recent!
  13. Well, it's certainly better for us! I'm just surprised that Web sites still use the technique, because it's easily fooled, and doesn't really tell them what they want to know. Chrome snobs? For example, only Firefox has the InternalError Javascript built-in function. Supported since Firefox 2! There doesn't seem to be a pref to turn it off either, although I suppose you could "undefine" it with a user script? And yes, that makes InternalError our second Mozilla-ism (after StructuredClone. StructuredClone can't be used for Firefox testing, though, because Chromium did adopt it eventually.)
  14. Well, the plot thickens.... The ridiculous UA "Chrome" does indeed get one into elektroda.pl, but an honest-to-goodness Chrome 109 user agent, Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.120 Safari/537.36, does not! Changing the Windows version to 10.0 didn't help either. Even the Firefox UA @VistaLover gave above doesn't get me into elektroda.pl! Nor does a UA consisting of just the word "Firefox." So far, only "Chrome" seems to do the trick. Edit: You can get away with this much: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome Safari/537.36 Just don't reveal that you aren't using the latest Chrome version! Apparently elektroda.pl wants to see "Chrome" but not a "too old" version. They also don't seem to mind Windows 7 (so I guess Supermium is OK?) This was all done using the latest Serpent 52, BTW, so obviously Chrome itself is not required; just the word in the UA....
  15. What is it with all these user-agent-based blocks all of a sudden? First Intel, then Xitter, elektroda.com.... I thought UA-based blocking was "old school" and everyone was supposed to be checking your browser's Javascript capabilities nowadays, but it seems UA blocking (and thence spoofing) is making a comeback for some stupid reason. (Although some - e.g., Xitter - seem to be using a combination; see @mina7601's recent post for example....) It's especially galling to see a ridiculous UA like just the word "Chrome" get past way too many of these stupid UA blocks, as if, "oh, you're using Chrome? Well, welcome; we don't even care what version you're running! But you over there, running Firefox - you'd better be running the very latest version, or a bas with you!" It's beginning to look like we should all just start spoofing Chrome 109 (last Win 7 version) even if our browser has no relationship with Chrome at all, and be done with all this UA nonsense.
  16. I get "Secure Connection Failed:" Toggling security.ssl.enable_tls13_compat_mode made no difference. Only difference is, I used the 64-bit version of Serpent 52. @adata, does your error page match the above (except possibly for language)?
  17. Thanks for figuring that out - although I must admit I'm puzzled that the minimum supported FF version depends on the Serpent version! It sounds like, if Xitter sees a FF version between 60 and 62, it performs some other Javascript check, which Serpent 55 passes but Serpent 52 fails. Perhaps there's a pref that can be set in those old FF versions to pass the check, so it allows those versions if the check indicates the pref is set properly. To be clear, I was referring to what I believed the Xitter SSUAO was intended to be; i.e., the SSUAO that didn't make it into last week's version. We don't know for certain what it was supposed to be, so I guessed. You're talking about the SSUAO that was actually in last week's version, which is known not to work. Edit: for what little it's worth, this week's Serpent 52 includes this SSUAO for Xitter: Mozilla/5.0 (%OS_SLICE% rv:102.0) Gecko/20100101 Firefox/102.0 Basilisk/52.9.0 ... which is close to what I guessed.
  18. Folks, you should not need to download and install FontAwesome 4.7 manually. The browser should download it (temporarily) from MSFN itself, based on MSFN's CSS. If that's not happening automatically, it's a bug when running under Vista (although downloading and installing manually is an easy workaround, now that you know which font is needed). @win32 has done a great job of making modern Chromium run under Vista, but we shouldn't be too surprised that it isn't quite perfect just yet.
  19. I'm pretty certain all browsers run background tasks. It's been a long time since most Web sites were entirely synchronous entities, where you press a button or click a link; the browser does something, shows you the resulting Web page, and then shuts down completely until you press another button or click another link. Probably like the '90's or so. Nowadays, many Web pages expect to send you notifications or update the page if something happens on their end, even without you doing anything on your end. Even MSFN. Nevertheless, it may be possible to force an app (such as a browser) to stop all processing when none of its windows have the focus. I'm not sure that's a good idea, but I wouldn't be surprised if there's a program out there somewhere that does that.
  20. I expect that @roytam1 will have the Xitter SSUAO fixed next week - in the meantime you can just add one yourself: Less certain about the intended Pale/New Moon SSUAO, but I suspect it doesn't matter as long as Xitter sees "Firefox/1xx.x" in the UA. (As I said I didn't determine the precise minimum version, but I did try 110.0 and it was good enough to get in, so 115.n should work.) @roytam1: In Serpent 55, unfortunately, there are other issues besides the SSUAO: twitter.com never finishes loading. (I tried both clean and "dirty" profiles; no difference.) Comes up fine in 52 with the above SSUAO though.
  21. A new SSUAO did make it into Serpent 55: Mozilla/5.0 (%OS_SLICE% rv:120.0) Gecko/20100101 Firefox/120.0 Basilisk/55.0.0 (Wasn't aware FF was up to version 120 already!) At any rate, the above SSUAO works, so apparently the "Basilisk" slice is ignored and Xitter just wants to see a "new enough" version of Firefox. I tried version 110 and it also gave me the sign up/in page; I didn't try anything older than 110. I assume the intended SSUAO for Serpent 52 is similar except it reads "Basilisk/52.9.0" at the end.
  22. Oh, come on. HTTPS Everywhere was developed by the Electronic Frontier Foundation, an American NGO. They have no connection to China. The answer to your question is right there in your question itself! HTTPS Everywhere was developed about ten years ago, when http: was still somewhat common and most browsers didn't upgrade http: to https:. EFF no longer supports HTTPS Everywhere or recommends its use. As you say, with "modern" browsers it's essentially redundant. But it may still be slightly useful for those of us using not-so-modern browsers, like 360Chrome.
  23. I think it's important to understand exactly what risks http: allows that https: deals with. First, there's nothing about https: that prevents the server from sending you malware, or receiving telemetry from you! Https: is not an anti-malware protocol. What https: does do is two things: It ensures you're connecting to the Web site you think you're connecting to It protects data from eavesdropping or modification by third parties (men/hackers in the middle) Those are both important functions, but if the Web site you're connecting to has bad intentions, https: won't protect you. At all. Conversely, there's no reason to think using http: makes the Web site any more suspicious than using https:. Using http: is stupid, because it gives third-party hackers a way into your traffic, but if the Web site is the one trying to hack you, there's no advantage in using http:. Why would the Web site want third parties monkeying with their data, even if they have bad intentions?
  24. It's possible I got this wrong, but if not, a "straight" FF UA is no good for Intel.com either: Mozilla/5.0 (Windows NT 10.0; rv:115.0) Gecko/20100101 Firefox/115.0 As @VistaLover pointed out, a SSUAO consisting merely of the word "Chrome" gets you in (although there are other issues once you get in) so apparently Intel has banned all non-Chrome-based browsers from their site. Speaking of SSUAOs, the default for Chase.com is in need of an update. Mozilla/5.0 (%OS_SLICE% rv:102.0) Gecko/20100101 Firefox/102.0 As discussed a while ago, Chase requires a minimum of 113.0 to avoid the "We'll stop supporting this browser soon" nag.
  25. You completely missed the point! If MSE can scan for the exploit on Windows, then surely widely-available AV software can scan for the exploit on Linux. Serpent 52 is patched. Try a pre-September version.
×
×
  • Create New...