[HN Gopher] Hobson's Browser: How Apple, Facebook and Google bro...
___________________________________________________________________
Hobson's Browser: How Apple, Facebook and Google broke the mobile
browser market
Author : feross
Score : 101 points
Date : 2021-07-24 22:39 UTC (1 days ago)
(HTM) web link (infrequently.org)
(TXT) w3m dump (infrequently.org)
| rstat1 wrote:
| 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).
| syockit wrote:
| 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)
| rstat1 wrote:
| Hmm, perhaps its something that changed in more recent
| versions then. My phone has one of the Android 12 betas on
| it. I certainly do remember this being a thing though, but
| not in a while.
| jefftk wrote:
| At some point might you have gone to Search > Settings >
| General and unchecked "open web pages in the app"? Pretty
| sure that setting is on by default.
| tadfisher wrote:
| The Google app uses Chrome Custom Tabs, which allows the
| calling application to filter the browser implementation by
| application ID. The documentation encourages this by showing
| how to limit to the various Chrome app IDs (stable, beta,
| canary, and dev). Naturally, the user-respecting action is to
| try a CCT request with the default browser and _fall back_ to
| known app IDs, but Google themselves don 't do this and don't
| show how to do it in their documentation.
| samename wrote:
| 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
| lenkite wrote:
| IMHO, Apple should be sued for Antitrust here, but somehow they
| are America's darling and can get away with everything.
| mulletbum wrote:
| Except of course they are being sued right now......
| post_break wrote:
| 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.
| gjsman-1000 wrote:
| 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.
| makeitdouble wrote:
| If we are going by that analogy, to governments the "chrome"
| is important when the "pipes" underneath are a common
| resource it regulates.
|
| I don't think govs regulating the implementation of anything
| in the OS is a good idea, but we could at least expect some
| wrist snapping to unlock the situation.
| judge2020 wrote:
| 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.
| tantalor wrote:
| You can decouple the browser engine from JS, e.g. use Apple
| JS core with Chromium/blink
| JoshTriplett wrote:
| The restrictions on JIT aside, my understanding is that
| there's _also_ a separate rule that you can 't have any web
| browser engine except the system version of WebKit.
| judge2020 wrote:
| Well, yes, but i'm trying to make a case for why Apple
| would want to prevent other browser at all - that being how
| it would look like Apple is intentionally handicapping
| other browsers by not letting them use JIT, raising less-
| explainable antitrust concerns.
| gjsman-1000 wrote:
| One explanation could be that Apple doesn't want an
| "electron situation," where every app comes with it's own
| fully-loaded web browser, is a memory and CPU hog, and a
| security risk if the app is out of date. Like is
| currently happening on PCs.
|
| With WebKit, its update once, secure all apps everywhere.
| paulryanrogers wrote:
| I'm curious if FirefoxOS had gone differently if Apple
| and others would've considered supporting a native-web
| approach for apps. (Albeit also tied to only one or a few
| blessed HTML and JS engines.)
| JimDabell wrote:
| That was the Apple party line when the iPhone was first
| released - the only Apple-blessed way to build iPhone
| applications was to build mobile-friendly web
| applications. There was a backlash - everybody complained
| and demanded native applications; the App Store was
| opened the year after.
|
| https://9to5mac.com/2011/10/21/jobs-original-vision-for-
| the-...
| paulryanrogers wrote:
| IIRC FirefoxOS did it differently. Apps were local
| bundles of web tech. Not only pinned links to open a
| browser.
| [deleted]
| gjsman-1000 wrote:
| Another explanation, less popular, is that Apple
| restricting to WebKit actually helps _foster_ browser
| competition at the moment.
|
| Let me explain. Right now it's WebKit vs Blink (Chrome
| and all Chromium-based Browsers, including Brave,
| Vivaldi, Opera, Edge, etc.). If Blink were to be allowed
| on iPhones... you'd see Chrome become _even more
| dominant_. Firefox is dying on PC, has less than 1%
| mobile share, and is no competition in this case.
|
| Requiring WebKit is what prevents an even greater Chrome
| monoculture.
| makeitdouble wrote:
| Apple was in critically bad place when windows dominated
| with Internet Explorer, and Adobe with its apps. These
| two companies dictated where the users would be, and
| Apple had to beg them to play nice.
|
| The iPhone was a whole new platform where Apple had 100%
| power on where it could go; opening the door to third
| party browsers to bring their domination to the platform
| from the start must have been seen as suicidal.
| an_opabinia wrote:
| It is totally about preventing alternatives to the App
| Store.
| judge2020 wrote:
| That's the rule, but you have to wonder why. They don't
| get more money just because Google can't spend their own
| development resources on targeting and validating
| Blink/V8 for iOS.
| an_opabinia wrote:
| 90% of the revenue is games. Mobile Chrome would only
| need to support idiosyncratic Unity and Unreal web
| targets for a significant chunk of that revenue.
| feross wrote:
| 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.
| [deleted]
| gjsman-1000 wrote:
| 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.
| pjmlp wrote:
| PWAs are just mobile Web sites and they are doing just fine,
| regardless on how someone feels like calling them.
|
| 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.
| tmpz22 wrote:
| Modern PWAs are inferior to products compared built with more
| traditional means.
| an_opabinia wrote:
| Show me a traditional App Store app that doesn't pay 30% of
| IAP to Apple.
| gjsman-1000 wrote:
| Easy, any app that is making less than a million a year, or
| any app where people have been subscribed for over a year.
| They pay 15%. Also you didn't specify the app even had to
| be paid, so any free app counts too.
| zmk5 wrote:
| This was only true a couple months ago and required a
| them to be sued by Epic (and a general "trust busting"
| attitude from the new admin) for them to drop it. They
| didn't do it out of the goodness of their hearts.
| gjsman-1000 wrote:
| Well, Tim Cook testified _under oath_ that they had been
| doing the change to 15% for under $1M before the actual
| Epic Games lawsuit was filed, and that it had been in the
| works for over a year. And Biden had not been elected
| yet, even when they rolled out the 15% change Biden still
| wasn 't President.
|
| Unless you actually believe that Tim Cook committed
| perjury.
| saagarjha wrote:
| Wouldn't be the first time he's done it, for this very
| topic in fact n
| ksec wrote:
| >Unless you actually believe that Tim Cook committed
| perjury.
|
| One. He knows there are no way to prove him wrong. Just
| like many other things he had said during Apple vs
| Qualcomm and Apple vs IMG. When there are ample of
| evidence his word are either lying by omission or a spin
| on a word's definition.
|
| Two, AFAIK, he didn't said "they had been doing the
| change to 15% for under $1M before the actual Epic Games
| lawsuit was filed, and that it had been in the works for
| over a year."
|
| He said and I quote " _probably has its origins several
| years ago_ ". They could trace that back as Phil
| Schiller's letter to Tim Cook on App Store if it needs to
| be.
| an_opabinia wrote:
| Listen to yourself. "Under the works." Dude, c'mon of
| course it was the lawsuits.
| Joeri wrote:
| 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.
| leodriesch wrote:
| I do think that for us developers PWAs are great. But for
| users, not so much IMO. Native apps (even the ones made with
| React Native or similar tech) are 99% of the time of higher
| quality than a web app.
|
| That comes down to having more possibilities (even with every
| PWA feature implemented, there would still be so many
| missing), greater performance and battery efficiency.
|
| As a developer I would love to see PWAs get more
| capabilities, but as a user I don't want my native apps to
| get replaced with PWAs to save on some money.
| kitsunesoba wrote:
| My thoughts are similar. It's possible to make high
| quality, kinda-native-feeling PWAs, but that definitely
| doesn't come for "free". In fact it takes a level of
| attention to detail and craftsmanship that frankly few
| developers seem willing or capable of, whether that's due
| to indifference on behalf of the developer or management
| riding their ass pushing them to ship sooner.
|
| So the most likely outcome is that the average PWA would be
| less pleasant to use than the average app, which is a
| pretty clear cut loss for users.
| fulafel wrote:
| A lot of users won't install a native app but will use your
| web app.
|
| From a user POV: Installing a native app is a decision. The
| native app capabilities let it do shady stuff with ads and
| exfiltrating your PII, might eat your battery, spam you
| with with notifications, and in case you forget to
| uninstall an annoying app it's a fail-open situation where
| it can keep on doing all this stuff in the background
| unless some day you remember to uninstall it. Browser ad
| blockers don't work on them. The app only works on your
| phone and with someprobability a web version doesn't exist,
| so it's a piece of tech that is inaccessible using a real
| computer, with a real screen and keyboard etc.
| dmitriid wrote:
| > Things like easy install on the homescreen, storing a lot
| of data locally, notifications, nfc, bluetooth, location and
| camera
|
| > The main problem is mobile safari.
|
| Ah yes. "The problem". And not the fact that a lot of what
| you want is badly specified, poorly implemented and
| considered harmful by both Safari and Firefox:
| https://webapicontroversy.com/
| enos_feedler wrote:
| its still just an assumption that pwa success is blocked
| behind some chicken and egg problem. i dont think you can say
| it is "definitely" something people (lots of them) want. as
| of right now it looks like the people who want it most are
| giant platforms like Google, Amazon and Facebook who want to
| build game platforms that circumvent in app purchases. thats
| a valid reason and if its meant to broaden it will. these
| companies are worth trillions after all
| foysaluix wrote:
| Facebook is literally controlling majority of social media and
| controlling your data! Apple is right in this issue
| underlines wrote:
| What was the Magisk module called, that allows us to change the
| engine of IAB on Android?
|
| Oh and my default action on all IAB windows is: top right menu >
| Open in... > Vivaldi
| perryizgr8 wrote:
| 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.
| akagusu wrote:
| 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.
| ogurechny wrote:
| Well, you've paid, and that very moment everyone has stopped
| caring what you think.
| akagusu wrote:
| 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.
| Jyaif wrote:
| Ironically, the article was paid by Microsoft.
| feross wrote:
| 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.
| dmitriid wrote:
| Yes, he's very outspoken on Twitter where he twists reality
| to suit his own worldview (which is almost invariably "Safari
| bad, put Chrome on iOS") and he completely ignores the
| realities that are:
|
| - So many APIs he raves about are considered harmful by both
| Safari and Firefox: https://webapicontroversy.com/
|
| - Chrome is blatantly ignoring all input and forces poorly
| specified internal Chrome APIs onto the world under the guise
| of "standards"
|
| But sure. "He's outspoken on Twitter" should really absolve
| him and any criticism of what he writes is "inane".
| torartc wrote:
| I don't typically agree with Russle on most things, but
| Safari is in fact bad.
| dmitriid wrote:
| Safari is, in fact, fine. The "Safari bad" argument comes
| from people who are keen on turning the Web into
| something it can never be: an app platform.
|
| I very very very much prefer the "bad Safari" to the
| shiny Chrome which pushes (and ships) "standards" so bad
| other browser developers can't even understand them [1]
|
| [1] https://github.com/mozilla/standards-
| positions/issues/459
|
| _Edit:_ grammar and typos
| enos_feedler wrote:
| well it seemed a bit funny that he used to bash apple while
| he worked at google and now that he works at microsoft he
| bashes both apple and google. in all cases he leaves his
| current employer out of the criticism.
| ksec wrote:
| I guess that he joined Google because he is pissed with
| Apple and joined Microsoft because he is pissed with Google
| as well.
| dwaite wrote:
| 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.
| forgotmypw17 wrote:
| Actually, even IE3 on Windows 95 supports the OLE embedding
| method, and you can build a "framed web view" browser.
| jefftk wrote:
| 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.)
| tantalor wrote:
| You can disable embedded chrome in Google app;
| https://support.google.com/websearch/answer/7013866?hl=en&co...
| wayneftw wrote:
| Not in Google maps on iOS though.
| dna_polymerase wrote:
| It's probably a good sign that you had to tell this the
| Google engineer.
| jefftk wrote:
| I did know you can turn it off. But I want setting a
| default browser that supports the Custom Tabs protocol (ex:
| Firefox) to make that browser be used any time an app asks
| for a custom tab, without any additional steps.
| tadfisher wrote:
| This is currently not possible because the filtering is
| done by the application calling CCT. The default CCT
| library implementation explicitly filters on the list of
| known Chrome app IDs and the app has to explicitly work
| around this filtering by trying the default browser first
| before falling back to the default CCT call.
| jefftk wrote:
| It sounds like you're saying that this is currently not
| possible because it's currently not implemented that way?
| But of course! I'm saying they should change it so that
| the application asking for a custom tab can only request
| "please give me a custom tab".
| tadfisher wrote:
| I'm saying it's not possible at the OS level because the
| filtering is done in application code. CCT is not an OS
| service, it's a client library and a service IDL.
| Updating the library to remove the ability to filter by
| application ID is similarly not possible because binding
| to specific application IDs is not unique to CCT, it's
| simply how binding to services works on Android.
| mulletbum wrote:
| You lost me. Are you saying that the people who make
| Android OS can't reprogram Android OS? That is all this
| person is saying.
| Jcowell wrote:
| 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.
| SPBS wrote:
| It's fine, a lot of people still use Safari on desktop
| despite Google Chrome being available. And developers have to
| support it all the same
| cbovis wrote:
| I'm a regular desktop Safari user and you'd be surprised
| how many websites are just flat out broken in Safari,
| especially government sites. Part of the reason I use it as
| my daily driver is to ensure that the websites I'm working
| on get tested properly in Safari since the defacto browser
| for most developers seems to be Chrome.
| jefftk wrote:
| I wish Apple would make a Safari for Windows or Linux.
| That the only way to test that your site works properly
| in Safari is to buy Apple hardware is certainly a
| contributor to sites being broken in it.
| kitsunesoba wrote:
| It's not a perfect analogue, but under Linux,
| Epiphany/Gnome Web is a reasonably close match for most
| purposes. Not sure about Windows.
| ksec wrote:
| That is the point, they want user to complain to Site
| owners for not working on Safari and forcing them to Buy
| Apple Hardware.
|
| Basically if you want to serve the 1.4B Active Apple
| Devices which nearly all use Safari, you have to buy an
| Apple hardware to test it.
| gjsman-1000 wrote:
| They had Safari for Windows for several years, but
| abandoned it because it didn't gain enough market share.
| sbuk wrote:
| The same was true when IE dominated. The point being missed
| is if a single browser is allowed to dominate across the
| board, the owners of the technology become the gatekeepers
| of web technologies. That would have been extremely bad
| under Microsoft, and it is going that way with Google. In
| fact, there was a groundswell of negativity towards WebKit
| until Google broke the hegemony with by forking it,
| creating Blink. Which is now in a significantly more
| dominant position than WebKit ever was.
|
| I'm not suggesting that Apple would be any better or that
| not allowing other browser engines is a good thing.
| However, the fact that they don't is keeping
| Google/Chrome/Blink from having total dominance of the web.
| echelon wrote:
| Apple doesn't allow competition on their device because they
| know they can't win if forced to compete. Apple, even with
| all its resources, can only be spread so thin. By hobbling
| the ability to run your own engine, they don't have to try
| very hard.
|
| This is the same reason they don't allow open installs. If
| they like an idea, they can compete at 30% more margin and
| with their army of engineers. Look how easy it is for them to
| enter the banking and movie businesses.
|
| Keeping developers weak means they yield all the leverage.
| It's the modern anticompetitive playbook.
|
| The DOJ can restore the balance by forcing Apple to open up
| compete fairly. It'll make for better software and products
| all around.
| leodriesch wrote:
| I don't think this is true. Safari on Desktop still has a
| considerable market share. IMO Safari is actually a pretty
| great browser. It is fast and power efficient, and much of
| the reduced feature set is stuff that I don't want anyways,
| like Push Notifications or PWAs on Desktop.
| samat wrote:
| Btw, safari has its own API to get push notifications on
| desktop.
| bobbylarrybobby wrote:
| I assumed it was because they didn't want users using the
| default, pre installed browser to see "this site works
| better I chrome" alerts on their i-devices
| echelon wrote:
| A sure sign they can't keep up and aren't winning over
| mobile web devs.
| EastSmith wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-25 23:02 UTC)