Comment by johnecheck | Hacker News Reader

Comment by johnecheck | Hacker News Reader

Parent Full thread

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com