> Web MIDI API - Allows websites to enumerate, manipulate and access MIDI devices.

This API is actually a bit horrifying from a security perspective. In addition to allowing you to use MIDI keyboards as input devices on websites, it also allows websites to send binary firmware updates to MIDI devices. The reason is that it's common to use custom firmware to backup/restore settings and enable neat effects and functionality on MIDI devices.

Mozilla's engineers have reasonably pointed out that an attacker utilizing Web MIDI could use MIDI devices as a stepping stone to launch an attack against the user's PC outside of the web sandbox. One such attack might be by reprogramming the device to appear as a standard USB computer keyboard and "typing" commands to the host.

At least one well known manufacturer has vouched for the technical safety of their musical instruments, noting that they're physically designed in such a way that the MIDI firmware can't alter USB firmware. But there's no way to know that every MIDI device has been similarly well designed.

As neat as Web MIDI is, I think Mozilla and Apple probably made the right security call here.

https://github.com/mozilla/standards-positions/issues/58

Fun fact: for quite a long time Chrome skipped over the user permission step in the Web MIDI spec, always allowing access and silently giving ad networks a list of connected USB MIDI devices with no user consent:

https://www.obsessivefacts.com/blog/2018-10-20-chrome-allows...

Here's what appeared on porn site xhamster.com once newer versions of Chromium got around to implementing the permission check (SFW-ish):

https://www.obsessivefacts.com/images/blog/2020-04-04-the-ja...

Guessing it was for additional browser fingerprinting.

Not sure why that's more odd than other crazy fingerprinting techniques actually in use. Keep in mind no midi devices would need to be present for fingerprinting. Different failure modes, etc.

Especially in the porn industry where the end users are likely using incognito mode or a VPN.

I still don't understand how WebMIDI would be used for fingerprinting of the vast majority of users who don't have any MIDI devices connected to their machine.

Because thats what you want when fingerprinting....the few users who have one connected gives you probably quite and accurate fingerprint for those users.

I'm sure there are fingerprint libraries that include every possible API that the browser provides. Does MIDI provide a good fingerprint alone? Probably not, but it can serve as a few more bits of information thrown into the mix when implementing fingerprinting. It's not like it would take many engineer hours to add it to an otherwise already functional fingerprinting system.

It's far fetched to think that google added web midi in this way just for a couple of bits of entropy which are essentially worthless (no ad network cares about identifying like 0.01% of people, if even that. Yes it's very valuable entropy if you want to identify those people specifically, but who actually wants to do that?)

The point is not to identify the people using Web MIDI but to identify individual users, regardless of what information exactly identifies them. To that end, every single piece of entropy helps. A good approach to it in general is to opportunistically consume every available API that can possibly divulge identifying information.

A lot of people also do have a virtual MIDI device installed whether they know about it or not. The name of this device differs between different operating systems and operating system revisions.

Well, in this case, a porn site wants to tie what it shows you to what you liked last time you visited. They aren't after your identity per se. They are after a conversion. And since you might be using incognito mode (no lingering cookies), they care about fingerprinting for that.

Edit: I see the disconnect now. I'm not saying Google/chrome added the midi API for fingerprinting. I'm saying the screenshot way up this thread is an example of a site using it for that purpose.

Here's a jsfiddle: https://jsfiddle.net/wj69s4fh/

I get different types of failures and messages from different versions of Chrome, Firefox, and IE. None of which have any midi devices. Those errors, or the structure of the resulting object if it succeeds, are all fingerprint inputs.

Yeah, ran it in Chrome, the browser didn't say a thing whatsoever and I see MIDIAccess object in JS console. Nice to know the browser just allows this entire API by default.

I would guess quite a few browsers or operating systems would implement at least one virtual MIDI device, so that sites wanting to play MIDI would work. Those virtual devices wouldn’t all be identical.

It might be a way to detect bots, even on headless browsers, that pretend to be Chrome but don’t implement the MIDI api. I’m sure crawlers are the bane of the porn industry.

It takes almost no work to check all available browser context, once you check for some of it.

Why? All kinds of details are already being used for fingerprinting

If this pun was intended, I'm phoning the World Court.

Please, make the call.

Besides, I know they want to turn the browser into an os, but it's not one.

It's sandboxed from the os and limited to some use cases, which is the point. I don't want something capable of hot loading code from any web site to have the capabilities of my OS.

The browser is indeed an application platform. Even HackerNews is an app, although it uses a minimum of browser functionality.

Maybe you don't want things like videochat or paint programs or music learning apps to run in a browser, but lots of people do.

Imagine if Firefox said "we're not going to let any web page access the camera"... their market share would probably drop in half overnight.

I wonder if and when the splitup will happen between the "text" web and "app" web.

I know you can disable Javascript, but this is still different.

I am have dreamed of a browser that lets me create desktop shortcuts to webapps and then pretend as if the webapp is its own fully independent application but all webapps would still run in the same browser instance.

Chrome lets you do exactly this: https://support.google.com/chrome_webstore/answer/3060053?hl...

I imagine other browsers probably do, too.

What would Hacker News be? How about email apps such as Gmail or Yahoo mail?

Both can be the text web.

I am fairly certain that I have posted to Hacker News with Lynx, which means that everything is handled server side.

About 20 years ago, I created a personal webmail client that was implemented entirely on the server side.

The distinction is important and while it would produce a very different web, but it does not mean a web of static content.

Well, I can certainly login, navigate to this comment, and then reply with Lynx.

It's not a great experience, mind, but it does work.

Upvoting and downvoting work too last time I checked.

The three categories I would make are: text, static forms, and SPAs

There are email clients.

>Do those clients work on my mac, my chromebook, my windows box, and my android phone?

Yes.

>Call me crazy, but I prefer web apps for that kind of stuff. I'm also glad I don't have to download an app to use Hacker News.

Web means HTTP, Email is POP3/SMTP/IMAP. Different protocol, different programs. That you can use a website to view and send emails is not the default case and is merely a interface to those protocols.

I understand how email works. "Default case" is a matter of interpretation. Most people today use web based email (at least on computers as opposed to mobile devices), and it is much easier for most people to set up and get working than using a native client. The vast majority never think about wire protocols. I have implemented both HTTP and SMTP in C etc back in the day, but that is not relevant here.

Regardless, I said my preference is to use web based email, that's all.

It's not about how people use it, the RFCs are clear on this.

What's "it"? "The relevant issue"?

Because the relevant issue is most certainly how people use it. People use web browsers to read their email. Why is what the RFCs say important to this?

Because the discussion above was about email. A browser is not a mail client (as in MUA). Unless a browser implements the RFCs regarding email, it's only a web browser.

>How about email apps such as Gmail or Yahoo mail?

So the answer is: It doesn't matter as those are not email apps. They are email frontends for a service that implements mail. If people think differently - it's their wording, but still a wrong one.

So you're just spinning on the definition of "email"? As opposed to recognizing that a particular activity people do (which I call "using email" but maybe you have a different word for), is very often done using a web browser.

Why you'd think debating the semantics of the word "email" is relevant to the discussion is beyond me. It makes me almost wonder if you are attempting to parody a certain type of pedantic technical person.

Words matter.

Average users won't do it.

Manual security = no security

It's kind of sad though because it's still 10X easier to build a browser app than a native app simply because of the wealth of highly-usable stuff written for JS.

Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.

Android programming is another can of worms and I'm frankly fed up with Gradle updates breaking my project every update and needing 79+ files, multiple cludgy steps for signing APKs, zipalign (wtf) and other crap just for a Hello World.

What would be nice to have is "installable" apps that use the webkit rendering engine but have full access to the system including directly opening TCP ports and direct access to /dev. These would have to be trusted apps obviously. Websites that load code without consent should be restricted, of course.

> Every time I have to build a GUI in Linux I just build a webapp that connects to a TCP backend on localhost because that way I can just build a beautiful UI in HTML/JS/CSS and I don't have to deal with the mess that is GTK, QT, TCL, TK, and all that crap.

I suspect this has more to do with the state of native Linux development tools versus Javascript dev tools then it has to do with the general case. Dev tools for Windows and iOS/ MacOs are fairly straight forward. Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)

Update: I'm basing my comment of what it's like based on the quoted comment, not making an assertion about how good/ bad it is.

> Dev tools for Windows and iOS/ MacOs are fairly straight forward.

Can't speak much for Windows, but the Apple dev story is pretty good. Platform SDKs are deep and capable, if sometimes not well documented, and there's a clear "right" way to do most things. One can build a "world class" app with nothing but Swift+UIKit and few or no third party libraries. SwiftUI is rapidly improving this too, bringing a fully native "modern" reactive approach that works across all Apple OSes.

Xcode can be a cantankerous beast at times but it's been getting a lot better in recent releases.

> Not sure about Android, since my burning hatred of Java has removed my desire to mess with that platform entirely. (I know Kotlin exists, still not interested)

It's slowly improving but still very much a mess. Jetpack Compose looks to be poising itself as the SwiftUI of Android and that will no doubt improve things, but I have doubts that Android development will ever be as nice as iOS development is.

> IntelliJ Idea is a fantastically better IDE than XCode from a functionality standpoint

This is not my experience, I've never quite cared for all the finicky setup needed to get things right, and it always feels a bit laggy. (Though IntelliJ is a world better than Eclipse).

It's definitely more laggy, but in terms of everything else, it's light years ahead of Xcode:

1) code navigation, editing, refactoring 2) integration with Git/GitHub, Issue Trackers, Cloud Providers 3) external build system support 4) multiplatform editing (java, js, typescript, kotlin, python, etc) 5) integration with testing, continuous integration, deployment 6) code analysis, finding problems 7) tons of special support for DSLs and third party frameworks

The only thing XCode is better at IMHO is UI building and OSX instrumentation. If you're writing tons of code that doesn't have a UI, especially for cloud backends, I don't think you'd use it.

Even simple things, like language injection, work wonders in the editor window. Having the IDE know how to syntax color, check, and code complete SQL, CSS, HTML, Regex, etc inside strings is a huge help.

I spend 15 years on emacs, and the last 15 on InteliJ, and having an editor that slices and dices code in a myriad a ways with easy to use automation, and actually indexes the code and builds a deeper understanding of the totality of your project is well worth it. I just wish it was less laggy in the UI.

If I was writing an iOS app, sure, I'd use XCode, but I can't envision being it general purpose for anything else, unlike the versatility of other competitors like VSCode.

> If I was writing an iOS app, sure, I'd use Xcode, but I can't envision being it general purpose for anything else, unlike the versatility of other competitors like VSCode.

I would never expect Xcode to be the best general purpose editor/ IDE. It's good for Swift/ iOS development which is what its build around. Personally, much of the time I'd rather have a performant editor than one that has a million bells and whistles.

> Dev tools for Windows and iOS/ MacOs are fairly straight forward

Are they? It's probably been a decade since I touched a native GUI (and I was without a mentor and working on already-old software) so I legitimately don't know. Using something like Visual Studio's form builder was fine enough, but it was not a very expressive toolset as I recall.

Web you can get started "instantly". Your browser covers most of the tooling you need and you can tweak any live site.

I don't like that that's how it is. From an abstract perspective I'd rather not be working on web because it seems like we're trying to make a better car by building a bicycle inside of it. But the low bar for entry is hard to beat.

> Web you can get started "instantly". Your browser covers most of the tooling you need and you can tweak any live site.

Obviously you can splat some HTML into a browser and get instant results, but once you start talking about apps with even moderate amounts of interaction, the simplicity of web apps falls away quickly. If you are talking about a sophisticated app, I don't think the complexity is any less when you are using javascript/ React versus Swift/ UIKit. The big win I've seen for javascript/ web apps is the fact that you are reasonably platform independent, obviously if you use Chrome and Chrome specific APIs, that falls away too.

I had to get back into C# a year or so ago to build a commercial internal production management application, WPF with XAML was exceptionally pleasant to work with and the final product just worked with few issues.

It felt weirdly like writing Vue-like code.

Microsoft nailed it imo, VS2017 and C# have come along way since I used to do .net 3.5 stuff.

I really liked C#, it’s http and a sync/await stuff was excellent.

Why not just use GTK or Qt?

GTK:

    import gi

    gi.require_version("Gtk", "3.0")
    from gi.repository import Gtk


    class MyWindow(Gtk.Window):
        def __init__(self):
            Gtk.Window.__init__(self, title="Hello World")

            self.button = Gtk.Button(label="Click Here")
            self.button.connect("clicked", self.on_button_clicked)
            self.add(self.button)

        def on_button_clicked(self, widget):
            print("Hello World")


    win = MyWindow()
    win.connect("destroy", Gtk.main_quit)
    win.show_all()
    Gtk.main()

HTML:

    <html><body>
      <button onclick="alert('Hello World')">Click Here</button>
    </body></html>

Now try implementing a swipe tab UI in GTK with animations and embedded video. In HTML you can probably import someone's awesome library .js file and be done with it in 5 minutes. Video is a snap. In GTK you have to deal with some idiotic factories, pipelines, sinks, faucets, and other god-knows-what abstractions. In HTML it's just <video>.

You could also use a glade file and only worry about functionality on the code itself. It's not too bad.

What is the problem if the user give the permission to do so?

I don't get this let's not allow this web api because it's dangerous, well you only move the problem to an application that the user installs on his PC.

If the permission mechanism is correct there is no danger, a web applcation wants to access my MIDI interface or my USB or Bluetooth or whatever and it can. Isn't the same for mobile applications and permission?

So maybe and I say maybe we could stop having to ship an entire Chromium engine with Elecron just for a web application to access devices or files on the computer.

Because people don't expect their web browser to be able to brick their hardware.

Then change the expectations. Native apps aren't much better as far as privacy goes. Users should absolutely verify everything they use.

Sure but for a long time web has been touted (rightly or wrongly) as this safe sandboxed convenient distribution platform. The expectation is very much still that a website shouldn’t be able to harm your computer and that expectation isn’t going to change any time soon.

In top of that, less technically inclined people don’t even expect native applications to be able to harm their computer and we haven’t been able to change that expectation.

That's why I have almost no Apps on my phone. Just a lot of different browsers. I think the new mobile Vivaldi browser is the first with an option to switch of the 3d sensor for the website

Native apps go through an approval process

Correction: some native apps on some platforms

Correction: Native apps on the platform this thread is about.

Not only brick the attached device, but also potentially fully compromise either the attached device or the device you are on. It doesn't seem responsible to put that kind of tis behind a permission dialog. Users are not in a position to make the judgment. The web should have a higher standard of security and privacy.

If the user is going to be tricked on the web, they can be tricked in other ways. If the web doesn't support MIDI, users will just download MIDI malware as an app.

By your logic, the web should not have video support either, because users are users and it will inevitably be misused.

If you were serious about addressing this: We need clear and robust and granular permission dialogs on web and native apps. Ideally they'd be consistent across web/native, which would help users trust their software, and understand the permissions they give.

And then we need to crowd source what the default should be for each site, because otherwise every site will have 100 permission popups

Couldn't we hide the rarely used features behind a checkbox in advanced settings?

One point not discussed here is by relying so much on app store and apple's walled garden, what do you do when china or other country ask apple to remove certain apps?

Bypassing geo block on websites is easy and there isn't a single source of truth on the web like app store is for the users. Can apple explain why they took down apps on the request of china in HK and how do you think that will play out when no web apps can work reliably on apple devices?

Censorship is a huge problem for app stores. They censor anything sexual but sexuality is part of human nature. They censor anything politically charged but it's part of human nature too. I hope the anti trust fine plays out.

Apple can protect the privacy of people by making it harder for them to be vulnerable by choice. People here point towards stupid users when saying that a normal user won't be able to connect usb and enable a feature. Why can't the same happen with browsers or apps on ios? Why the $99 fee just to side load apps? Why the need for a mac?

Just admit it's for profit seeking reasons. Ads in your app store are a proof of that.

It's still possible to partially implement it while keeping it safe by excluding sysex messages. Probably more than 90% of the end users will never need sysex messages so why bother?

> so why bother?

maybe 10% is enticing for those who create botnets

I’m pretty sure GP meant why bother implementing sysex messages.

Personally, I think that’s the solution. Provide access to the most common and safe features while disallowing the unsafe one. You’d still get far more functionality than you have now and only sacrifice a little in exchange for safety (vs not having any at all).

yeah it will be interesting to see how it evolves

I'm curious now that I read this, this means that web midi can access the virtual midi devices created under alsa on linux also? Which means if you have it routed to other software using Jack or aconnect, websites could send midi notes directly into whatever software your midi device is routed through?

So theoretically then, could a Jack aware payload be created that runs in the background, say disguised as a vst or ladspa plugin and when a user browses a malicious site, this site could, recognize the malicious midi device, create connections to other software and gain access through possible buffer overflows or other things?

It seems like a stream of midi notes could itself possibly cause a buffer overflow in certain programs. Muse and rosegarden are a bit buggy as is and frequently crash for me. From what i can tell there's a lot of midi aware audio software that likely contains a bunch of avenues for exploits and when you throw virtual midi devices into the mix capable of doing far more than hardware midi devices...

Why not just limit allowed midi status to: Note On, Note Off, CC, Aftertouch, and Pitch Bend? Or maybe be readonly?

Is there a way to escalate that I'm not seeing? AFAI remember, all programming is done through status messages 11110000 and above.

https://www.midi.org/specifications-old/item/table-2-expande...

Full Disclosure: I made a web synth and really want to be able to use midi to play with it.

I don't see why the API should even allow enumerating devices. Put that behind a browser dialog. Webpages don't get to enumerate directories/files on your system - they pop up a file picker dialog. The same should happen with device selection. Once you've granted the site access to a device, it can ask you to associate a name with the handle, and provide whatever shiny device selection / device management UI it wants.

Better yet, reasonably abstract the raw MIDI protocol away with something that has suitable security and privacy properties for the web, and translate it to MIDI on the host. In any case, the current proposal does not seem to cut it.

I agree that it would be nice to have a limited amount of the Web MIDI spec, but bear in mind the staggering few people who actually have MIDI devices, and the even more staggering few of those people who want to use whatever website has midi support for its features.

To answer your question about why not to just limit the API: because that would be another data point to use to fingerprint users, and because the amount of engineering time that would have to go into Web MIDI support (including testing, security auditing, etc.) would never be worthwhile compared to putting those same developers on something that might be beneficial to vastly more users.

(Also note that Firefox made the same decision to implement nothing at all.)

This is just a philosophical standpoint, but I think supporting the interests a small group of experimental pioneers is generally more useful than their numbers would imply.

The idea that "staggering few" is a negative disappoints, given it has almost always been the "staggering few" who've progressed humanity.

Yeah. It's crazy to me that they haven't decided to create some abstract virtual midi instrument. That you can instruct the browser to pass through to your devices.

It's a shame, but it proves just what a futile affair it is to retrofit ancient protocols that never had to consider host security. Especially because MIDI is so elegantly simple!

Sending binary firmware updates (sysex) is not a necessary part of the API... they don't have to implement that, and if they do, they can ask for additional permissions.

Allowing you to use a keyboard as an input device is incredibly powerful, and even that can be handled much as camera and microphone is: you give the site permission.

If you get the MIDI device to act as a keyboard it’s not for typing things in the browser but in the OS... you are out of the sandbox so it’s possible to download and install any payload.

I don't understand what you mean. We're talking about a piano keyboard by the way, not a typing keyboard. The browser uses it via the MIDIAccess API, and simply sets up a callback for MIDI codes, such as noteOn, noteOff, etc. I have used it extensively.

The alternative is that users download executable to apply firmware updates. Then the attacker doesn't even need to find a hardware vulnerability!

There may be some legitimate fingerprinting concenrs. But given the list of API's it's hard not to see this as Apple crippling PWAs to prevent them from replacing native iOS apps (and hurting Apple's revenue from the Apple tax).

And maybe I'm missing something, but wouldn't the fingerprinting concern be mitigated by the fact the app has to ask for permission before using the API? If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.

Exactly. This is about making sure web apps are not as powerful as native apps.

One thing is the revenue generated by the App Store but suppose JavaScript web apps were just as powerful and well integrated as native apps; then why use native apps at all? Why have an App Store at all? Why have a Mac or an iPhone if any device with a modern web browser would do?

When Huawei tried to create their alternative to Android. The big thing missing wasn't the hardware or the operation system. It was the App Store with your map app, your banking app, your scooter app and so on.

The App Store and the proprietary development platforms for Android and Apple has become a way to keep their duopoly in place.

I like having apps that work and feel the same. I can bring my knowledge from one app to another. I can develop expertise on a platform. The web is culturally unable to do that.

Look at a sophisticated web app, like Google Docs. This has a menu bar, which is a bad copy of the native Mac menu bar. Web apps are copying native app conventions, to try to be more familiar. But they're also eroding those conventions.

Eventually only click and swipe will be left. And this problem is not going to be solved by Web MIDI or whatever.

I think you’re trying to say that Mac OS or Windows native apps have pretty much the same UI/UX conventions which makes it easy to use any app on that platform. And that Web Apps have UI/UX that is less consistent than apps across OS’s.

I can’t say I agree with this. There are a ton of MacOs apps that implement fully custom GUI (first one that comes to mind is Jira native Mac app which looks nothing like a Mac app I’ve seen before)

I agree web apps are likely eroding OS conventions though. The Jira app is an example of that (they decided to make their native app look and behave the same as the Jira Web App instead of using standard MacOS GUI conventions.

It’s a tough trade off.

Yeah and Spotify is another one. Electron is clearly at work here, probably in your Jira example too.

These apps are frustrating for someone accustomed to the Mac UI. Basic interactions (like context menus) don't work at all, or work in unexpected ways. I have no idea what these apps can do because they all have a unique UI vocabulary. So I don't try.

I think Apple has really dropped the ball on this. They ought to have spotted and embraced the web's great strengths early. Ephemeral, zero-install apps, using native components - that's the platform I want. Though I understand how others may disagree.

Android supports PWA and let's you install apps without their app store, not the same as apple at all

Isn't Google the one implementing all these APIs though?

But for google, the benefits of having richer web apps on which they can show you ads and have app developers pay google for ads may be more valuable than any revenue they lose from the app store.

Speaking as a Xoogler, there's no coordination between the teams building Chrome APIs and those working on Android. Leadership is content to see what sticks (and they may be right).

Sure, they are not micromanaging the Chrome APIs or the Android APIs. But the strategic direction is clear: "develop more web APIs and make them useful, so more people stay on the web so we can show more ads."

No. This is about privacy.

Why have native apps at all?

Because web apps are crap, excuse my Swahili.

Do you honestly think that Apple would lose enough money by implementing Web MIDI for Safari on iOS that this would be even the most remote consideration? Like, the Safari team was in a meeting about Web MIDI and some manager said "but think of the impact on our stock options!" and they all went "oooooh" and scrapped it?

Or is it that Tim Cook was looking at Apple's balance sheet and decided that they couldn't afford to lose the 30% cut of all the MIDI-capable iOS/iPadOS apps that could be completely replaced by a web app?

The reality is that the real cost of this feature to them would be developer time; it would be a colossal waste of their limited WebKit/Safari developer resources to implement Web MIDI rather than something that would actually be used by more than a scant sliver of a percentage of Safari users.

apple fanboys will accept anything from apple. No headphone jack? it's an improvement! w3 spec not implemented? they are working on more important features! antenna stops working if you hold the phone wrong? I like it that way!

I wished they implemented the Fullscreen API for iPhones...

> If an app that doesn't have to do with MIDI asks for permission to use my MIDI device, I'm going to be instantly suspicious.

Sure, you'll be suspicious, but I seriously doubt you're the average user. I bet a very large proportion of Safari users have no idea what a MIDI device is and some significant portion of them wouldn't think twice about granting those permissions.

I'd assume the small percentage with a midi device who are going to music app websites would be more likely to know

Anyone can request MIDI permissions.

The parent comment implies a bad actor using the API for something like fingerprinting, and a common user who may have never even heard of MIDI, let alone have a device.

But won't the user then go "why would I allow this website to access something I don't know about?" or, if they clicked yes anyway, the entropy would be ~0 as they have no midi devices.

This is assuming we moved to a model where more permissions had to be requested rather than just allowed

No, of course they wouldn't. You or I would, sure, but a regular user is pretty much conditioned to accept whatever to make the page load.

If they don't care about privacy enough to learn about it, that's fair, no point wasting your time to avoid a problem that isn't affecting you much.

Are you all serious about this ask for permission thing? Good luck explaining MIDI, HID, NFC and so on to the average Joe, in a small popup. We already have enough “I agree” buttons popping over the screen. Web should be built for everybody, it’s not the nineties anymore.

Sorry, but Average Joe needs to learn this one thing to adapt to the modern web:

Say no.

Average Joe doesn't need to learn what all these things are. In the unlikely event he knows what the thing is and knows that he wants it, he can answer yes. But his default response needs to be no.

>Web should be built for everybody

Exactly. That's why Average Joe needs to adapt.

Sure, but Apple could solve that by requiring a user action to show that popup dialog. Or they could even block everything by default and force you to give permissions manually. That way average Joe is blisfully unaware of anything and completely safe while you just have to suffer a minor inconvenience of whitelisting that one legit website the first time you use it.

I don’t even want these 16 api’s. I want a way to do notifications and a way to store more than 50 mb on ios. Sure, make me and the user jump through hoops to make sure I’m not abusive, but with those two there are a ton of apps which I can build as pwa’s.

The app clips feature they showed? That should have been a qr code triggered pwa with notifications, except everybody had to build it as an app because they couldn’t do notifications, and then apple used the cumbersome nature of those apps as the reason for app clips. It’s the snake eating its own tail, and I’m getting IE6 vibes because microsoft also strategically stopped improving IE for web apps because they wanted to push app developers to native because of the improved user experience. Yeah, the web is worse, but worse is better.

I’m very glad a web page cannot store 50mb data and send notification to me.

You only think from a developer’s perspective. What if you are the user receiving 50 notification requirement a day from a web browser?

Then you tap on the notification and say "turn off" and then it stops happening.

This isn’t able notifications, this is about the “do you want to allow notifications” prompts. Crazy how in the same HN community you have people on one post complaining that there are too damn many cookie/gdpr/etc prompts, then on the next post asking for additional notification prompts. What ever happened to going to a website and consuming its content and leaving?

I get that making an app instead of a PWA is a pain the in the ass, but the reason I pay $$$ to Apple is so that pains like that exist in the developer’s ass instead of mine. I want to be in their walled garden and I want them to keep lazy developers and poor UX out.

> Whatever happened to going to a website and consuming it's content and leaving?

The internet became more powerful so it does more things. The PWA spec allows for zero-install apps that are just as performant (or more) than native apps. You can view their network requests in the console, and they run in a sandboxed environment. You want to download and install a binary for something that can be accomplished in a few kb of cached JavaScript?

I don’t want any websites sending me any notifications ever.

I don’t want any websites triggering the browser to ask me if they can send me notifications.

I don’t want any websites asking me if they can ask the browser to ask me to send me notifications.

I don’t want any websites using their classic scams like tiny “x” buttons that have insufficient contrast and are impossible to click on a mobile device anyways to ask me if they can ask the browser to send me notifications.

I don’t want to see my grandma dealing with scammers who trick her into allowing potentially phicious notifications that she doesn’t know how to cancel, or even what the source is.

I want developers to jump through as many bullshit hoops as possible before even having the chance to send me notifications. Apple and their review prices help me out there, and for all above points.

It seems to me like you believe everyone is the same as you: they value small package size, they personally audit all code they run, they want random corporations to have an easier time getting a presence on their home screen, and they’d be able to easily identify and stop all corporate badgering they do end up receiving. I don’t think any of those are true even for me (someone in the industry), let alone the population at large.

> I don’t want any websites sending me any notifications ever.

I agree with you actually, but not everybody does. Some people do want push notifications when they get a new email or Facebook update. I wish it weren't so, but it is.

> I don’t want any websites triggering the browser to ask me if they can send me notifications.

> I don’t want any websites asking me if they can ask the browser to ask me to send me notifications.

> I don’t want any websites using their classic scams like tiny “x” buttons...

Given that we live in a world where there are notifications, you have the choice to disable them on your device, or decline them on a site by site basis. For your grandma, I'd suggest the former strategy.

But if you don't want the site to ask you, and you don't want the browser to ask you, and you don't want to disable them for all sites, you're setting yourself up for disappointment. All the whining isn't going to bring back 90s internet.

> It seems to me like you believe everyone is the same as you: they value small package size, they personally audit all code they run, they want random corporations to have an easier time getting a presence on their home screen, and they’d be able to easily identify and stop all corporate badgering they do end up receiving

What's the difference between a native app asking to send you notifications vs a web app?

> I don’t want any websites sending me any notifications ever.

> I don’t want any websites triggering the browser to ask me if they can send me notifications

That’s fine for you but some of us who are in niche communities or have weird applications don’t want to wait for a VC to fund the development of a native app.

Right now I can’t get notifications from IRC at all which pushes me and everyone else to centralized chat services. This has distorted the evolution of the internet and I would argue has contributed heavily to the “fake news” problem.

> It seems to me like you believe everyone is the same as you

You’re projecting. We want a feature that the user can disable, not ever being able to use this at all means everyone has to want the same things you do.

I clearly outline how “a feature the user can disable” is the same as “a gdpr/cookie/telemetry/etc prompt the user can reject”

It doesn’t take a VC to make an app, I made some starting in HS (with push, yes), and you can too. Be the change you wish to see.

>I clearly outline how “a feature the user can disable” is the same as “a gdpr/cookie/telemetry/etc prompt the user can reject”

You're clearly wrong then. iOS already does something similar with location and doesn't suffer from this problem.

>It doesn’t take a VC to make an app, I made some starting in HS (with push, yes), and you can too. Be the change you wish to see.

That's actually kind of upsetting. On my other machines I do fix problems. The cost of volunteering to deal with apple's shitty phone is an overpriced machine where even the old used desktops are more expensive than the modern one I just built, the time it takes to learn a new language and an (IMO pretty crap) environment (GUI toolkit not withstanding,) the time it takes to maintain an app for a platform with constant API churn, and $100 a year for a developer license (nope, you can't use push notifications without paying this.)

Here's the change I want to see: people abandoning an abusive company. I'm buying a pinephone so that the next time I have a problem I can deal with it without having to buy the beater car equivalent of a computer (and spending as much.)

None of us like the crazy number of prompts.

Most (all?) of us like to be the one who controls what we can do with our own devices.

These standards return some control to the user, rather than the corporation.

But then we get more prompts! Well, not necessarily. The user could choose to have all prompts automatically rejected, and only opt-in when they desired. This would not create more information for trackers to track, because Apple could make it the default for all of their devices.

This seems to solve the problem: People who want the features can have them, and the people who don't want them can ignore them without interruption.

This is where our problem with Apple is: there are solutions to be found but rather than solve them, Apple hides behind lies in order to protect their bottom line while harming many users and the internet as a whole.

I don't want that notification.

Despite this, I believe PWAs will eventually win, and Apple will be forced to comply if they wish to stay relevant.

Their browser share dropped a little recently (https://gs.statcounter.com/browser-market-share). If that continues, it'll certainly irk them!

IMO, that won't happen until either Apple gives up their control on browser "engine" choices on iOS or Apple itself becomes irrelevant.

Consider that browser share usage could shift around as device usage shifts around during a pandemic.

I don't disagree, but would you expect such a significant drop in Safari usage?

It’s possible if people are using company-provided devices at home in lieu of their own, and the company is providing Windows devices while theirs were Apple. I don’t know the likelihood of this explanation, though.

I would personally think this is unlikely. Looking at https://gs.statcounter.com/browser-version-market-share we can see that Safari on iPhone probably caused the overall drop.

Now, I can't see people suddenly not using their iPhone because of the pandemic (quite the contrary actually) - perhaps this signifies a slowdown in iPhone sales?

Apple is a corporation listed on a US exchange, an entity where the only motivation is to generate profit for shareholders. It helps for corporations to frame business decisions in moral terms. If Apple cares about privacy, it is only because there is alignment with profit. If Apple cares about locking out APIs that disrupt their App Store profit, it doesn't hurt to frame the decision in privacy terms.

Currently my desire for both privacy, convenience, and usability align with Apple's current business decisions, so I choose iPhone. When Apple pivots to a new business model, I'll find the best compromise product.

I disagree strongly. Apple leaves money on the table by not aggressively tracking its users. And their investment in e.g. accessibility is certainly not driven by bottom-line considerations.

Apple is relevant today because they actually are focused on products, not profits. Sometimes it really is that simple.

It's naive to think any company exists for any other purpose than maximizing profit. That's business 101.

Every time I see this argument I have the same question. How many successful web apps are there for Android? Apps that make the most money on the App Store are free to play games with in app purchases of loot boxe, coins, etc. how many of those are feasible on the web?

On the other hand, which apps that make money via in app purchases would be viable and successful as web apps?

I think most would be as successful IF they had an equally frictionless payment system. Big hits like Candy Crush could easily be built as a web app. These are not pushing the boundaries of software, they're just exploiting our psychology.

If PWA support is so good on Android, there should be a lot of successful profitable PWA’s on Android. Chrome supports the Web Payments API that should make payments seamless in the browser.

I have removed all my e-commerce apps and use on web versions of those on my phones (Flipkart agrees - https://www.pwastats.com/2017/08/flipkart/ ). I saw my parents doing the same when they uninstalled a bunch of apps like FB & Pinterest and started using the web versions instead to save space and don't seem to have any negative experience.

Which still doesn’t support the argument that Apple wants to cripple PWAs because it makes money on the App Store. Those apps would have been free on the App Store and since they are selling physical goods, Apple wouldn’t have made any money on in app purchases.

I mean it gives credit to the theory that webapps (PWAs in particular) are gaining tractions and big companies are paying attention to it because people are actually using it, which means Apple is afraid it might loose it's stranglehold on the app economy.

The types of apps that are theoretically “moving to the web” aren’t making Apple any money anyway. There is no evidence that there is a trend for the types of apps that actually benefit from in app purchases are moving to the web.

All of the APIs that Apple isn’t supporting wouldn’t help a single major revenue producing app move to the browser.

PWA support is still pretty new. It will take some time before we see a lot of really successful PWA deployments.

counterpoint to that argument: if you want to create an app that runs on both Apple and Android products, and you know that Apple doesn't support the progressive web app specification, why would you waste your time? It makes more sense to use a cross-platform development tool and release on the app store when one of the two big software platforms doesn't support the spec.

Any app that you wrote would also have a web equivalent any way for non mobile environments. So why not just do an iOS app and a web app?

And still waiting for someone to give me an example of an app that makes a lot of money on the App Store through in app purchasing, that could probably make just as much money as a PWA if it weren’t for mobile Safari.

But the implication of this argument is that the benefit of PWAs is to the developer rather than the user, right? If PWAs actually benefited users, then creating one instead of an Android app wouldn’t be waste of time even if you had to create a separate iOS native app in either case.

Yep, seems like apple made another move against the web.

PWA's have always lagged behind Native Capabilities, even when API's exist the performance has been poor for high performance apps so the allegation doesn't quite make sense to me.

Almost certainly an excuse to further suppress PWAs.

Google's developer relations team have done a good job convincing web devs that those APIs are pushed by Google to enable "Amazing PWAs", yet we haven't seen them used by any major app. People are choosing to download native apps for more sophisticated applications.

However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.

So sad that Google has taken over the web. From the most used browser (Chrome) to the content hijacking (AMP) to the standards (PWA). All to sell you to advertisers.

On Android you can use web apps in Firefox, with content blocking powered by uBlock Origin and Privacy Badger. This is because Android allows real Firefox, engine and all and Firefox implements the web push API.

This gives you unmatched privacy. As I've said elsewhere too, see this Facebook page listing apps that share data with them via FB's SDK and marvel at how privacy friendly your iOS device really is:

https://www.facebook.com/off_facebook_activity

The notion that Apple is not implementing the web push API for example, for privacy reasons, is stupid.

"Your off-Facebook activity is currently turned off."

Seems fine to me?

The problem with having an Android phone is that then you have to actually use the damn thing.

On a more serious note though, in iOS 14 app developers are responsible for any SDK's their app uses including data egress.

If PWAs die, we will be struck with this duopoly in smartphone OS for foreseeable future as native apps are the ones which help them retain their position.

If we want upcoming pure Linux smartphone OS, Sailfish or any other platform which protect the mobile computing from becoming proprietary; we need web apps & PWAs to grow and capture significant market.

Apple's treatment towards PWAs has been well known as PWAs are the only threat for its Appstore monopoly in iOS.

From a developer's point of view, I can see the value in PWAs (for them), but as an end user, I really don't see the benefit of PWAs over native apps. The UX is almost always severely degraded when compared to their native counterparts (even if the feature set is ostensibly identical). Why would I use a Twitter PWA, when the native app provides a much better UX?

Why would I use the Twitter app, when I can get the same out of the PWA and not have to download a hundred meg update every week for "bug fixes and improvements"?

Maybe in the case of Twitter it makes sense (I'm not using Twitter myself), but in general, as the OP notes, the UX is worse with PWAs than it is with native apps. So, to rephrase your comment to reflect this

> Why would I use the app, when I can get /something worse but workable/ out of the PWA and not have to download a hundred meg update every week

And then the answer might be --- because your phone has 128 gigs of memory, your home wi-fi has unlimited bandwidth, and the updates all get downloaded automatically while you're sleeping, you might decide to go for the better UX in exchange for nothing at all.

Or just use Tweeetbot, it weighs in at 7.2MB and the last update was 8 months ago.

Every time I load the page for a tweet in their PWA on iOS it gives me an error, and then I reload the page and it works fine.

Why would I use the Twitter website, when I can get the same out of the app, it loads faster, and it actually works consistently? Plus I don't have to log in in app webviews all the time.

Downloading a PWA isn’t smaller and it also needs updates just like a native app. And the answer to your question is the comment you replied to.

As a developer who has tried to love PWAs a number of times I don't see the value. Users simply do not like them and for good reason.

Just this last month I have been building an app to manage my pantry (keep track of expiration dates) using QR codes I stick on everything. I built the "app" in VueJS (wanted to sharpen those skills) and did the whole thing in the browser. Scanning QR's and scanning UPCs (to track items) was all done using browser apis. I then tried to use it on my phone and hated dealing with the loss of space to the browser UI and it hiding/showing as I scrolled. It was a terrible experience.

So I migrated all my code over into Quasar (a VueJS framework that will let you build for PWA, SSR, regular web, and Cordova/Capacitor. I told myself I wasn't going to use cordova for this, I was going to stick to the browser and try to make it a homescreen icon. It was still shit. It was a pain to get the app to go fullscreen and not pop webkit views on top of my "app". The nail in the coffin was Apple doesn't let you have camera access when the app is running in that mode (it's really just unacceptable IMHO). I spent <10min getting the cordova app running and it's been smooth sailing ever since.

I still do some development on my laptop in the browsers but I would never run a PWA if I had the option of an app (even a cross-platform web app in a cordova wrapper).

>The nail in the coffin was Apple doesn't let you have camera access when the app is running in that mode (it's really just unacceptable IMHO)

So, who's the culprit here? You were able to create an app which can perfectly run in browser but now apple forces you invest in hundreds if not thousands of dollars in equipment, effort in learning a new programming language(although it's open-source), $99 every year for license and give it 30% cut of your revenue when you earn it just to preserve its monopoly in Appstore?

That's my argument, issue is never been the PWAs it's Apple's support for it. So, is the reason it doesn't allow any other browser engines on iOS as well. Apple has branded 'Privacy' and uses it for weaponising marketing.

Edit: Forgot the yearly license.

That's a completely fair point and you are 100% right. Apple is the culprit. Unfortunately me making PWA's won't fix that problem and while I agree they are in the wrong here I'm not going to switch to Android or expect my users to do so. I do wish Apple would change but this isn't enough of a thorn in my side to force me switch OS's.

Thankfully I already have another reason for paying for the app store dev program so I am able to leverage that for my own personal apps or ones I might publish.

PWA's or web experiences are "good enough".

I would never use a social network native app, ever, as the category has a history of abusing privacy, poorly utilizing resources or any number of other things.

For business, it's a much easier decision. If I can do what I need to do in a PWA, why futz around with iOS, Windows variants, and multiple versions of Android apps? App Stores are a much bigger PITA than shipping web code, and I don't have the time, budget or care to make a polished user experience for employees.

I remember when Alan Kay said "The computing revolution is Good Enough."

Business apps: do whatever, who cares. Social networking is its own hell and yeah, sandbox that stuff (for now - doesn't have to be that way).

Apps intended to be tools, to be vehicles for creation - well those are rarefied these days, huh!

Native apps are hard to develop and publish through app stores compared to PWAs, and many users don't have access to Play store.

Web apps are also more strongly sandboxed which is important considering how much of Android install base is running on devices without security updates. (Android devices notoriously stop getting them after only couple of years after device launch, or even sooner)

> From a developer's point of view, I can see the value in PWAs (for them), but as an end user, I really don't see the benefit of PWAs over native apps.

I suspect the bigger demand for PWAs is for non-consumer apps. If you are selling to businesses or building internal apps for a business, often delivering a multi-platform + web app with decent performance/ UX, often a PWA or PWA + Web platform is the way to go.

> Why would I use a Twitter PWA, when the native app provides a much better UX?

This is why I think vertical/ internal apps make a lot more sense for PWAs. If consumers have a choice on what they use, they are going to opt for the faster/ better integrated app and PWAs can't compete. For a purchasing manager, the difference between a cross platform PWA and delivering 2 native mobile apps plus a web app can easily be tens or even hundreds of thousands of dollars in development costs.

(FWIW, I work on a large SAAS web app/ PWA which obviously colors my perceptions)

The advantage of a PWA might be that it exists compared to the native equivalent that doesn't.

I'm interested in the many quirky apps and niche experiments made by people who won't or can't make cross platform native apps.

It's this stuff I care about. I don't care about whether you faang of choice chooses to go native or not.

Mobile apps are designed to be used on mobiles. But what about web apps? You need many versions of the app, from smart-watches to desktop monitors and smart TV's. And then they will be crippled by the web chrome/shell, so we are stuck with Electron/NW.js apps if you want it to blend in to the OS. What's nice with web apps though is that they are sand-boxed, compared to Electron/NW.js apps that get full system access. What needs to be done is to give better design/layout possibilities for web apps once they are installed on the "shelf/desktop", for example transparency, able to design the top bar, able to have a window menu. Or maybe the future is UI toolkits like Flutter and React Native ?

Why on earth would I use a native app for twitter? It's all static content browsing, this has been solved decades ago with the web.

The occasional tweet I may send is just an input field and a file upload maybe.

This is a perfect example of a HN reader being out of touch with what the vast majority of users actually want. There are plenty of reasons people want a native twitter app: state restoration, integration with system services, push notifications, better user experience, better accessibility, fewer ways to track the user, better permission model, ...

You think native apps have fewer ways to track the user? Then why does every social site push users to their native app? Just so they can get less info? Seems unlikely to me.

What is state restoration? All I want is to go back to where I was, a normal website does that ( e.g. HN). Integration with what? I literally just wanna browse twitter, like, retweet, and occasionally compose one. Push notifications, they work on every system except iOS. Better UX is using URLs that I can open and share. Better accessibility is HTML that blind users can use. Native apps track you much, much more than websites and can't be uBlocked. Permission model is as good as native, if not better because users blindly give native apps all permissions (see Instagram).

You haven't made a single point, on the contrary, web wins on ALL of them.

The one single point you can make but you didn't, is that native apps often (but not always) feel smoother or more responsive. Which shouldn't be an issue on browsing static content.

"Out of touch" is an unfair characterization. Not everyone wants what you think they want.

I specifically do not want push notifications from Twitter or almost any other app aside from calendars and alarms. Having Twitter notify me about every stupid online interaction was causing my life to be buried in constant distraction. Without a doubt, my life is better without it, and I don't think that's an unusual perspective.

Also, I would be curious about your reasoning that running an app gives fewer ways to track the user. I would tend to believe the opposite.

*Edit: 1 minor typo

Vast majority of users go back home and browse on their laptops because a big screen is better than a credit card

Vast majority of users will use whatever you throw at them, especially if they're friction free (no account needed, no credit card, no updates, no space occupied, immediately available, even on slow networks, etc. etc.)

> Vast majority of users go back home and browse on their laptops because a big screen is better than a credit card

I used to think this, because I am like this, but living with my wife made me realize that for a lot of people, the phone is the primary internet device. Probably one factor is that she is a nurse, so she works on her feet. Also, she generally does not have a deep relationship with her machines, computers to her are strictly tools, so laptop is basically for word processing and storing photos when the phone gets full.

Another way to look at it is that it's not that browsing the internet is better for her on the phone, it's that sitting down with a laptop is a disruption in her routine that needs to be justified.

Sure, in theory Twitter’s website could be very simple and straightforward, built on tried and true web technologies. In practice, they wrote an entirely bespoke web app that is every bit as complex as a native app but shittily executed and with a terrible UX.

It is decidedly not "static content browsing." It's aggressively loading and unloading content as you scroll. This in turn breaks basic interactions like Find.

Frankly Twitter is borderline unusable except for "see what's new," which is by design. A native app designed to empower users is a threat, which is why Twitter decided to kill them.

Seeing that most revenue on the App Store comes from games, I fail to see how Apple would lose money by suPlotting any of these Apis.

We almost have a duopoly in browsers as well - you have Firefox, and everything else with market share are forks of WebKit.

My last employer (a business to business company) exclusively went down the web app route, with some minimal PWA features, because their clients genuinely preferred not having to go through the app store to install it on their (often personal) phones. Whether they bookmarked the website or "installed" it to their home screen or only used it from their laptop / desktop was entirely up to them, and they never had to deal with the app upgrade hassle.

Tastes vary, I suppose.

> Name three PWA apps please

Fastmail, Facebook, Twitter.

None of them work on iOS due to lacking web push notifications. All of them can work on Android as PWAs and as PWAs they are more secure and privacy friendly (not only due to less permissions granted, but also because you can protect yourself with uBlock Origin et all).

Keep in mind that your personal experience is an anecdote.

>Fastmail, Facebook, Twitter.

I don't Android, so I really don't know - but are those PWAs the only or primary options for most users on the Android platform?

If not, they're really just "native apps which are also available as PWAs", and without data on relative adoption rates it's not really very useful information.

So you're invoking popularity, but I don't understand what that has to do with it.

I use web apps all the time, even on mobile. And I'm sure I'm not alone.

Speaking of which Fastmail's Android and iOS apps are just the web app packaged in a native shell ;-) and they are not alone. For them clearly it was cost efective to work on that web app.

As for why they bothered to package their web app in a native shell? Maybe that's were the problem is.

But a billion+ users do Android on a 99$ phone

Not sure which region you're from, so I've included the filter for you[1]. These are from famous companies, every major apps uses PWA in some part of their app.

[1]https://developers.google.com/web/showcase/region

Are you talking specifically about add-to-home-screen / offline capabilities? Because PWA is a very broad term, and most descriptions I've seen consider those features necessary to be a PWA.

Ignoring those two, you get damn near every major web app. All of Google's applications, Facebook, Twitter, etc. etc.

This is a good question.

You can enable add-to-home-screen for websites with a single meta tag,

   <meta name="mobile-web-app-capable" content="yes">

e.g. Here's one of my website with that tag[1], Ironically this feature was introduced by Apple and is considered part of PWA specs.

But for the sake of this discussion, let's consider PWAs to be one which uses app manifest[2] and uses some high level device features.

[1]https://needgap.com

[2]https://web.dev/what-are-pwas/

Woops! I left off the word "don't" in regards to those features being necessary to be considered PWAs!

Twitter

Firefox Send

Spotify

I love that firefox send is on this list. Thank you.

Nah people can just program in Java again.

> However Google is pushing those APIs because they know tracking people without cookies in future is a big challenge for them and they need new ways of tracking people.

Why would it be? They have the search data, they know what you clicked on, they have GA on 60-80% of sites, they have plenty of information, tracking and profiling users isn't the issue. Tracking and profiling users legally is what's hard.

You have to build these APIs before people use them, and a lot of what Google has been building into Chrome is stuff native apps can do, so the use-case is clearly there.

IMO native apps are capable of far more invasive privacy violations than the web is. But for some reason they're given a very free pass by comparison.

> Native apps are not handling my bank account passwords.

You're conflating browsers (Chrome, Firefox, etc) with user applications. User applications are still not handling your bank passwords.

> They're also not collecting data about my consumer behavior with the goal of displaying more ads.

lol? Absolutely wrong here.

> They're also not collecting data about my consumer behavior with the goal of displaying more ads

This is my original point. They 100% absolutely are. Look at some of the ad and tracking frameworks for native apps. Somehow no one cares.

It's even easier to block a web app - just don't visit its web address.

A native app sits on your device, executing all kinds of code, sometimes without your knowledge. With PWAs, the code is more or less open source - all the JS is there for you to inspect - even after obfuscation, you can see the network requests being made in the dev tools of any browser.

I appreciate that and maybe didn't make my point as best as I could.

My point was essentially that you can run a native app without internet access most of the time (and can easily block the app making calls out by switching the internet off or blocking the calls its making) but a web app you have absolutely no control over, you just have to not use it.

That's not true with PWAs. You can have PWAs that operate offline. The problem is that not enough web developers know how to build good offline-only PWAs. But trust me, they're coming!

That's not true at all! Free native apps abound. Web apps tied to subscriptions are also plentiful.

Open source is neither here nor there: both web sites and native apps can be open source. In fact, the web is unique in allowing you to actually inspect the source that is running on your machine, you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.

> In fact, the web is unique in allowing you to actually inspect the source that is running on your machine

To be fair, this is changing with WASM. On the other hand, there are tons of obfuscation opportunities with native executables that don't exist for WASM.

What about Facebook? A native app, free, tied to a business and utterly motivated to violate your privacy.

> False: you can definitely verify that a binary matches the source code in deterministic builds

If I want to check an app I have installed from the iOS App Store matches the code provided in an open repo, how would I go about doing that?

>Truthness: many webs are obfuscated on purpose like native apps are.

True. But their underlying behaviour, i.e., what data they send and where they send it, is viewable and blockable by browser extensions.

Never trust what they say, Google is known to offer so called "free" services for your good, ultimately people realize they are paying with their private data.

Interesting thought. I wonder if there's a genuine threat of google "AMP-ifying" PWAs. And by that, I essentially mean Google using their properties to exert control over PWAs, just as they have with web articles and other content. Given Google's virtual stronghold over the web, I'd assume so.

I don't really understand: the PWA APIs are W3C APIs, they're not created by one company. Mozilla fully supports them.

Just because they're standards doesn't mean they aren't standards written and promoted chiefly by Google. Mozilla also has pushed back on some of them, despite the fact that... Mozilla supporting them isn't a good argument since most of their revenue also comes from, you guessed it: Google.

I agree app stores need to face antitrust scrutiny... but websites having crazy types of permissions isn't the answer.

Web apps by default talk to an outside server, native apps by default do not. Native apps will always be the more private by default option.

Actually, most app sandboxes have to request network access as a permission. Unfortunately most mobile OSes don't let you deny it at present. However, you have a lot of options for using network devices or inspection software to intervene and block requests on local machines. Meanwhile, once data is on a remote server, you have no control of it.

Furthermore, native apps can be retained and often installed after they're no longer supported by their developer. Web apps vanish into the night, and leave you with nothing.

> However, you have a lot of options for using network devices or inspection software to intervene and block requests on local machines.

Do you? What would the average user install on their iPhone to allow such intervention? What’s the native equivalent of incognito mode?

I won’t argue with you in the retention point but that’s not really related to the privacy discussion at hand.

I’ve heard so many people complain on HN about Safari’s lack of support for APIs. Before now, we didn’t have a public justification why Apple refused to implement them. Now we know.

The price of a Safari user in the ad market is going down, and it’s exactly what should be happening. I’m very happy with Apple.

https://9to5mac.com/2019/12/09/apple-safari-privacy-feature-...

Except "privacy" as a justification is BS.

You can implement these APIs while at the same time requiring explicit permission from the user before a web application can use them. This preserves privacy while also giving users the option to have much more powerful web applications.

Apple doesn't want to implement these APIs because currently if you want access to these things on iOS, you need to go through their walled garden App Store, where they get a big chunk of any revenue you might make on such a service and can nerf competitors and all the other anti-competitive stuff they're doing.

> requiring explicit permission

Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.

They only need to get the foot in the door and then you'll find that plenty of stuff ends up conditioned on you giving them access. Every one of these APIs is a Trojan horse. Past experience just proves that they will be hijacked for purposes that don't do the user any favors.

Look no further than JS which is there to enrich the web to benefit users but 99% of it is garbage slid under the door to benefit site owners. That's because plenty of things that should work just fine without it are now tied into it, disable JS and the site experience breaks.

> Except on the long term that would have no effect in empowering users. We all know that when faced with a deluge of permission requests, or pressured by the fact that enough people have already accepted and it's the entry price to collaborate, people will just hit accept and be done with it.

How is that any different from apps on the App Store?

The App Store can enforce things like "users can deny permissions and the app still works for anything else" or you get booted out of 50% of the US market. A web site can say "oh, you denied access to location? Well, I won't let you continue at all until you do". We saw this on Android - on install apps would require a raft of permissions, but if all your friends were on Facebook you'd be compelled to accept them all anyway.

A way this could be solved would be to provide websites with an interface that appears to be the system with no devices attached (or dummy devices in the case of devices that are always present, such as a power adapter) and only connect the real device when the user give permission. If the website thinks it has permission, but finds no device, it must have to fail gracefully or at the very least ask the user to connect a device (like a midi keyboard).

The OS could to provide a set of "fake" devices to any app or website in a manner that is plausible and consistent. E.g. Not identify as an iPhone with 320x240 resolution, or a battery counter that never goes down, or that always goes down as the exact same rate, and so on.

My opinion is informed by my experience with JS.

I love the web that actual dynamic logic on the frontend has allowed. I want more of that, not less.

The alternative to web apps that can do these things is native apps that can do these things. If you don't think native apps are tracking your behavior, you are sorely mistaken.

> I love the web that actual dynamic logic on the frontend has allowed.

I think you missed my point, I also truly love that 1% of useful stuff that JS brings and wouldn't want to lose the functionality. But I absolutely hate the other 99% which I have no control over or I have to jump through uMatrix hoops to control.

Let's put it another way. You probably love that electricians and plumbers exist to fix your stuff. But if once you let them in they could invisibly camp in any room of your house without you even knowing where they are and what they're doing, would you still open the door for them?

These APIs can either give you a relatively broad "Allow on this site" option, or they can flood you with granular choices. The first opens the door for them camping in bed with you. The second is like someone triggering your alarm every 5 seconds until you disable it. Accept all. Then they can camp in bed with you.

Doesn't your experience tell you the same?

> If you don't think native apps are tracking your behavior, you are sorely mistaken

You see, this is exactly what I meant. "Those guys are screwing you over so it's OK if these ones do too". This is how the "screw the user over" arms race happens where everybody tries to outdo the others with even more invasive techniques, and users take it because each is just a slight escalation from before. When native apps were adding these "features" someone loved them for one reason or another. Frog in hot water.

P.S. Example of how the innocent battery API access can be sold as "to save battery" and then repurposed to screw you over:

https://metro.co.uk/2019/09/27/uber-charge-battery-lower-107...

Unequal progress of privacy improvements on the web and app fronts does not make it okay to walk back progress on the web front just to provide API parity.

If the only way to have privacy is to nuke functionality, then I’d rather have the functionality.

Luckily you can have both, despite Apple wanting to pretend otherwise.

> Luckily you can have both

I have a bridge to sell you...

Please just explain your point, instead of being snarky.

I think there are ways to get (a bit of) both. It's not simple though.

The point (which I vehemently disagree with) is that prompting for permission is insufficient because illiterate users will just click accept on the dialogs.

So apparently we now have to restrict all interesting functionality in the name of keeping the lowest common denominator from shooting their metaphorical feet. If there's a more charitable way to read their stance, I'd love to hear it.

> The point (which I vehemently disagree with) is that prompting for permission is insufficient because illiterate users will just click accept on the dialogs.

I had 2 points actually, which I thought I made very legibly. I didn't think they they need a fourth reading but here we are... They are both solidly confirmed by present day reality. 1) is what you mentioned already. As seen with cookie prompts, app permissions, actual scientific studies, etc. if you pester people with alerts and popups they are desensitized and start ignoring and accepting them. 2) is that once you give a website permission you lost control. They lack even the modicum of oversight apps receive.

> So apparently we now have to restrict all interesting functionality

All? Hyperbole much? Or did you just decide that these 16 APIs are the crux of "interesting functionality" and freedom? It doesn't matter how much you allow there's always going to be someone to shout "they restricting eeeeverything around here". This is what security and privacy measures do, restrict some things because the benefit doesn't outweigh the cost/risk. All those features are sold as "essential" when in fact most of them at best address some minor nuisance. Then they're promptly hijacked for nefarious purposes because there's always going to be some wannabe coder who insists that his website needs to know my battery level for some (undoubtedly good) reason.

Care to ponder how we got here in the first place? With every piece of tech around trying to steal data from you one way or another, usually in a dishonest way? There's a reason Google is championing this and it's not that they want to give you "interesting features".

It's always a compromise and for the past decade+ we've been compromising a lot more on the privacy side. If you truly believe you can have both privacy and aaaaalll interesting functionality in the real world you're either naive or sitting on a gold mine.

>It doesn't matter how much you allow there's always going to be someone to shout "they restricting eeeeverything around here".

A good example here would be the MIDI interface getting blocked because it allows binary uploads via certain control message, as well as device enumeration.

If privacy is the main issue with this API, then the allowed control messages that the API would accept could be limited strictly to note on, note off, key velocity, etc.. things that have no realistic possibility of data leakage or compromise.

But instead, no, we lose the whole thing, even though a more nuanced approach (and in this case, one that's easy to implement - MIDI being rather straightforward) would satisfy any privacy concerns.

So with that in mind, the fact that a privacy-respecting alternative exists, no. I don't believe for a hot minute that that this is all about privacy - that is mere marketing fluff. I instead believe it is Apple is using privacy as a pretext for ensuring that PWAs remain as gimped second-class citizens on the platform in furtherance of their lock-in.

> have no possibility of data leakage

Oh if I had a penny for every time someone said with such certainty that "this is safe" only to be proven wrong sooner rather than later I'd have a second yacht :).

> I don't believe for a hot minute that that this is all about privacy

Of course it's not. It's about appealing to the customer base Google and the likes are losing by using an actually useful feature as a bridge to them. For the moment our interests align, whether by side effect or not. That's it.

But while you get your "first class interesting features" in apps, and second class shaky experience in the browser, what do I get for privacy? They're both already turning (turned?) to malignancy with too much of the code dedicated to actual data extraction. You have your apps, let others have their browser at least. That was the escape when you wanted to touch Facebook and Google Maps and no 10ft pole was around. If you think I'm unreasonable for wanting a last bastion of privacy (saying this is a bit of a stretch), just think that you're the one who insists everything should be how you want it by turning even the browser into the hot mess that apps already are. And this in exchange for some "interesting features" that you already have if you need them just not in every single piece of software.

You're ostensibly a coder so I don't need to point you to all the instances of trust being breached via conscious decisions. But surely this time they won't abuse that power. Neither will the host of obscure and completely unvetted websites one may access.

I don't think there's more to be said. It never ceases too amaze me how cheaply people are willing to sell their privacy for and how much they're willing to fight to make sure this is everybody else's only option.

How many browser exploits are you aware of that target the user's keyboard input directly? Because that's the level of complexity we're talking about here with MIDI. You only need to pass through what key was hit, for how long, and how hard, to have reasonable functionality.

Those EU "accepts cookies" boxes have done an amazing job at making people ignore every popup on the internet.

By this logic, permission prompts shouldn't exist at all. I think you're gonna have to provide proof for your "we all know" assertion, because I do not know that users will individually grant dozens of permissions on each site they visit.

I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer. A website has no business doing any of that. There is no justification for these API to exist.

I don't want _most_ websites doing this. There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

Maybe it shouldn't "asking for permission" but "giving your permission" explicitly. If you don't need such an API, you would never be bothered by it if the model is opt-in without notification/popups.

I understand the problem you have with websites asking for permissions, especially push notifications permissions, as they keep showing up. And I do definitely agree that having a website that does not need any of these permissions ask for it would be even more annoying but there are definitely cases where I'm glad a website can help me out (and I don't have to download a heavy client that might or might not have tracking and analytics in it)

>There are some websites (especially PWA) where they are definitely useful and can replace a heavy client.

How can this be so when the web browser itself is a heavy client?

Unless you only use one such website ever, then it's a win for the browser to be the heavy client instead of having separate ones for each.

You could argue that, however, I don't think it change the fact that you already have it installed. So, in my honest opinion, it is indeed replacing a second heavy client that you might have installed if you browser did not have this capability.

Why would you ever want a PWA when a native version exists?

And "heavy client" is a fallacy. Operating systems come with runtimes too. Very complex native app can be very small in size if it uses the native controls and APIs. They can be KB in size. Any asset is going to be bigger than the binary itself.

The web-as-native apps are the ones that are huge, because they embed a behemoth (a browser) which is akin to an entire operating system.

PWAs run from the browser sandbox which is generally much stricter than restrictions for native apps. Permission systems for native applications seems to be starting to follow browsers (flatpak, snap, .appx, etc.), but don't offer nearly the ability to restrict what a native app can do like the browser does.

In theory native apps are "trusted", but I think for the vast majority of users the trust between a companies website and app are equivalent, vetted the same, and probably do an equivalent amount of tracking if not more by the native app (facebook SDKs are pretty common in native mobile apps).

I already have a browser, and the PWA uses that.

> I don't want random web sites I open (and their ads) to ask permission to scan bluetooth in my area and use usb devices connected to my computer.

Why not? It makes complete sense for something like a website that backs up the photos stored on your camera. What's even the counter argument, that if people want to back up their data they should have to pay Apple?

If you've granted a website access to a restricted API, the browser can just paint a flashing red border around the website or whatever, similar to how people configure their terminals when they're SSH'd into prod.

I don't want random sites to ask to use anything on my computer. It's like a popup ad - it's annoying and blocks the site. Sure, there are legitimate use cases, but if it's anything like push notifications it will be heavily abused and far too many sites will ask for permissions.

Because every other site will start asking you to scan Bluetooth when some ad network starts using it to fingerprint you

I’m tired of websites asking if I want to enable push notifications from them. The answer is, and will always be, GTFO.

In most browsers, you can go into settings and default it to block without asking.

most sites use a html modal to ask for the permission, and if you answer yes they make the request to the browser api which shows his own modal.

I disagree. I want that. Therefore a website does have business asking for those things.

You (or a small minority of users) actively wanting it is not sufficient justification for creating APIs that will, with near-certainty, enable additional widespread surveillance and data gathering of the public by entities whose only interest is in profiting from that data, not better serving the public.

You're wrong. Therefore the developers' effort should not be wasted, and certainly not while exposing their users to privacy risks, exploits, and such other dangers as will inevitably arise when placing the capabilities to perform sensitive operations in software which also deals with untrusted input from the Internet.

This is definitely going to be downvoted.

Isn't App store apps (Not reserved to Apple's one, this also works for Google, Microsoft and many others) untrusted code too? It runs with even more privileges than your browser's code and have access to more fingerprinting information if that's what it is going to do.

As far as I see it, a PWA with these permissions has less privacy risks than a native application I can find on a store. I'd really like to understand how installing an app is not an issue but having the access from the browser is. Is it simply the permission framework that is broken and you don't trust it to not leak information when the API is disabled?