Hacker News Reader

Comment by themacguffinman | Hacker News Reader

> How exactly did ‘Steve Jobs cripple the web browser’?

Some examples:

- Automatically erasing all script-writeable storage after 7 days, crippling local PWAs and preventing them from competing with native apps

- dragging their feet on Service Worker support for ages, another PWA issue

- delaying WebGPU standardization

- blocking the standardization of numerous web hardware APIs:

  - Web Bluetooth
  - Web MIDI API
  - Magnetometer API
  - Web NFC API
  - Device Memory API
  - Network Information API
  - Battery Status API
  - Ambient Light Sensor
  - HDCP Policy Check extension for EME
  - Proximity Sensor
  - WebHID
  - Serial API
  - Web USB
  - Geolocation Sensor (background geolocation)
  - User Idle Detection

View on HN

Why should any of those be web browser APIs? I don't want those anywhere near my browser. They all sound horrible.

Edit: Sorry, I wrote this too fast and didn't finish my thought. To clarity, I meant they sound horrible from a privacy perspective, and I don't think some random website should even have to option to access those APIs. The web has enough tracking and malicious sites as it is.

Imagine if apps as they exist today were actually running on a web platform. Apps indistinguishable to the ones you use today.

They're downloaded over www.

They call device APIs

But they're written in Rust or WASM or something.

Visit Netflix.com and suddenly you have the native Netflix app instantaneously on your device. And it works just the same as the one you use today.

That's what I want to see.

The web isn't just HTML and JavaScript. It's not just documents or web apps. It can be native too.

It's a protected runtime.

And it'll be fast.

I honestly think that is a massive privacy issue. Letting the web browser have any access those API is practically begging for abuse. There are enough privacy and tracking issues already with what they have access to without those being added on. The negative far outweighs any positive you have mentioned.

Should there be better faster options for applications to run? Absolutely. Should they run in the web browser? I don't think so.

How is clicking a link to a web page and tapping "accept" any different than clicking a link that loads an app store entry and tapping install?

Heck use the same permission dialogues.

And the same sandboxing.

Who manages those permissions? The browser? The OS? Is it different dialogs than the OS? If not, you are now giving a browser the ability to delegate those permissions. Is it the same level of granularity?

If I visit one page, say facebook and it gets permission. And then visit another page which embeds Facebook, does it still have all those permissions there? If I visit a page, and it hits 60 different URLs under the hood am I getting 60 accept buttons or blanket accepting all of them?

As I see it, there is a ton of difference in scope there.

The exact same argument exists for apps that embed facebook's SDK in them.

It isn't like we can't treat a WASM compiled program delivered through https the same as any other compiled program delivered through an app store. It is just that launching involves visiting a url instead of tapping an icon.

Sure, but this ignores the fact that App Store apps are reviewed, and Websites are not.

That’s critical to why one is trusted more than the other.

As to the Facebook SDK, yes that’s a problem, but it just proves the point - Apple is in fact continuing to tighten restrictions on what Facebook can do to invade your privacy via their app.

This is only possible because it’s an App and not a website.

I was thinking more about my post after I made it, and I came to the same realization.

Part of this is on iOS, apps are compiled to native code and the restrictions enforced through static analysis before code even reaches the end user.

A good analogy would be Android and how they ban 3rd party advertisements in push notifications. That obviously isn't an API enforcement, indeed that enforcement is only possible with a centralized app store where developer credentials can be revoked.

In comparison, web browsers have become a push notification nightmare, with naive end users being endlessly spammed with garbage on their desktop being delivered through web push notifications.

So, I'll readily concede that a web based open distribution model cannot offer the same API surface area as a distribution model that has a combination of manual reviews and static code analysis being used to enforce customer friendly policies.

That said, a lot of apps still can fit into the web model, including large numbers of games (See: The decades of insanely HQ Flash games that existed until recently, sandboxed(ish) code delivered through a web browser), video playback (in which downloaded apps failed in the 90s, then the field took off thanks to web browsers), music playback (I use Spotify in my browser every day), and many others.

Sure, I don’t think anyone, least of all Apple, is disputing that the web can be a great platform for apps.

The point is that there is a genuine need for both kinds of platform and for people to be able to tell the difference.

Can’t believe people downvoted you for making a clear point

So if you don't like something - it shouldn't exist, and no one else should have it?

That is not what I said. I asked what the justification for them existing is. None of them sounded valuable, and seemed like just additional ways for ads and malicious sites to track you. So what are the up sides? I actually want to understand.

None of them sounded valuable to you - I have no problem imagining how those APIs could be useful (e.g. some simple apps may be replaced by a web application). One can easily apply your argument against access ramps ("My establishment already has stairs, a ramp doesn't sound valuable")

Can you see how they also create privacy problems?

If ramps hypothetically did create privacy problems, would you still wish them out of existence, despite their utility to other people?

Do these exist on Android?

If not, why not?

If they do, why hasn’t it enabled Android to leapfrog iOS?

These are web APIs, not Android/iOS specific, and IIRC Google and possibly other browser vendors have expressed interest in these APIs.

Web standards require voluntary cooperation and isn't something that can be resolved by allowing "better" standards variants to win in a marketplace over others (otherwise they wouldn't really be standards).

Apple has pre-emptively blocked the standardization of these APIs because they effectively have veto power, and they have veto power because web standards aren't really a free market. Browser vendors choose not to ship standards that major browsers don't all agree on, which means that Apple's singular objection scuttles the process by design.

Of course this is one of the risks you have with standards, one bad actor can screw everything up. It's why standards often suck and it's a happy miracle that the web is as good as it is. When Apple themselves can screw up a standard that they directly compete with (web vs native iOS) from the inside, well, that's just too convenient for them.

This isn’t accurate. There are plenty of instances of browser vendors implementing API’s ahead of other vendors.

It simply isn’t true that vendors always wait for agreement. Apple’s participation is important, but not mandatory.

They implement APIs ahead of other vendors because someone has to do it first and try out an implementation, most standards start out as experimental implementations. But when other major browsers reject it as a standard, the API is usually deprecated.

I'm sure there exist instances of vendors not waiting for agreement, those are rare exceptions because it essentially breaks the standard. Web fragmentation was a big problem for a long time and the major browsers have largely willingly agreed to avoid that. Apple's participation is de facto mandatory, they control a major browser and other major browser vendors won't ship something that Apple has openly declared they will never support.

Reply on news.ycombinator.com