7 ms·

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

by palata 3mo ago

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.

Akronymus 3mo ago
> - 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.
- palata 3mo ago
  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.
SebastianKra 3mo ago
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 3mo ago
  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.
  - johnecheck 3mo ago
    > 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 3mo ago
      > 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".
63stack 3mo ago
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.
- palata 3mo ago
  > 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?

by palata 3mo ago

Akronymus 3mo ago

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

palata 3mo ago
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.

SebastianKra 3mo ago

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 3mo ago
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.
- johnecheck 3mo ago
  > 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 3mo ago
    > 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".

63stack 3mo ago

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.

palata 3mo ago
> 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?