[SebastianKra]

1. You can download & install PWAs for offline use too.

2. This isn't true for apps anymore. Server driven ui is a thing.

3. JS runs locally. You can inspect the network traffic more easily than you can with an app.

4. You can audit OSS websites too.

5. Your personal preferences have nothing to do with the fact that Apple makes tons of money from apps but not websites.

[palata]

1. If you do it like this, then I count it as a mobile app, not a webapp. A webapp loads in the browser. We're not debating programming language here, if you run Rust in your browser via WASM it's still loading in the browser.

2. Wut?

3. The network traffic of an end-to-end encrypted app is... encrypted traffic to the server you don't trust.

4. Not sure if it's bad faith or not, you conveniently drop the other ideas: can you fork a website and use it against the original service? And again, if you audit the sources and then load the website, you have no idea if you are running those sources or not. Or if you will next time you hit "refresh".

5. Granted, they make a ton of money for apps. My solution to that is to force them to allow third-party stores.

[the456gamer]

1. PWAs load in the browser too

2. many apps are also just webviews, and dynamically load updates from servers out of your control, whether you want it to or not.

3. I suspect they were referring to certificate pinning, but I'm unsure. I don't think the e2e encryption argument really holds up, as you have to trust the app vendor too.

4. Its always possible to do it, for personal use: at worst case, you will need to host an api proxy on a custom domain, so you can have different CORS headers. However, for open source PWAs, its possible customization would be officially supported (and/or hosting backend instances yourself), so you could use it as-is.

5. not hobbling PWAs would be nice

[palata]

> 1. PWAs load in the browser too

I keep getting that kind of answers, and it just tells me that people just don't get my one point about end-to-end encryption...

> I don't think the e2e encryption argument really holds up, as you have to trust the app vendor too.

... and that shows a misunderstanding of end-to-end encryption again.

It does not matter whether it is coded in Javascript or not. What matters is how it works. If it sends the data in plaintext, it's not proper end-to-end encryption. If it sends the data weakly encrypted in such a way that it is trivial to decrypt, it is not proper end-to-end encryption. If it fundamentally dynamically executes code coming from the server whenever it wants, then it defeats the point of end-to-end encryption.

That means that for end-to-end encryption to work well, you have a bunch of constraints.

- The Signal client app is a good example: it's open source and it is distributed in such a way that you can reasonably trust it (i.e. it's reasonable to believe that Signal and Google are not colluding to attack you personally, and if you believe they do you can reasonably compare that you run the same app as someone else). This all makes it very difficult for Signal and Google to attack it.

- Anything that dynamically loads Javascript from the server and runs it is a poor fit for end-to-end encryption. Whether it loads in the browser (like web.whatsapp.com) or does something dynamic that allows the server to modify the code you run this one time and without leaving a trace, it does not matter. The fact is that everything that you load in the browser works like this, so a simple rule is that everything that you load in the browser is a poor fit for end-to-end encryption. Then of course because it is an app does not mean it is a good app, but that was never my point.

[johnecheck]

> If you do it like this, then I count it as a mobile app, not a webapp.

This is pretty funny distinction to make. It's hardly a surprise you find web apps inferior if you define them so.

Whether through a store or browser, your computer is downloading code from the internet and executing it. A browser adds cross-platform ease for devs and a sandbox for security at a slight performance cost. A store adds gatekeeping (for better or worse) and a 30% tax. The other differences are UX choices from browser makers and OS designers, nothing more.

[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.