Wow I had no idea, thank you for your well-reasoned critique! I can tell you're very capable of evaluating the merits of complex socio-technological systems. Your wisdom is unparalleled; now I see we all should just keep using X and GitHub.
There are many reasons to prefer an app, most of which are ways OS makers have crippled web apps for reasons that TOTALLY HAVE NOTHING TO DO with the fact that they get a 30% cut if the user chooses the native app.
This is wrong. The most important reasons why I prefer mobile apps are the same as why I prefer desktop programs.
- I can download it once and then use it.
- I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing.
- End-to-end encryption doesn't make much sense in a webpage, because I fundamentally have to trust the server (which serves me the whole app I run every time). If you care about end-to-end encryption, you want an app.
- For open source apps, I can audit the code, possibly edit it, and use it. I cannot do that with a webpage.
- I exclusively use free apps, so 30% of zero is... zero.
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.
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.
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.
> 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.
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".
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.
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".
This is only true if you are using apps that require no communication with a server.
Otherwise it's constant forced updates, and basing security on the version number of the installed app is a moot point since you can't guarantee the server will send the same replies to 2 different users.
I can't parse the part about e2e not making sense for webpages.
> This is only true if you are using apps that require no communication with a server
End-to-end encryption is all about going through an untrusted server. You don't need end-to-end encryption otherwise.
> Otherwise it's constant forced updates
There are apps that allow you to verify that you are running the same signed binary as others. Think key transparency but for apps. It's trivial to do.
> basing security on the version number of the installed app
Obviously you don't base your security on the version number of the installed app?!
> since you can't guarantee the server will send the same replies to 2 different users
With a website, you cannot. When you open protonmail.com in your browser, you don't know if you are running the same code as I am when I do the same.
With a mobile app, you can. You get a signed binary, it's trivial to compare. Also even if you don't check that, if you get the Signal app through the Google Play Store, it means that the app is signed by Signal but distributed by Google. They have to collude in order to have you get a different binary.
> I can't parse the part about e2e not making sense for webpages.
It's what I'm saying above:
- If you audit the Signal sources, compile them and run them, then you don't have to trust the server.
- If you use the Signal app distributed by Google, you can trust that you got the same app as everybody else who downloaded it through the Play Store, unless Signal and Google collude.
- If you open protonmail.com in your browser, you have to blindly trust that the Proton server is sending you the code you expect. But if you have to blindly trust the server, then it's not exactly end-to-end encryption anymore, is it?
> - I can see when it gets updated (versus a website that gets updated every time I load it). For security reasons it's better, I can even verify my app with other people online and make sure we run the same thing.
in many cases this is no longer the case. Discord, for example, has introduced capabilities to update parts of the app without goung through the play store on android, same with youtube. Which they obviously use to enshittify things against your will.
I understand your point, but I am not sure how relevant it is to use bad practice as a criticism of the technology itself.
Like I can write a modern C++ program that will be orders of magnitudes slower than an interpreted Java program from the 90s. But that does not mean that C++ is slower than interpreted Java: just that I can't write software, right?
If I care about security, then I choose apps that I believe are built correctly. I do happen to believe that ProtonMail is built correctly, and Signal as well. But it remains that because of how the technology works, the end-to-end encryption happening in ProtonMail requires me to trust the server, which defeats the point of end-to-end encryption in the first place [1].
[1]: to be fair, it does not defeat the purpose of ProtonMail entirely. It helps me trust that ProtonMail doesn't massively store data of all the users. But it is weaker because Proton can easily target me personally, and Signal cannot.
AGAIN, we are way past SIMPLE SOLUTIONS like this. We have enough data and information to be able to see the potential for harm that we can mitigate through smart policy without falling back on this simple argument.
Personally, I really like that my feeds aren't getting that level of granular detail. I prefer the explicit control I have with 'Show more like this' and 'Show less like this'.
I generally think that. But letting dwell time/clicks/open-rates expand the recommender and then (bound to swipe) 'disinterested'/'show less like this' to cull has been pretty efficient. I used to feel dumped into simclusters and now I see a more specific subset of posts I prefer (while still casting what feels like a wide net).
I really liked when bsky introduced the 'show more/less' and then expanded it to custom feeds. But I'm afraid the recommender systems work better with more data. And I think the feed operator alone gets sent a limited set of interactions?
I'm not exactly sure how it would work in atproto but I could imagine an enriched 'graph-interactivity' where you can turn on and off which/how much signal/privacy you want.
Trust is subjective! Let's establish trust in each other rather than rely on one-size-fits-all solutions.
Personally, I trust my friends, family, and some public figures and institutions to varying degrees. I want to see social experiences that reflect that.
reply