This is an excellent article. You should be able to choose a browser and then use it in all situations. Google Search only using Chrome, Apple only allowing their own browser, Facebook and others pushing us into their own in-app browsers, all of this makes things worse for users.
(Disclosure: I work at Google, speaking only for myself.)
I think this should be looked at a lens of what’s net gained and net loss. From my point of view , if Apple was to allow other engines on their devices chrome will be the de-facto winner.
No Apple is not going to try to make Safari compete with chrome , especially on windows.
No developers are not NOT going to use Chrome as their target browser and use Chrome push standards
Yes people will switch over to chrome since it will be the one browser developers will target for sure to make sure every hiring works. All it takes if for one website to recommend it in order for users to switch.
Ironically the only thing saving the web from complete Google Control is the opposite of competition. I do not see a scenario where competition does occur and Google doesn’t win. Especially on a service they’re not willing to put in their death bin.
Windows search also uses IE / Edge when you search through the start menu, and this can not be changed as far as I know. Hope they rethink that for Windows 11.
Do you by chance know how to remove the annoying search bar at the bottom of the homescreen without having to install a separate launcher or rooting the phone?
> A browser is an application that can register with an OS to handle http and https navigations by default.
A browser in 2021 is a full OS, data store, compiler, network API, runtime, virtual machine, application platform, and user environment. It should really be called a Web Operating System.
It's not surprising that Apple, Google, and Mozilla have very different visions of what they want in terms of a Web Operating System.
For example, Apple and Google have opposing interests on iOS. Apple generally benefits from replacing web apps with native apps, while Google generally benefits from replacing native apps with web apps. (Google's own apps might be an exception.)
Web developers may like (Google/Chrome's) PWAs, but they are not aligned with Apple's business interests (or their vision of user interface, responsiveness, power efficiency, privacy, etc.) any more than Flash was in 2010.
This article isn't fully accurate. I just went to my Android phone, searched for a random thing with the Google search widget and the links I clicked on all opened in the default browser (which for me is Firefox).
Mine doesn't. It opens a search result in an embedded browser, which claims to be "powered by Chrome" when you open the three-dot menu. (Android 8.1.0)
IMO it is absolutely inexcusable that a device I paid for, does not let me run the software I want to. Lack of browser engine diversity is but a small symptom of that larger root problem. The owner/user must have final authority to run, use it as they like.
If the market is failing to ensure this for the vast majority of the phones and tablets sold, the state must intervene. This is classic monopoly abuse.
You don't own your device, you are just licensing it.
When you pay for a device you are only paying a license to use the device, since you need a firmware to run the device and the firmware is licensed to you without any ownership transfer.
Your device does what the firmware allow it to do, therefore you are only allowed to do what the real owner of the firmware wants you to do.
This is one of those topics that I noticed the symptoms of but didn’t sit down to conceptualize and connect all of the dots. This article clearly ties together all the loose ends and even goes as far to offer potential solutions. A great write-up
Hot take: I know this is controversial, but I want to say it: Only developers and a few tech bloggers care about PWA.
I have never seen or heard of anyone using a PWA outside our little tech bubble in real life. Nor have there been instructions in the news or many clickbait YouTube videos about how to use PWAs on your phone or PC.
PWA is the label for “do things like an app in the browser”. Things like easy install on the homescreen, storing a lot of data locally, notifications, nfc, bluetooth, location and camera (in a user-friendly way), … This is something people definitely want to do, but can’t, and that’s why PWA remains stuck for a niche audience.
The main problem is mobile safari. It is such a limited environment that basically apps are impossible to do for real world use cases in the browser. So, by necessity, even though I was hired to work on the web platform for my organization, I’m now working on a native app.
Apple has handicapped the mobile browser to the point where you have to go native. It is even worse than the IE days, because back then you could make a single web app that supported all browsers. You could have a web-only strategy. This is no longer possible for most organizations.
I still can’t believe Apple gets away with their browser rules on iOS. Yes you can have default browsers now, but they are still built on what Apple says so.
This is made all the worse by the embarrassing bugs in Safari. Apple broke IndexedDB in the current stable Safari and isn't in any rush to fix it (see https://news.ycombinator.com/item?id=27509206). Safari updates are so infrequent that developers will have to include workarounds to this issue for years.
It's been fixed on master for over a month, but it hasn't been included in any of the Safari releases that have come out since then. When someone asked the Webkit engineers when we can expect a fix, their response was "Apple does not comment on future releases." https://bugs.webkit.org/show_bug.cgi?id=226547
If I asked you to imagine what you could do to sabotage the web, it would not look very different than what Apple is currently doing. Add "support" for modern web features but then actually subtly (or not so subtly in this case) break them on a regular cadence. To be clear, I don't think the Webkit team is doing this on purpose, but the effects on the web are still the same.
Perhaps it's because, to the user and the government, the "chrome" around the browser (bookmarks, experience, branding) is more important than the engineering details underneath, which most users don't care about. And governments, seeing other browsers are allowed but they have to use some similar plumbing, don't really care as the branding and sync and all that is different.
To them, it's the same reason why Apple might say you have to use the system Button instead of making your own Button, or use the system way of handling Graphics instead of making your own way of handling Graphics, use the system WebKit instead of rolling your own WebKit. That's a harder nut to define.
I honestly don't think more than 5% of users give a rip on what their browser internals are, if not less.
Has someone perhaps tried making a browser on iOS while sandboxed (aka. without JIT, and only sideloadable of course)? My understanding is that interpreted JS execution has abysmal performance and battery life characteristics, and given that Apple only entrusts themselves to run arbitrary code (since third-parties could just RCE themselves any bypass app store review otherwise) they can't allow other browser engines to use the JIT entitlement - it would look like they were intentionally handicapping the performance of other browsers.
There are a lot of poor arguments made in the article:
1. WebViews have existed since Windows 98, and they are not meant for embedding third party web content but for rendering first party web content.
There is a lot of web content rendered in WebViews which has not been vetted to run outside of them. There are also frameworks like Cordova which surface native capabilities through extensions. They can do this because portions of the WebView run in-process.
To provide user choice here would both break a significant portion of these apps and would result in third party code being injected into your application. It is simply untenable as a position.
On the other hand, the stores _already_ have policies about apps using WebViews to render third party content. Witness the recent article about FakeSpot being removed from Apple's App Store due to complaints by Amazon. A far more appropriate (if still very aggressive) restriction would be around web views being limited to first party content - content included in the application, or marked as being renderable within a particular application's Web View.
2. More calling out for Apple not being aggressive for PWA technology. In this case, there is a linked list of features that were 2-5 years delayed - but not to any standard release. Thats the delay from when Chromium shipped the feature.
Chrome has a very different perspective on Web technologies from Chrome OS, which sought to have no native applications and to have web technologies be the only way to use the laptop or tablet. While they since have backed off on this approach by allowing for running Android applications, this meant for a long time that lack of a "WebUSB" API would also mean these laptops effectively did not have support for any USB devices beyond what the underlying OS included.
It is also worth noting that when people bash Apple for not shipping technologies like WebMIDI aggressively as Chrome, they also leave off that neither Firefox nor IE shipped the features (until recently, when IE became a chromium vender fork). They also leave off how many of these "Chrome Specials" are not tracked to become standards.
3. Even if Apple deleted the one line about not including a third party web rendering engine in submitted apps, I would imagine substantial additional changes would be needed before a Chrome or Firefox was willing to invest in porting their rendering engine over.
The iOS security environment is based on a sandboxed model with distribution-time grants of static entitlements and user-granted dynamic entitlements. Trying to become the system default browser for something like PWA would involve getting apple to create and grant entirely new entitlements, such as "write and execute arbitrary binary code" (for a Javascript JIT), or "modify home screen" (to install a PWA as an application icon). Even support for the chrome execution model (multiple rendering and background tabs to isolate individual sites) is not fully available on iOS.
Hardly impossible, but it would take a lot of work by all parties. It would also mean that third party browsers look less like a tweak to app review and more like long-term strategic partnerships.
I saw a lot of comments arguing about technical requirements, but companies like Google, Apple, Facebook, and others, don't do what they do because technical requirements. They do because they want control. More control they have over the platform people are using, more money they can extract from them.
This is an inane comment. The author Alex Russell speaks for himself not his employer. He's always been outspoken on Twitter and he spends much of the article criticizing Google, the place he worked at for over 12 years.
[+] [-] jefftk|4 years ago|reply
(Disclosure: I work at Google, speaking only for myself.)
[+] [-] tantalor|4 years ago|reply
[+] [-] Jcowell|4 years ago|reply
No Apple is not going to try to make Safari compete with chrome , especially on windows.
No developers are not NOT going to use Chrome as their target browser and use Chrome push standards
Yes people will switch over to chrome since it will be the one browser developers will target for sure to make sure every hiring works. All it takes if for one website to recommend it in order for users to switch.
Ironically the only thing saving the web from complete Google Control is the opposite of competition. I do not see a scenario where competition does occur and Google doesn’t win. Especially on a service they’re not willing to put in their death bin.
[+] [-] EastSmith|4 years ago|reply
[+] [-] Akronymus|4 years ago|reply
[+] [-] musicale|4 years ago|reply
A browser in 2021 is a full OS, data store, compiler, network API, runtime, virtual machine, application platform, and user environment. It should really be called a Web Operating System.
It's not surprising that Apple, Google, and Mozilla have very different visions of what they want in terms of a Web Operating System.
For example, Apple and Google have opposing interests on iOS. Apple generally benefits from replacing web apps with native apps, while Google generally benefits from replacing native apps with web apps. (Google's own apps might be an exception.)
Web developers may like (Google/Chrome's) PWAs, but they are not aligned with Apple's business interests (or their vision of user interface, responsiveness, power efficiency, privacy, etc.) any more than Flash was in 2010.
[+] [-] rstat1|4 years ago|reply
[+] [-] syockit|4 years ago|reply
[+] [-] perryizgr8|4 years ago|reply
If the market is failing to ensure this for the vast majority of the phones and tablets sold, the state must intervene. This is classic monopoly abuse.
[+] [-] akagusu|4 years ago|reply
When you pay for a device you are only paying a license to use the device, since you need a firmware to run the device and the firmware is licensed to you without any ownership transfer.
Your device does what the firmware allow it to do, therefore you are only allowed to do what the real owner of the firmware wants you to do.
[+] [-] ogurechny|4 years ago|reply
[+] [-] samename|4 years ago|reply
[+] [-] gjsman-1000|4 years ago|reply
I have never seen or heard of anyone using a PWA outside our little tech bubble in real life. Nor have there been instructions in the news or many clickbait YouTube videos about how to use PWAs on your phone or PC.
[+] [-] Joeri|4 years ago|reply
The main problem is mobile safari. It is such a limited environment that basically apps are impossible to do for real world use cases in the browser. So, by necessity, even though I was hired to work on the web platform for my organization, I’m now working on a native app.
Apple has handicapped the mobile browser to the point where you have to go native. It is even worse than the IE days, because back then you could make a single web app that supported all browsers. You could have a web-only strategy. This is no longer possible for most organizations.
[+] [-] tmpz22|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
99% of applications don't need to be an app, a Web page with some fancy data form and data presentation widgets is all that is needed.
Best of all, I don't need to deal with the mess that Android development has turned into.
[+] [-] lenkite|4 years ago|reply
[+] [-] mulletbum|4 years ago|reply
[+] [-] post_break|4 years ago|reply
[+] [-] feross|4 years ago|reply
It's been fixed on master for over a month, but it hasn't been included in any of the Safari releases that have come out since then. When someone asked the Webkit engineers when we can expect a fix, their response was "Apple does not comment on future releases." https://bugs.webkit.org/show_bug.cgi?id=226547
If I asked you to imagine what you could do to sabotage the web, it would not look very different than what Apple is currently doing. Add "support" for modern web features but then actually subtly (or not so subtly in this case) break them on a regular cadence. To be clear, I don't think the Webkit team is doing this on purpose, but the effects on the web are still the same.
[+] [-] gjsman-1000|4 years ago|reply
To them, it's the same reason why Apple might say you have to use the system Button instead of making your own Button, or use the system way of handling Graphics instead of making your own way of handling Graphics, use the system WebKit instead of rolling your own WebKit. That's a harder nut to define.
I honestly don't think more than 5% of users give a rip on what their browser internals are, if not less.
[+] [-] judge2020|4 years ago|reply
[+] [-] dwaite|4 years ago|reply
1. WebViews have existed since Windows 98, and they are not meant for embedding third party web content but for rendering first party web content.
There is a lot of web content rendered in WebViews which has not been vetted to run outside of them. There are also frameworks like Cordova which surface native capabilities through extensions. They can do this because portions of the WebView run in-process.
To provide user choice here would both break a significant portion of these apps and would result in third party code being injected into your application. It is simply untenable as a position.
On the other hand, the stores _already_ have policies about apps using WebViews to render third party content. Witness the recent article about FakeSpot being removed from Apple's App Store due to complaints by Amazon. A far more appropriate (if still very aggressive) restriction would be around web views being limited to first party content - content included in the application, or marked as being renderable within a particular application's Web View.
2. More calling out for Apple not being aggressive for PWA technology. In this case, there is a linked list of features that were 2-5 years delayed - but not to any standard release. Thats the delay from when Chromium shipped the feature.
Chrome has a very different perspective on Web technologies from Chrome OS, which sought to have no native applications and to have web technologies be the only way to use the laptop or tablet. While they since have backed off on this approach by allowing for running Android applications, this meant for a long time that lack of a "WebUSB" API would also mean these laptops effectively did not have support for any USB devices beyond what the underlying OS included.
It is also worth noting that when people bash Apple for not shipping technologies like WebMIDI aggressively as Chrome, they also leave off that neither Firefox nor IE shipped the features (until recently, when IE became a chromium vender fork). They also leave off how many of these "Chrome Specials" are not tracked to become standards.
3. Even if Apple deleted the one line about not including a third party web rendering engine in submitted apps, I would imagine substantial additional changes would be needed before a Chrome or Firefox was willing to invest in porting their rendering engine over.
The iOS security environment is based on a sandboxed model with distribution-time grants of static entitlements and user-granted dynamic entitlements. Trying to become the system default browser for something like PWA would involve getting apple to create and grant entirely new entitlements, such as "write and execute arbitrary binary code" (for a Javascript JIT), or "modify home screen" (to install a PWA as an application icon). Even support for the chrome execution model (multiple rendering and background tabs to isolate individual sites) is not fully available on iOS.
Hardly impossible, but it would take a lot of work by all parties. It would also mean that third party browsers look less like a tweak to app review and more like long-term strategic partnerships.
[+] [-] forgotmypw17|4 years ago|reply
[+] [-] underlines|4 years ago|reply
Oh and my default action on all IAB windows is: top right menu > Open in... > Vivaldi
[+] [-] akagusu|4 years ago|reply
[+] [-] foysaluix|4 years ago|reply
[+] [-] Jyaif|4 years ago|reply
[deleted]
[+] [-] feross|4 years ago|reply