Please standardize your version number format #1253
Comments
|
Thanks. With or without standardisation, I think that the project should:
– four, most recently (https://github.com/MrAlex94/Waterfox/releases/tag/2019.10-classic, https://github.com/MrAlex94/Waterfox/releases/tag/2019.10-classic-1, https://github.com/MrAlex94/Waterfox/releases/tag/2019.10-current and https://github.com/MrAlex94/Waterfox/releases/tag/2019.10-current-1). Whilst I agree with the logic of 'soft and hard' launches: significantly changing the code without changing the version is likely to be troublesome, sooner or later. I expect to find in-the-wild copies of
Additional background: |
|
Meta, tracking: #582 in particular #582 (comment)
– and four days ago, https://www.reddit.com/comments/dmmfxv/-/f5nwg5c/?context=1:
|
|
Thank you, Graham. Another issue was filed a month ago, about Waterfox identifying as Firefox/2019.10: Another Firefox derivative (Pale Moon) carries unique version numbers, but their on-screen and useragent version numbers match, and they note which Firefox ESR they base their code. In my opinion, this is the best way for Firefox derivatives to identify themselves, as sites that don't recognize the derivative can still determine whether the underlying Firefox code is recent or obsolete. Apple and Microsoft use "friendly names" for marketing purposes, but list version numbers in their useragent strings. I would be okay with Waterfox following this example as long as the version numbers shown on Wikipedia match the version numbers in the useragent string. In contrast, the TOR Browser intentionally claims to be the current Firefox ESR (rather than adding a TORBrowser/xx.x token). While this isn't the most ideal -- once the mainline Firefox reaches 73, Firefox/68.0 appears to be 5 versions (6 months) out of date -- it does save the "obsolete browser detection" authors from maintaining a unique regex; TOR Browser automatically falls back to Firefox detection code. Just being honest, my code (as well as most other sites that run similar code) only looks at the major version number (Firefox/70, Chrome/78, etc). The issue is that PHP's regex tries to match from the end of the useragent string, so if I'm looking for Waterfox/xx (two digits) but Waterfox presents as Waterfox/xxxx (four digits) then I need to update my regex. Otherwise my code will skip the Waterfox token and match on Firefox/56, which looks like a bot since a human should have updated to FF 60 if not FF 68 or 70 by now. |
This is what Waterfox Current does, as Waterfox Current is based on Firefox ESR. |
And you've no idea how many complaints I receive from TOR Browser and Firefox ESR users, because Firefox doesn't update the ESR useragents to show 68.1, 68.2, etc. And I can understand your point of view: if Firefox doesn't update the UA, why should Waterfox (or TOR or any other ESR derivative) update theirs? That's WHY I specifically look for a Waterfox (or Pale Moon, or whomever) token in the UA, so that I don't mistake Firefox derivatives for spambots or other unwanted connections. :) |
|
A brief retrospective … IIRC the notional https://www.reddit.com/comments/d79h2l/-/f1ulnxa/ reminds me that I was still, occasionally, experimenting with (but not recommending) I'll probably never rediscover the origin of the Firefox 56.2 pretence, and Rabbit is no more, so I'll no longer try this.
This is very useful to know, thanks. |
|
Graham, I took a quick glance at the links you offered earlier in this thread. Between them and the pinned issue about useragent switching, I believe many of the issues could be solved with a few simple changes. For Waterfox Current (based on FF 68.0 ESR), use the 2019.10 version format:
For Waterfox Classic (based on FF 56 non-ESR), stay to the established FF format:
Update the version numbers on the Download page, then post a blog entry announcing the revised version formatting (so you have a quotable (linkable) source for Wikipedia):
Yeah it's a bit of work to do this, but it'll solve sooooo many compatibility problems going forward. :) |
A pretence of #882 (comment) the second non-checked checkbox and "it might be tempting to drop from |
Do you have a useragent-switcher addon that would allow you to test some of the "fake" useragents I suggested? If YouTube and the other sites magically allow Waterfox/56 to work (when it claims to be Firefox/68 or higher, instead of Firefox/56), I see no harm in doing this as long as the Waterfox/56.x token is present and accurate. I'd do a few tests myself, but I'm on Windows 7 32-bit ... the currently-available versions of Waterfox are x64 only, I can't install them. :( If it turns out that claiming a fake Firefox/68+ causes code problems (sites send the wrong stylesheets or assume functionality Waterfox Classic doesn't have), then I agree, Waterfox Classic shouldn't send the Firefox/68+ token. But that's why I suggested this be toggled on with a "compatibility mode" button, so that Waterfox Classic users won't be sending this unless necessary. :) Edit 1: I'm sorry, I didn't watch your videos before responding. Let me take a closer look at them, I may update this in a few minutes.... Edit 2: Okay, I see how YouTube drops the icons at the top and the suggested videos along the side, when you spoof a later Firefox useragent. But if YouTube works with a Firefox/56 useragent (as your video appears to prove), then you wouldn't need to send a "fake" Firefox/68+ useragent to begin with; you'd stay with the default Waterfox Classic useragent. I withdraw my "fake Firefox/70 useragent" idea. It makes more sense for anyone who can't use Waterfox Classic on a website, to instead use Waterfox Current. |
i only can 2nd this. it is very important to see in the version number if its the classic or the current build. i made a backup before i installed the update, because it was not clear which version will get installed. |
|
UA strings aside, for now … Version identifiers
+1 My current thinking – without knowing all technical consequences – is to echo (in future) the format, or something like the format, that was seen for tagged releases in October. Compare with https://github.com/MrAlex94/Waterfox/releases/ At their simplest, without variation from the October format, assuming November 2019 pre-releases (soft) and releases of both Waterfox Classic and Waterfox Current beta:
Defocusing from Waterfox Project and Mozilla: I should expect any version of beta software (for testing) to include Mozilla uses channels, which is fine for their user base however I'd not want to see the word channel in (for example) an About Waterfox Current dialogue. Whilst the Waterfox user base includes a good proportion of technically savvy people, let's not forget the 'average' end user, who might be disinterested in (or off-put by) geeky codewords. Waterfox Project has its branches – again, not a word that I'd like to see in an About dialogue. Colloquially I sometimes use the word flavours – i.e. two flavours of the Waterfox application, which probably makes some people cringe but it's to avoid using words such as channel or branch in an environment (e.g. Community Support) where readers might want minimal jargon. All things considered I'm toying with this, for example:
More specifically, tying that to a notion of separate web pages (one starting page for Waterfox Classic, one starting page for Waterfox Current):
|
With all due respect, I opened this issue to address the UA discrepancy. Whatever Waterfox does in the human-readable About box is a different concern, as YouTube will never see the About box. I can tell you that if Waterfox starts adding dashes and letters (such as -classic) to the UA, you'll cause a LOT of problems for sites that are only looking for numeric values (such as 56.4). PHP will log each access from Waterfox/2019.11-classic as an error that the site administrator (or their IT team) will NEVER be able to track to the UA, it'll only track back to the script on the webserver. Which, on sites that run my software, will look as though MY script is buggy. Try running this UA through Udger and some other UA identification sites: You'll find that the dash and anything after are dropped ... which makes this form of versioning useless for sites that need to display different code for Waterfox Classic (FF 56.x code) and Waterfox Current (FF 68+ code). That's why I suggested staying to the older version format for Waterfox Classic, and limiting use of 2019.xx to Waterfox Current -- so that websites that recognize the Waterfox token can know what to send to your browser. This also allows the human-readable About box to display "Waterfox Classic 56.4" or "Waterfox Current 2019.11" without causing anyone any problems whatsoever. :) |
Apologies. Focusing on the subject line, I lost sight of the context. My previous comment was for version number format but in no way a suggestion re: UA strings. |
|
Please do let me know what sites are running your script so I can block them preemptively because relying on a UA string for anything is naive at best. It says absolutely nothing about what the browser actually allows and frankly as someone who uses lynx a lot, it's damned annoying to get blocked by such silly sites. There's literally nothing nefarious about not using a string YOU expect. Expecting Tor to identify itself as a tor user is just .. stupid. Proper thing to do is detect what features you need |
|
@h1z1 thanks, your frustration (with lynx etc.) may be understandable but with respect, it doesn't help to progress this issue. I see past discussions of pros and cons of reliance upon UA strings; somewhat interesting to follow but they don't alter the reality of some sites choosing reliance of this type. |
|
No, actually it does help. The request is lunacy. |
You didn't read my first post. I'm not attempting to detect browser features -- I'm attempting to detect spambots and content scraper scripts. Sadly, malicious bots don't declare themselves as bots. They claim to be common browsers, such as Chrome and Firefox, to try to get past software like mine. This is why I need to scrutinize the useragent for small details such as version numbers that don't correspond to known or supported releases. I opened this issue because Waterfox 2019.10 isn't sending consistent version numbers, and I need to know whether to look for 2019.10, 56.x, or some other value ... or if I should forget about Waterfox and rely on the Firefox version instead. |
I did read your post, you're not reading mine. I never said you were trying to detect features, I said you aren't but SHOULD..
Which is unbelievably silly. At the very least it prohibits self compiled/custom spins which may or may not have the same features enabled and thus SHOULD have different versions. Or users who copy a URL between different browsers? You're going to trigger on them as bots? As I said, lunacy. Are your unsuspecting users aware of this? To be completely clear, you're not the only one whom does this. UA snooping has been around since at least Mosaic. There's a reason it's unreliable. |
|
Due to my heavy reliance on various old-fashioned XUL extensions that so far haven't been replaced by web extensions with equivalent functionality, I'm using Waterfox Classic (always u[dated to the latest release, which as of today is 2020.07.1). Like others, I still come across annoying websites that don't support Waterfox, for whatever reason. I don't know if the following is an over-simplistic KISS approach, but here's my concept, goofy or otherwise ... Would it be possible to add the capability for a Waterfox Classic user to select the reported browser version from a drop-down list in an attempt to allow Waterfox to be recognized/accepted by such websites? My idea is that once you've tried to get such a website to accept Waterfox and done your business on that site, you would simply use the same drop-down list to reset to the latest version (maybe an item in the drop-down would be "latest version" or there could even be a button to click to do so). This may be unrelated or only partially-related, but I'm also am finding that some websites (here in Australia, anyway) that have location awareness features are either reporting me to be in the wrong suburb or are reporting that the website's location awareness feature is not supported for the browser being used. (Just a few minutes ago I had to switch over to Chrome browser to make use of a site's location detection feature.) Am I confusing issues? Any general comments on this? |
|
@NotesTracker A year late, but I can recommend |
|
@Megalomaniak, thanks for that, better late than never! I had seen references to UserAgent but didn't know how to tweak it. One website that I use fairly frequently is rottentomatoes.com. Some months ago, after having no issues for years, I found that its search bar disappeared from the red header bar (at top) and I now have to switch to Chrome or Edge to be able to use the search function. I was hopeful, however using User Agent Switcher for Windows / Firefox 83 (or any of the other Windows selections) plus overriding for the Rotten Tomatoes domain makes no difference, I still don't see the search bar. Any suggestions? |
|
Here's a screenshot of the search bar in Rotten Tomatoes |
|
Can confirm, according to the web console it's an search-algolia js library that fails because of unexpected type error: |
|
@NotesTracker Note that it stems from missing a feature introduced in FF 63: A polyfill might be able to work around this. |
|
So, if "it stems from missing a feature introduced in FF 63" I wonder what chance there is that it will be fixed. (Always hopeful.) |
|
As I said, a polyfill might be able to fix it. I have the polly add-on installed that for a while was bundled along with waterfox classic and enabling some polyfills did get the searchbar rendering. I didn't test any further though. |
I realize this project is based on Firefox, and I realize that you'd like websites to treat Waterfox as though it IS Firefox.
But here's the issue: some sites have "obsolete browser" code that examines the user-agent Waterfox (and Firefox, and Chrome, and IE, and and...) provide when they connect ... and Waterfox isn't being identified as equivalent to a current version of Firefox. If you're lucky, the site will nag your users to upgrade to a newer version ... but some sites will simply block obsolete browsers from seeing the site at all.
I am the current developer of ZB-Block (a website protection script), and ZB-Block has an optional module that blocks spambots and content scrapers that claim to be older browsers. For my code to work reliably, I need to be able to determine CURRENT version numbers from an official download site or a Wikipedia entry.
Per your download page, your blog, and Wikipedia, the current version of Waterfox is 2019.10. But on installing Waterfox two hours ago, I found that Waterfox Classic's useragent reports as 56.3, and Waterfox Current doesn't claim Waterfox in the useragent at all!
Classic: https://imgur.com/3QVtlsR
Current: https://imgur.com/E8qCM8L
Wikipedia: https://en.wikipedia.org/wiki/Template:Latest_stable_software_release/Waterfox
Your blog: https://www.waterfox.net/blog/waterfox-2019.10-release-download/
Please, PLEASE standardize your version number. If you want the useragent to show 2019.10 to match your blog, download page, and Wikipedia entry, then change your useragent already. If you want the useragent to show a Firefox-like version number, then list the useragent's version number on Wikipedia and your website, so all the websites that identify browser versions (Udger, WhatsmyUA, etc) can keep THEIR code up to date.
The text was updated successfully, but these errors were encountered: