This banner appeared when I came to TidBITS-TALK:
“This site will soon remove support for iOS and Safari versions 13 and below. A simplified read-only version will remain available.”
This is on my mid-2011iMac maxed out at MacOS 10.13.6
So it looks like I’ll be kicked off TidBITS-TALK effective 1 Jan 23 as I understand it since MacOS 10.13.6 only has Safari 13.1.2 and it can’t be updated to Safari 14. Am I understanding this correctly?
Correct, macOS 10.13 (High Sierra) can’t run Safari 14 or newer. High Sierra can still run the latest versions of Firefox and Chromium-based browsers so the age of your Mac will not prevent you from using TidBITS-Talk (you could also use it solely by email but I find replying on the web preferable).
Discourse’s About page includes their mindset about browser support:
Discourse is designed for the next 10 years of the Internet, so the minimum browser requirements are high.
Discourse supports the latest, stable releases of all major browsers and platforms:
- Microsoft Edge
- Google Chrome
- Mozilla Firefox
- Apple Safari
Additionally, we aim to support Safari on iOS 12.5+ until January 2023 (Discourse 3.0).
I found the thread on Discourse’s own forum about this change, Maintaining support for iOS 12 and iOS 13 until January 2023.
It seems forcing the read-only mode is not because Safari 13 lacks any specific feature, they don’t want to spend resources on testing older browsers and don’t want to be held back from using newer, widely-supported browser standards (Safari 12 probably does lack support for things they want to use). Rather than users sometimes discovering problems, they force read-only mode in browsers that don’t “cut the mustard.”
I suppose you could try using Safari 13’s Develop > User Agent > Other to make the browser “lie” about its version but that strategy may not work for long.
Bummer that they limit to only those four browsers. My installed alternates are Brave and Vivaldi.
If Chrome is supported, Brave is supported, since it’s based on the same code base.
Thanks for the explanation, @cwilcox!
Of course, there is a difference between “is broken” and “is not supported”. If the site is truly incompatible, you have no choice but to try a different browser. But if it is compatible (or mostly compatible) and just not supported, you can configure your browser to lie about it’s ID, so the server will send you the interactive content you want.
Here’s how to do it with Safari (screen-shots are for Safari 16.1, because that’s what I have, but I think this feature has been available for a long time):
In the popup, enter the user-agent string you’d like Safari to send. This is the primary way web apps identify your browser. Here’s the string from my Safari 16.1:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15
If you’d like to experiment with other user-agent strings, they aren’t hard to find with a bit of web searching. For example, here’s a page listing the latest user-agent strings for a variety of different browsers (which has links into their massive database of user agent strings):
So if you’d like to tell the server you’re running Firefox on Windows, or Opera 16.8 on BeOS or Mobile Internet Explorer on PalmOS or whatever else sounds like fun, you can give it a try.
Vivaldi, like the vast majority of alternative browsers these days, is also Chromium-based. As long as a browser maker is timely in their updates, how they handle HTML, CSS, and JavaScript should be the same as the current Google Chrome.
I’m strangely fascinated by the topic of websites and browser support, I recently spent way too much time looking at the impact of including a fallback for browsers that support min() and max() but not clamp() in CSS (basically Safari 11 & 12, they’re about as likely to visit a site as Internet Explorer these days).
Browser makers are moving away from updating their User Agent info to indicate what version they are. Websites can instead test what features the browser supports, either checking features the site actually requires or ones that “fingerprint” the browser.
For a very long time, the need to support Internet Explorer (IE) prevented websites from using newer web features. As its use has declined, some have complained that “Safari is the new IE” primarily because Apple has been slow to adopt web features but also because iPhones can’t use a different browser and have useful lives longer than Apple releases iOS updates for them (lots of Android phones run old versions but they can update Chrome independent of the OS).
In the past year, Apple has really picked up the pace in releasing Safari feature updates but sites that want to reach the most people will still need to keep older devices in mind. Safari 15 has added so many consequential web features, I expect there to be a great desire to drop support for older versions.
I’ve got over half a dozen browsers on my iPhone, including Chrome, Firefox, Brave, Edge, DuckDuckGo, and several others!
Thanks, David, I’d totally forgotten about the User Agent setting to spoof websites. In Safari 13.1.2 there are the following preconfigured:
Four versions of iOS Safari 13.1.3 (1 each for iPhone, iPod Touch, iPad, and iPad Mini
Microsoft Edge (I’m guessing for Windows)
Two versions of Google Chrome (1 each for MacOS & Windows)
Two versions of Firefox (again 1 each for MacOS & Windows)
and then there is the Custom option.
I’ll play around with it to see what happens.
Except that sites that check your browser user-agent don’t usually recognize Chromium browsers as Chrome. I use Opera as my primary browser, and I routinely get sites asking me to use a “supported” browser, even though I keep my Opera up-to-date with the latest stable releases, which are usually not far behind the latest Chrome release.
The reality is that an overwhelming majority of browsers are versions of Safari, Chrome, Firefox, or Edge. There are very few browsers being actively used right now that aren’t built on one of those four engines, and most “alternative” browsers are either Chromium- or Mozilla-based. I can understand verifying against older versions, but if your user-agent identifies as Chromium or Mozilla, your browser should be treated as Chrome- or Firefox-equivalent. It’s lazy web coding to do otherwise.
Sure, but on iOS they are forced by Apple to rely on the same WebKit engine as Safari. So if there’s an issue with the engine not being properly supported by a certain site’s code, just switching from Safari to one of those others isn’t going to do the trick.
Everything about how websites are rendered and operate in those other “browsers” is in fact using Apple’s WebKit. These apps can only do things differently around the web pages, handling tabs, bookmarks, etc. I suppose they can also do things that browser extensions are allowed to do but if a website needs a web feature that iOS Safari doesn’t support, it’s not going to work in those other apps either.
Even Microsoft Edge has also been based on Chrome for a couple of years. Internet Explorer has survived longer than non-Chromium Edge.
A site that doesn’t recognize current Opera as being based on Chrome shouldn’t be blocking browsers.
I have a question that really concerns me regarding web browsers being based on Google’s Chrome. How do we know that they don’t contain the same data harvesting code that Google uses in Chrome? Do the other browsers just install their GUI instead of Google’s or do they vet the entire code?
Google made the bulk of the Chrome browser into an open-source project called Chromium.
When Microsoft, Brave, and others use code from the Chromium project, they are able to review the code and make decisions whether to keep or remove any Google code that might raise privacy issues. How thoroughly and competently they do so, of course, depends on the developers themselves.
Thanks, Ron. So we have to just trust that they do remove any data harvesting code (assuming they find it). Well, that rules out Microsoft as I don’t trust them and never will.
