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).
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.
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):
Enable the Develop menu, if you haven’t already done so:
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):
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.
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.
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.
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.