Hacker News Reader

Comment by tgv | Hacker News Reader

Me too. Device orientation, USB, Bluetooth, vibration, they don't belong in a web app.

All the dangerous ones come with comprehensive permissions prompts, and browsers can offer options for don't ask again/never ask etc, so if you're not interested there's still little downside to those being available for those who are.

Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is amazing.

I would guess that most regular users are very quick to click “Allow” on a dialog box. I like how macOS handles unidentified apps where you have to navigate manually to the security settings to allow an unidentified app.

Also known as “yes click syndrome” or “make the stupid thing work already”, a phenomenon which can be and has been weaponized.

> where you have to navigate manually to the security settings to allow an unidentified app.

You don’t need to do that, you can just right-click the app and choose “Open”.

For dangerous ones like WebUSB you can't just click 'Allow' - after granting permission, it shows you a list of connected devices, and you have to actively select the device you want the website to access, and then approve it.

We already have a diverse ecosystem of platforms which are capable of using hardware components for various experiences - we call them "the OS". It comes with a security model, permission prompts and all kinds of bells and whistles (it's a mature platform, developed for decades).

The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages can be styled (CSS) and made interactive (JavaScript).

When one wants to create an experience which goes beyond the scope of the browser, one builds another native app that is able to leverage the needed resources. A dedicated native app can embed a browser (e.g. webframe) or consume web resources through other protocols. A native app can also request access to hardware resources via the OS.

You describe the problem and how the web solves it quite well.

The desktop might be quite diverse, but the diversity on closed, proprietary ecosystems like iOS is controlled by one party. Either, we open up iOS so anyone can distribute apps without Apple being the ultimate authority (like on MacOS), or we enrich a much more mature platform (the web) that we already have to be more capable so we can deliver very similar experiences through the web that we currently build native apps for. Compared to iOS, the web platform is more secure with better privacy controls [1][2], and that feels like a better place to invest our energy.

[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26

I'm not sure how the close aspect of iOS is relevant, it feels like a strawman.

You say the web is more mature, to which I reply that this is the same circumstance as leaving one browser to become dominant (which we already did). In a perfect world, having a closed option would be "one of the options on the table" but for the majority of users this is not the case.

Introducing WebUSB (or any of the more exotic features on the list) will not help us towards an open platform. On the contrary, it will only worsen the dependence on a handful of corporations that can afford to invest to build a browser. Remember, even Microsoft couldn't afford to continue working on their own engine.

As a developer, I care very deeply about being able to make my apps and experiences available to "all the platforms" but shifting the cost of compatibility into userland is not a long term solution. Just put yourself in the shoes of a traveller, struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.

The closed aspect directly speaks to how much diversity you can have on the platform. The features (like WebUSB) aren't the drivers for a more open platform, but they highlight what the impact of having no competition does. Opening up the platform will fuel competition and the market can decide what works and what doesn't. At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].

Chrome becoming the dominant browser is also concerning, and they will have to be held to a much higher scrutiny by us and policy makers to ensure they have users best interest at heart [3].

> shifting the cost of compatibility into userland

What do you mean by this?

> struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.

I agree! This is exactly why we can't depend on one organization to dictate what's allowed and disallowed on that platform. On iOS, think about how long it took Apple enabled Apple Pay support for non-safari browsers even though they all had to be WebKit-based.

[3] https://open-web-advocacy.org/walled-gardens-report/#the-chr...

Even something as simple as auto-focus on a form field on page load... imagine that your keyboard jumps up and takes up half of your screen space, just because a web-dev wanted you to be able to "immediately input your name". I'm actually quite happy that my iPhone doesn't shove a keyboard in my face "for my convenience of being able to input text immediately".

Why would they belong in a platform-specific app but not in a standard-based web app? Because Apple can't get 30% out of it?

Because there's typically at least a minimum of safety checks before an app can go into the app store, whereas a website can do whatever it wants (and can).

Almost all of these APIs still require a user to approve their use in the browser for a given origin.

Next next next finish

Because some of us lived through pop up hell and Microsoft’s lack of security as it relates to web browsers in the late 90s/2000s. Web apps should be as restricted as possible.

Rich companies such as Epic, complaining about a 30% cut can cry me a river. Lock iOS down as much as possible and restrict/sandbox the web.

iOS is the only internet connected computer I’ve had that didn’t get malware and/or a virus at some point. Unless you consider an Xbox/PlayStation a computer.

https://medium.com/online-io-blockchain-technologies/the-evo...

The web lacks intentionality that installed 'native' apps have. You search for a recipie and land on a random blog, executing untrustable code from a countless number of third parties, clicking "I agree" on that modal that says "LiveLaughLove blog and out 1382 partners value your privacy".

Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.

The APIs coming with a security or privacy risk are always gated by a permission prompt on the web (contrary to platform-specific apps). Safari has gone even further by only allowing some of them (e.g. Push notifications) for installed web apps.

These APIs are also much more restricted than their proprietary-ecosystem equivalent.

Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.

And would you build for all browsers or just your favourite "standard"? It doesn't matter how many layers we add, it will always amount to the same challenge when people use different systems. That's why it's generally better to target a solution with the least amount of abstractions to depend on. Build a native app, you depend on the OS. Build a PWA, you depend on the browser and the OS.

As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.

They absolutely do, if well implemented they are no more risk than any other API. The web can be what java wanted to be, if we don't screw it up.

They belong in the browser engine so that they could be used by a web-app that is presented and served as a standalone app. They do not belong in the scope of just any website out there.

Also clipboard reading and volume change, no thanks.

I didn't understand why these APIs existed until I used ESPHome. It can use the Web Serial API to flash an ESP32 board using Chrome + a USB cable.

Many of these belong into a web app, the problem is that browsers can't distinguish between a web app and a web site.

Correct, we need to be hiring 3x the amount of programmers to make our apps on 3 platforms instead of one, webusb is killing jobs!

I agree with you. Notifications is another “feature” I just want to stay out of my browser. To that extent, I actually don’t mind Safari on iOS being deliberately slow to adopt some of the more intrusive standards.

TBH Bluetooth is useful for Xiaomi e-paper clock-thermometers which can't be set without a Mi Home app... smh

Reply on news.ycombinator.com