[palata]

> This is pretty funny distinction to make

Is it? Wikipedia says: "A web application (or web app) is application software that is created with web technologies and runs via a web browser."

> It's hardly a surprise you find web apps inferior if you define them so.

Then I guess we agree :-).

> A browser adds cross-platform ease for devs and a sandbox for security at a slight performance cost.

Mobile apps also run in a sandbox. But a sandbox does not magically remove all security concerns.

My point about security was regarding end-to-end encryption. If you don't trust the server, then the model where you dynamically execute whatever the server sends you every time you use the app is fundamentally a problem. I assume it is the reason why you cannot run Signal in the browser even though they distribute an ElectronJS desktop app (I believe it's ElectronJS?).

> A store adds gatekeeping (for better or worse) and a 30% tax.

Sure, but that's not all of it. A store adds a third-party intermediary:

- If Signal wants you specifically to run a modified version of their client that will leak your key to the Signal owners, they have to get Google to serve you a different version of their app, and hope that you don't compare it with someone else (which you can trivially do with an app). In other words they have to collude, and if you really care you may well realise it.

- If Google wants you specifically to run a modified version of Signal that will leak your key to Google, they have to make the Signal Foundation sign their modified build, otherwise your phone will refuse to install the update. They also have to hope that you don't compare it with someone else. In other words they have to collude, and if you care you may well realise it.

- If ProtonMail wants you specifically to run a modified version of their web client that will leak your key to Proton, they can just serve a different version of the client this one time only, just for you. They don't have to collude with anyone else, AND there is absolutely no reasonable way for you to realise it.

It's not "UX choices", it's the difference between "reasonable end-to-end encryption" and "having to trust the server".

[johnecheck]

Installed PWAs still run in a browser, they just don't show you the address bar so it looks and feels like a native app. (UX)

To all your points about a 3rd party intermediary, fair! Such an intermediary can be valuable. But whether we go through an intermediary is orthogonal to whether our app is running in a browser. Native apps can be installed without intermediaries (if your OS isn't evil) and there's no reason you couldn't build an intermediary for web apps.

As for your ProtonMail example... you got pwned. They just handed you some new code to run and you ran it. You could have ran the old code instead. You could have gotten a message saying "would you like to update?". You could compare the hash of content you received with others, tipping you off if you're being targeted.

To that, I imagine you say "but there's no reasonable way to do that stuff!"

And you'd be right. None of that is practical. Why is that? Is it some inherent difference between native code and code running in a sandbox? I think not.

[palata]

I can't tell if you genuinely don't understand the difference between "installing a signed archive once and then running it multiple times" and "running code dynamically in a browser that is fundamentally made to be able to change next time you hit refresh".

Whatever you load in your browser is not signed, and it's not saved.

A PWA does not run in a browser, it is a browser. The question with it is whether you get the benefit of an app (you download it all at once and run it) or if it's just shipping a browser for wasting resources but then it still loads and execute the code dynamically everytime you open it (which again defeats the purpose of end-to-end encryption).

> And you'd be right. None of that is practical. Why is that?

Well it's a design decision. It's just not made for that. If it loads in the browser, it's fundamentally not made for end-to-end encryption. Now you can use webtech and build an archive that behaves like an app. I am not saying that "Javascript cannot do end-to-end encryption". I am saying that loading a webapp (that is, in the browser) defeats the purpose of end-to-end encryption.

> Is it some inherent difference between native code and code running in a sandbox? I think not.

Again, native code running on iOS and Android do run in a sandbox. You can always run code in a sandbox, it does not have to be webtech.

And it does not have to be "native code" to qualify as an app. You can use Javascript to develop an app. The difference is not in the tech itself, but in its distribution. A webapp is distributed dynamically in a browser, and as such it doesn't work with end-to-end encryption because a webapp assumes that you trust the server. That's fine in many situations (like talking to your bank), but not for end-to-end encryption, period.

[johnecheck]

We don't actually disagree, our definitions of 'web app' and 'browser' just differ. Personally, I find it absurd to say that PWAs (progressive WEB APPs) cease being web apps when installed, but whatevs.

The important point is that how OSs should (with user consent) grant installed PWAs access to system APIs like notifications. I'm just trying to condemn Apple's preferential treatment of native apps in this regard.

[palata]

Right. Yeah it seems like we agree. My point is that if you dynamically run code coming directly from a server, you have to trust the server, and that is fundamentally a problem for end-to-end encryption.

I totally agree that PWAs count as apps and are eligible for end-to-end encryption (as long as they don't dynamically run code coming directly from a server). I don't know exactly the story on iOS though, I just know that I like "native apps" better then PWAs, but that's a preference.

> I'm just trying to condemn Apple's preferential treatment of native apps

Are they actively working against PWAs, or are they refusing to spend resources supporting another technology? I could understand that they don't want to go out of their way to add new "features" they don't care about.

[johnecheck]

> Are they actively working against PWAs, or are they refusing to spend resources supporting another technology?

What difference does it make? I'm hardly surprised that they won't dedicate engineering resources to tech that threatens their bottom line. But it is a choice, and it's to the detriment of their users and I. For that, it deserves criticism.

[palata]

> What difference does it make?

I think it makes a difference.

To find other examples, I don't find it unacceptable that Samsung doesn't try to support GrapheneOS on their phones, even though it would benefit their users and I. Or that Google doesn't support misp for Android. Because I like RISC-V does not mean that Microsoft should be forced to support RISC-V. And because I like Erlang does not mean that Linux should accept Erlang contributions into the kernel.

I don't find it unacceptable that Apple doesn't work on supporting Asahi Linux. But I would find it unacceptable if they added some kind of hardware attestation that would prevent it from running.

It's the difference between "I will not help you do what you want" and "I will block you from doing what you want".