I think security is definitely an important point that often gets glossed over when browser forks are brought up; while still necessarily adding a patching delay, simpler modifications like Icecat or ungoogled-Chromium are (in theory) capable of staying safely fairly close to upstream; by contrast, something like Palemoon/Goanna will require much more active development to stay secure, even if simply to review newly discovered vulnerabilities from Firefox/Gecko, and see which still apply to it.
So long as Apple maintains its not-invented-here mindset, WebKit can act as somewhat of a brake on the feature gluttony that we see now. Apple is in a perfect position to avoid or delay any feature creep, since it would prefer anything overly complex be done in native code, both for performance, and for the potential of getting a 15-30% revenue cut if the App Store is used (or required as on iOS).
Furthermore, Apple is a large enough target that security researchers remain interested, and it has the resources to patch what those researchers discover.
Also, WebKit already works with open source projects, we can even see links to Epiphany (AKA GNOME Web), WPE (embedded), and WebKitGTK+ on the official WebKit site’s download page: webkit.org/downloads/
Re-read the sentence, carefully. The problem is not that Apple falls behind in feature set, which is desirable. The problem the article points out is that (old) Edge and Webkit / Safari fall behind Blink and Gecko in market share, which further tightens the browser duopoly grip. Google at this point is subsidizing Mozilla just because they know they will get under investigation for anti-trust with a browser monopoly, because, while open source, Chromium is developed under the Google umbrella under close surveillance. Google decides what new technology gets implemented in the modern web, w3c at this point is just adding google technologies as protocols for the web.
The browser duopoly is only growing stronger, too, as Microsoft drops Edge and WebKit falls well behind its competition.
I do not see how this is true at all; something like StatCounter shows Safari at more than twice the marketshare of Firefox for every continent (or whichever collection of countries StatCounter treats as Oceania along with Australia). Even if it were not, being the built-in browser of a widely available and frequently-used commercial product line forces developers to care about its implementation.
StatCounter - All User Agents
World
Asia
Europe
North America
(Oceania)
Africa
South America
Chrome
65.13
73.52
60.48
50.76
52.44
65.86
82.59
Safari
18.64
11.65
19.29
34.11
32.72
11.2
6.07
Firefox
3.45
1.92
6.33
3.53
3.22
5.64
2.43
StatCounter - Desktop User Agents
Here is the same table’s worth, only for desktop; note that NA and Australia/Oceania still have Safari at more than twice the marketshare of Firefox, Asia sees roughly marketshare parity, Europe favours Firefox slightly, and Africa and South America heavily favour Firefox:
I think it is more a case of, if Google stopped supporting Firefox, the users would generally move over to Chrome, rather than safari, (given the choice) and the market would have a single huge player, and a small side note of safari. Bearing in mind, not all Apple users use safari, and almost all the safari users are in Apple, it locks it to a small portion of the market. Apple might be a reasonable size in NA, but ROW not so much.
Edit: wow, Australia heading towards 45% iOS smartphones. There might only be 25m of them, but they like it fruity down under!
My point is that Google cannot as easily drop support of WebKit because it is a built-in browser for a widely-used commercial product.
As a third-party browser, Firefox coexists with a built-in browser that Google can treat as a fall-back if it does not want to bother with Gecko. As a built-in browser on Linux, Google can safely assume that whoever (end user, family tech, or distro packager) installed Firefox can be forced to install Chrome/Chromium if Google breaks functionality on Gecko. The userbase, in effect, selects for users who can be more easily forced to switch browsers.
With Safari it is the inverse, as a built-in browser of a website-browsing product (Mac/iPod/iPhone/iPad) many more of Safari’s end users might not know how to install or might not trust a third-party browser. If Google breaks WebKit support, a far larger portion of Safari’s users may decide to switch away from Google rather than Safari.
I do not have a good primary source, but Quantum is the marketing name of the project/initiative of porting into Gecko some code originally developed under the Servo project/initiative. The rendering engine itself is still called Gecko.
True. Maybe he meant just desktop browsers? But then again, it’s a discussion about web browsers, not desktop web browsers. Fair point.
True. But if we count iOS users, all of them, no exception use WebKit, because Apple anti-competitive practices. iOS Chrome and Firefox use WebKit as the web engine. They probably have different user agents though, so they are still shown as Chrome/WebKit instead of Chrome/Blink or Firefox/WebKit instead of Firefox/Gecko.
They did shadier stuff in the past, like nerfing youtube performance on Firefox and Edge. Not sure they can easily do that with WebKit, because as mentioned above, iOS Chrome uses WebKit itself.
This is an excellent point, hence why there always needs to be backwards compatibility support when you use online banking with WebKit browsers. Unfortunately social media is of the Chrome mindset and it stopped working on iOS 9.3.5 a long time ago.
The last version of ESR 78 Vanilla, but then take arkenfox’s user.js, modify it so only what makes sense is applied, then apply a distribution/policies.json to lock it in place.
Of course, modifying a pre-made user.js requires meticulous reading of the in line comments so I don’t make a mistake and might take an entire day. RTFM people.
A LibreWolf Lite has to remove Mozilla branding, but at the same time the thing I miss most from CTR and Waterfox classic is text options for the context menu. Anyone found a way to do that without Waterfox and Classic Theme Restorer?
Well the developer choosed for the money.
The browser itself is still in development but is now owned,
by not such a cool company.
You could either like it or not, if not just use something else.
If that works out well for you then why not?
All browsers have their pro´s and con´s really.
I mean i think that we pretty much have to accept that browers are simply going downhill.
Fully agree, hence I only move when sites start to break en masse. That is currently happening to Waterfox Classic.
Waterfox 3.x.x, as ProPrivacy pointed out, cannot be trusted:
Despite Waterfox’s statement that “absolutely no data or telemetry is sent back to Mozilla or the Waterfox Project”, it is difficult for us to continue recommending Waterfox, without advising users to proceed with caution – since they may be sending the data and telemetry elsewhere (i.e. System1).
FF 78 ESR will be a good holdout for a while with updates disabled on the very last release of the 78 branch. LibreWolf if it went ESR would jump to ESR 91.
I think that pretty much all browsers have their issues now days.
So yeah just use what makes you feel the most comfortable with.
In the end there is no perfect browser.
In regards to Waterfox i never used it.
But given the company that is behind it now days…
I wouldn´t trust it personally haha.
Off-topic response,
It seems like the X11 part of the platform chunk in Firefox/Gecko user agent strings has been used since at least 2010 as an identifier for desktop Linux, rather than Android or Maemo.
If you check the Mozilla developer site, it has a page about the Firefox user agent string structure; while it says next to nothing about the platform chunk, it does show you how the Gecko/20100101 is now fixed and basically as meaningless as the leading Mozilla/5.0.
I wish we had more people helping with the releases we already have in place (eg. ubuntu and other debian based distros could use some love), instead of adding new ones, which would require to be compatible with all the supported OSs / distros / install methods / architectures.
and keep in mind that this is not caused by a lack of interest in stable software, I just do not see the advantage of having ESR: breakage is easily identifiable and fixable, and it is not related to the baseline source code version which librewolf is built on top of but rather to the config file + the setup that the user is comfortable with.
They’re of the Chromium mindset where change is normal and you just rapidly adapt. Not everyone is of this mindset.
especially not when I’m currently a 9/10 on the mental health pain scale, with 10/10 being a crisis.
