Hacker News Reader

Chrome on Android also lacks support for extensions entirely, likely because Google is well aware that overwhelmingly the most popular type of browser extensions are adblockers. There are Chromium based browsers that get around this, but usership of those is low because most people just use the default browser. Seems like a fairly clean cut instance of conflict of interest.

At this point Chromium and Blink should be spun out into a Mozilla-style non-profit, not only due to conflict of interest but also because it's a bad idea to have a single corporation in full control of software that has become critical infrastructure.

Non-Chromium browser picks also don't swap out the system webview, meaning that if you click say, a link in Slack/Discord/whatever other app, you still end up with the Chrome browser anyway.

That's why I mention the system webview in the first place; it's a super insidious browser that solves a meaningful issue ("Electronification", where every desktop app is now running Chromium is solved by it's presence) but conveniently also grants full control back to Google, overriding other browser changes. (I once read some stats about this - system webviews are the majority of browser traffic on phones nowadays, because app developers love them; they can be tracked (the Google system webview reports back data to the main app about user behavior - IIRC the one Apple offers for non-browser apps is more of a black box though) and analyzed to see where users go from their apps, which helps with things like user profiling for advertisements).

Given that Android lets vendors force it to Google's implementation on a kernel level, it's also very much an avenue Google doesn't want users to figure out to change or to have competing implementations for.

> (the Google system webview reports back data to the main app about user behavior - IIRC the one Apple offers for non-browser apps is more of a black box though)

That's correct, SFSafariViewController does not afford app devs any usage information whatsoever, is run out-of-process, and uses separate cookie/localstorage/etc from both normal app webviews and Safari proper making tracking more difficult.

Also unlike Android's Chromium webview, SFSafariViewController utilizes the content blockers and extensions the user has installed unless the user specifically requests otherwise, so there's still some level of ad/tracker blocking happening.

You forget another important need for system webview. It's handled differently but don't forget we've trained users to type oAuth login credentials into random browser popups. The alternative is each app adding their own (potentially malicious) web view which is hard to confirm is safe.

> then Google does a sneaky thing and make it so that any in-app browsers will still be Chrome thanks to the System WebView. So nobody gets to escape the Google ecosystem.

Are you sure about this? I'm able to use (and have been using) Firefox as my Android system webview, just tested now. And this is literally on a Google-designed device. Maybe I'm missing something.

Disclaimer: Googler, opinions my own.

I... don't know what you changed because Firefox does not offer a system webview. They just... don't. Firefox offers GeckoView, but that's an app library that also does what WebView does, not a system application. There's not even any Firefox forks that build up a system webview because none of the forks think it's worthwhile after Google locked it down so much.

The closest you'd get to a "firefox webview" is by installing a Magisk module/non-Google ROM that replaces it with a stub application that forwards any "open system webview" call to your regular browser (so it works like clicking an http link). In the past you could just install that stub on any old Android device, but Google locked it down by letting vendors set a signature that a system webview would need to adhere to[0] (as well as a ton of other restrictions).

To be clear, I am not referring to what happens if you just click an http link in an app and the app just calls the browser. That setting respects browser choice. I am referring to the WebView[1] component, which a lot of apps use as a substitute for launching the browser and relies on an underlying app called the Android System WebView[2] to render the pages. For a legitimate usecase; in chat applications (ie. Discord), where a user might visit a website only to then want to immediately go back to the chat itself, the app instead just creates a WebView and... that one is always Chromium, and is nowadays enforced by vendor settings (so it can't be changed without root). In less legitimate usecases, this is done for tracking reasons.

(Another big user of the WebView component for this was Facebook Messenger, but Facebook has switched to using an internal version of this webview component, for reasons only understood by Facebook and it effectively acts as a shadow "fourth internet browser" that is in practice a somewhat outdated version of Chromium.)

[0]: https://chromium.googlesource.com/chromium/src/+/HEAD/androi...

[1]: https://developer.android.com/reference/android/webkit/WebVi...

[2]: https://play.google.com/store/apps/details?id=com.google.and...

Interesting, so for the apps that I've used that open a webview (which specifically says in the menu box "Powered by Firefox", with an option to "Open in Firefox", which opens in the full browser), they've added the library specifically in the app? To be clear, I don't have a rooted phone.

Not trying to be difficult, but I'm seeing this specifically in the Fastmail Android app, and I don't remember ever setting an app-specific setting to use it. I believe I've also seen this "webview" (maybe this isn't what you mean?) in other apps as well.

Edit: Bit of research suggests that this may be the "Custom Tab API"[1] which might be something different, perhaps a newer API?

1. https://www.reddit.com/r/firefox/comments/zkbf8v/enable_fire...

Ah hold on - that's not a webview. That's the custom tabs provider; https://developer.chrome.com/docs/android/custom-tabs/ .

That one can still be user configured. (As you can see, what Browser gets used on Android when you click a link is just a bit of a mess in general; you have custom tabs, system webview and even bundled webview, which is what Facebook does).

Yep, what you're referring to (the "Powered by <browser>" screen) is done with the Custom Tabs API. Some folks might also refer to it as the in-app browser. Any browser can implement a CustomTabsService and the whole feature respects the default browser setting.

The Fastmail app is actually a good example of something that uses the WebView APIs though. Fastmail's UI is entirely web-based and their whole app is rendered inside of a WebView, provided by the Chromium-based "Android System WebView" app. If I remember correctly, the list of allowed signatures for a WebView provider is baked into the OS, so no third party can provide an implementation without root access.

I've been using Firefox as System Webview for quite some time. I think all you need is setting Firefox as default browser.

I'm only able to do this with root, which is fine for me, but the percentage of devices that can even be rooted at this point seems to go down every day :(. It's a shame that is not legally protected as well.

> Android is slightly better in that on the surface you can switch out the browser for say, Firefox (although Firefox on Android is a disaster)

When was the last time you tried it ? It has been my daily driver for years and I can't complain (ublock origin works on it :).

About a year ago? The main issues I had mostly boiled down to "the app felt clunky to use", pages not rendering nicely, issues while scrolling pages and buttons not being in places where they seem logical. Similarly, the way Firefox handles external links from other apps feels... bad? Like that's really what a lot of it boils down to; Firefox as an app just feels outdated to use.

Then there's the fact that extension support in Firefox Mobile is aggressively locked to the Mozilla extension store and only a whitelist of stuff Mozilla approves (it draws extensions from a collection on the Mozilla extension store, so if your desired extension isn't in it, the only option you have is to override the entire thing by making your own collection and messing in about:config), and that kinda compounds to a strong "I'd not recommend it" for me. Firefox to me is a browser that at it's core should be respecting user choice and the Android implementation on that alone doesn't meed the sniff test; Mozilla lock-in even on minor things like this is a big dealbreaker.

Chrome's feel with the rest of Android, for all the issues I have with it, is really well done. Firefox makes you feel much more like you're constantly struggling against Android to make a square peg fit in a round hole. I personally do use a Chrome fork (Cromite, which is a Bromite fork since Bromite's lead dev is MIA), just so that feel is preserved (while also having a solid adblocker and other privacy oriented features).

Thanks for your detailed answer. I have only ever used firefox on android so I don't really feel its clunkyness and I only know of one major website I use (an e-commerce merchant website) with problems. Sometimes the sharing function is broken (no icons) but I can live with that.

I also wish there were more extensions but as long as ublock is available it's okay for my usage.

I should spend a day or two with Chrome or cromite to see what I am missing.

All that being said, the latest firefox update pisses me of: now when you open a new tab and type news.ycombinator.com it will jump to any tab with the same url. I have >1000 tabs and the new behavior messses up the chronological order in which tabs were opened. It also jumps me back hundred of tabs backward at time. I dig a bit and found the bugzilla bug report, the original problem is about opening a new tab from the home tab and seeing how it took years to get the behavior changed and how the change has unintended consequences and people in the thread are "too much tabs is bad" kind of people I am giving up on reporting it.

I used it for years until the update which removed most add-ons. Not because of that change though, that didn't bother me, but because the interface became and in my opinion remains absolutely awful. Some navigations went from literally 2 presses to more than 8 and I don't understand how people put up with it.

This I think that yeah FF is losing badly on desktop, but it doesn't help that the majority of people use mobile and Google/Apple have created a duopoly on mobile... it very literally should be an antitrust, and quick before it's too late for any other competing engine to catch up.

I think we'll get to the point where they have had monopoly for so long that their policy making that they get to dictate as a result will be so ingrained inside of the web that it will be non reversible.

> then Google does a sneaky thing and make it so that any in-app browsers will still be Chrome thanks to the System WebView

Rubbish. Any app can use your own embedded browser engine - Google is not sneaky. It is just that the WebView is easy to use and you don't need to manage security updates. Apple doesn't give you the choice (I am fairly sure App store rules disallow you from embedding your own WebView implementation into an App).

If anything locking down iOS that much now probably means that Safari remains a viable browser. If people could install Chrome, I imagine we would have more of a monoculture of browsers.

If Safari only is a viable browser because of Apple literally being anti-competitive to it's users in other ways, I'd argue it's hardly viable at all.

The reality is that we're most likely in a monoculture already when it comes to browsers (just on the whole); Firefox gets funded by Google as and Safari only is propped up because Apple does it's own anti-competitive practices in other areas (read: their gatekeeping of the App Store) rather than being a common choice because it's a good browser.

There's also the fact that a lot of this is a tough thing to claim when by all accounts from webdevs... Safari is an unviable browser without Apple's anti-competitive behavior because Safari fucking sucks. It's the modern Internet Explorer of browsers; a lot of modern web APIs that both Firefox and Chrome use just... don't work on Safari because the system has bugs or weird design decisions that don't follow spec, which means they're not widely used because Safari is still there and holding back everyone else.

"Safari fucking sucks. It's the modern Internet Explorer of browsers; a lot of modern web APIs that both Firefox and Chrome use just... don't work on Safari because the system has bugs or weird design decisions that don't follow spec"

Absolute nonsense. The web developers who go off about Safaris are overwhelming terrible webdevs who want to stick a "Made for Chrome" button on their website and be done with having to bother dealing with other browsers. It's actually a bit hilarious when Safari is called Internet Explorer -- there was a time when Internet Explorer offered all sorts of crazy new stuff (just like Chrome today) which threatened the user's privacy and security, but webdevs wanted it so they stuck "Made for Internet Explorer" and dropped a bunch of ActiveX controls on their page. If anything Chrome is the Internet Explorer of the day.

I'm pretty passionate about this because not only is it going to be incredibly damaging for the web when Safari is crushed (Firefox will be crushed simultaneously), it means whatever half-baked nonsense Google pushes out is going to be the norm.

Honestly, I could link you a lot of articles, but... just look at the page on caniuse and see what Firefox and Chrome implement, yet Safari just doesn't bother with.

https://caniuse.com/?compare=chrome+118,safari+17.0,firefox+...

The main ones of note here really are the AV1 support, OGG Video and WebCodecs though. These aren't "new" technologies; most of them just are objectively good pieces of tech that have been battletested for years now. They just barely see any use because Apple doesn't want to implement them and the iOS browser market can't just be handwaved away. That's Apple refusing to implement certain technologies that make the ecosystem worse for everyone else. That's why I say Safari sucks.

I didn't include CSS in that list but if you enable it, you'll see a similar thing; Firefox and Chrome are both more or less up-to-date (with Chrome running away with certain APIs which is yeah, an issue), while Apple just doesn't support large chunks of it.

Similarly, while not listed on caniuse, their IndexedDB implementation is an infamously buggy mess that often introduces regressions with each update (and back when Web SQL was a thing, their implementation was once again implemented in a way that made it useless; they'd wipe it entirely after a week, meaning nobody ended up using Web SQL).

That one is also compounded by the fact that the Safari release cycle is infamously just... too slow, since Apple insists on tying it to entire OS updates (which means you aren't just supporting the most recent version of iOS but probably the ones from 5 versions ago as well because not everyone can run the latest version of iOS).

This isn't "bad webdevs"; it's Apple being a bad actor and using an external method of leverage (the App Store) to force webdevs to not be able to use actually good technologies.

>The main ones of note here really are the AV1 support

Apple devices -- in fact, most devices -- don't have AV1 hardware support. Meaning playing AV1 content will have a greater impact on battery life or provide a worse experience.

That's why Apple doesn't support it. Any reasonable technology stack is going to sniff what the client supports and serve up AV1 to so equipped clients (which hopefully have hardware support), h265, whatever. That falls in the realm of "complete and utter non-issue".

Google doesn't care about your experience (this has been shown time and time again). They'll toss whatever corpse of a solution they want over the wall and let it bake in the sun of exposure.

Further, notably your comparison includes loads of partials and nones for Firefox as well. Do you also hold that Firefox sucks? Because again, Chrome is Internet Explorer. Google sticks anything and everything in Chrome because it serves Google.

>they'd wipe it entirely after a week

This is actually a telling comment. At the time vendors discovered that they could circumvent cookie blocking/clearing by just stuffing everything into WebSQL. Again, Google just tossed it over the wall and loads of "bad webdevs" exploited it and went wailing and gnashing that Safari did this or Safari did that, why can't they just circumvent your privacy controls like they could on Chrome.

> a lot of modern web APIs that both Firefox and Chrome use just... don't work on Safari because the system has bugs or weird design decisions that don't follow spec, which means they're not widely used because Safari is still there and holding back everyone else

Are these Standards, or are these "standards", ie, Chrome implemented something and now Google is complaining that Apple didn't also implement the thing that Google just came up with?

Vivaldi is the best mobile browser I know! It has a builtin tracker and ads blocker. Made the change a year ago can't look back

how can you prove that apple's gatekeeping of browser has an economic impact. the google deal is easy to assess

Apple is blocking an entire market of technologies from its platform outside of their own implementation by abusing the fact that iDevices have a single storefront they control.

It'd be one thing if Apple made it so that the iDevices just are too technically incompatible with Gecko or Blink, but that's not the case. It's literally just a reviewer in their offices going "no, non-webkit browsers are against policy, not allowed".

Like... there, that's it. Apple is abusing their monopoly in one area (the App Store) to force a monopoly in another area (the browser market on their devices). That's textbook antitrust.

still, whatever service is available on chrome is also available in safari. it s the app store that drives the gatekeeping

[citation needed] given how much Safari's browser seems to laggard behind its peers

Well, and JIT is not allowed as it is a security nightmare. So that means no custom Javascript implementations.

> entire market

Which is realistically only Chromium. Unfortunate as it is Apple’s policies are the only thing keep Google from entirely dominating the browser market.

I’ll fly to Europe if I have to in order to get an iPhone that can run Adblock on the mobile browser

Have you looked at nextdns? Works well for me.

AdGuard and Vinegar work fine for iOS Safari. What do you mean by mobile browser? Or do you mean any iOS webview component?

Vinegar is amazing, combine it with SponsorBlock and you get a much better YouTube experience than the native app

Apparently I was just ignorant. Thank you these look amazing.

No problem. I feel torn about advertising these extensions because YouTube might become wise to them, but I also want to pay it forward.

I use Firefox Focus. It doesn’t block everything but it does stop most annoying ads. I doesn’t support “tabs”, but in vanilla Safari I find tabs to be a graveyard of things that I occasionally clean out but rarely actively use.

1Blocker exists?

Yet another alternative (to those already mentioned) is to run PiHole at home and Wireguard. This way you have one place to add domains, it works across all apps and browsers, and even away from home.

How many gigs of the very finite storage on my mobile device should I, as a user, be required to dedicate to every mom-and-pop browser engine that comes along? Storage is cheap but it ain't free on mobile, and it's not expandable without buying a new phone.

Seriously though: especially if you're a developer, do a quick audit and discover how many copies of entire browser engines you have on your desktop machine. They get squirreled away in testing frameworks, one-off bespoke apps, hardware configuration control panels... I'm not immediately convinced that the phone ecosystem controllers going "No, we don't do that here" is a bad thing.

I wouldn't argue every browser needs to be pre-installed, but as it stands now you can't even choose to install another actual browser engine at all on iOS.

Assuming you're talking about Android here (given on iOS everything is just WebKit)...

Do note that I have nothing against System Webview implementations. I think they're a great solution to avoid the current Electron hellscape we're seeing play out on the desktop, where every single bespoke application is running an entire copy of Chromium under the hood. The idea of just having a single copy of a browser running in the OS as a sort of backbone for in-app HTML pages/external links without launching the entire browser is a very reasonable approach, especially given phones have historically been much less powerful devices than desktops.

The problem I have is the lack of user choice; you have no control as a user what your System WebView is. Google used to offer that choice, but then quietly let vendors slam the door shut (unless you go the custom ROM route or root, which is beyond the skills of a regular user), and the default they offer (afaict) means most vendors do that, with vendors assuming most users won't care about it, so why would it matter. In fact this is also why I really dislike the Firefox approach of making it something the developer chooses to switch out, not the user - it's just bringing the Electron problem to mobile. The user should be the one making that choice, not the developer.

It really shouldn't be difficult to ask the user to pick from a list of browsers and then to actually respect that list. If a user says "I want to make Firefox my browser", then Firefox should also be the System WebView. Not to quietly put them back into Chrome (and therefore subject to Googles data collection practices) just because they clicked a link in an application.