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