Should I use native apps instead of PWAs?

Privacy and Security Get Advice
33

I have a question. I agree with your points that when you are installing a an open source app from Google Play or you downloaded the APK directly from the developer, you cannot be sure that the code you are running doesn’t contain any funny stuff that are not part of the source code that is publicly available.

However, when you are installing an app from the F-Droid repository then the app has been built by F-Droid from source instead of the developer and has been signed with the F-Droid private key. So, doesn’t that mean that so long you are getting your apps from the official F-Droid repository you can always be sure that the source code for the exact app that is currently installed on your phone is available?

3 Likes
34

You’re adding another party to trust. The developers of the app, people from F-Droid, probably developers of something like Neo Store because F-Droid’s client is out of date as f*ck. Not only that, but all of your updates will be very late.

1 Like
35

You are missing the point of my post. F-Droid forces the developer to submit the source code and then they are the ones who compile and sign it. This means that you can always be sure that the source code associated with the app currently installed on your phone is the exact same source code that was used to build it.

When you get the APK from Google Play or directly from the developer the one who builds the APK is the developer themselves. This means there is no way to verify that the source code published on GitHub is the same source code that the app running on your phone was built from.

F-Droid has other issues like for example slower updates which is partly due to this process. However that’s an entirely different discussion. My post was specifically about the how F-Droid makes sure that the app you are running on your phone came from the source code you think it did.

3 Likes
36

If you fully trust F-Droid and if the source code is always audited (which isn’t the case) then that would be correct.

1 Like
37

Even if the code has not been audited there is always an archive of source code versions associated with each APK version which can be audited in the future. Due to this companies who distribute apps through the official F-Droid repository would think twice before putting any funny stuff in there, which could irreparable damage their reputation if discovered in the future.

My initial post was specifically referring to this part of @johnozbay’s reply.

Effectively if you’re running Proton on your android, you have no way to verify it’s not sending your keys to their servers, because the code isn’t open yet. And by the time they update the github repo, it can have all the necessary corrections / changes / amendments to cover up if they did make any changes. (and I mean, considering it hasn’t been updated since Apr 28, which is 2 months ago, that would give them ample time to make alterations to hide malicious lines of code before pushing it to github too)

And by the time the code is live on github, you’re effectively taking their word that they didn’t do anything malicious with the previous version / target you etc.

And to my understanding if your app comes from the official F-Droid repository the above is no longer the case.

2 Likes
38

Hey @reformed_sandpaper :wave:t2:

@anon89964105 summed up my thoughts quite well. It essentially means you’re adding another party to trust, that which is F-Droid. While yes, you can see the code of the app linked from some other place, you’re still trusting F-droid to verify that the code you’re running is indeed the code that you read some place else. Because you have no way of de-compiling and verifying the code that’s running on your device at any given moment in realtime. (unlike PWAs, where you can instantly verify, any second you wish) Perhaps F does a great job. I don’t know, I didn’t personally audit their code. In which case, more power to them. I think it’s an excellent initiative. :sweat_smile:

But I do know that in the grander scheme of things, f-droid caters to only 1% of all the apps in the play store… , and that’s nowhere nearly statistically high enough to conclude there will be enough eye balls auditing authenticity of stuff on F-Droid.

Also Android has over 3b users, and while I can’t find the statistics for the number of F-droid users there are out there, we can draw a rough estimate based on the search trends, which seems like less than 1% also.

image
image1920×1138 58.4 KB

( I would love for them to publish these kinds of usage stats and enlighten us all actually, I would love to be proven wrong on this one )

So for more than 99% of the Android users out there, what we’re talking about is statistically insignificant and inapplicable. This isn’t to invalidate f-droid itself, but to say: statistically, it doesn’t and likely won’t have enough eyeballs auditing it.

I can tell you first hand, because I (along with team Cryptee) regularly try to break things and criticise and audit big tech to hold them accountable. Here’s one from last year where I put the spotlight on Apple quite publicly on Motherboard / VICE. We spare time to do things like this, because the impact affects billion+ users. We wouldn’t spare the time to do the same for F-Droid, because for the amount of time we would have to spend to audit and break things, the impact would be so so statistically insignificant in comparison (to google / apple etc). And if other experts prioritise their time the way we do, I can statistically say that you’re better off and safer using Play Store vs F-Droid. This doesn’t mean one is ‘factually’ safer or not, it just means F ‘statistically’ won’t be safer.

— to reiterate, I’m not saying f-droid isn’t safe. But I’m saying you cannot mathematically prove it is, (as it necessarily adds an additional party to trust) and that statistically there are nowhere nearly enough eyeballs on it to speculate that some day someone may audit and maybe catch some inconsistency. If we’re speculating / extrapolating our trust in F-droid based on “someone can maybe audit in the future”, I’m merely suggesting we do so with numbers in hand to see the statistical likelihood of that happening.

Hoping these make sense! Thanks for the constructive convo folks :v:t2:

3 Likes
39

My point is that in Chrome, a shortcut which opens as a window and a PWA appear to be identical. The process to install them is different but the outcome is the same.

There are countless third-party archives which store historical versions of apps.

If your examples of native apps which are susceptible to the issue I’m bringing up are all in fact web apps, then this doesn’t really change any of the points I’ve made here regarding the security of web apps.

This isn’t true though, native apps with reproducible builds can be (relatively) trivially verified that they match the original source code. On the other hand, Javascript code in PWAs could easily be compiled in such a way that makes inspection near-impossible for the average person, regardless of whether a developer console in a browser is available. It’s like I said, this advantage applies to either one. You’re moving this away from PWAs vs. Native Apps and towards Open-Source vs. Proprietary, which is a different discussion altogether.

1 Like
40

Huh, this actually proves that Chrome displays the install button even if a site doesn’t meet the classical “Progressive Web App” with service workers criteria. The criteria at What does it take to be installable?  |  Articles  |  web.dev states that only a web app manifest is required, not a service worker. The requirements listed at MDN must be outdated.

You can check this on Proton Mail by going to the developer console and checking Application → Service Workers, where none are listed.

This muddies the waters a bit if Chrome has more similar behavior to Safari than I initially thought. So the only way to tell on any browser/OS is to check an app’s offline functionality.

3 Likes
41

At least on Vanadium and Brave, PWA opens as an app without an address bar at the top, whereas a normal shortcut opens the browser and has an address bar at the top.

42

You can follow these instructions on Brave desktop to create a shortcut which opens “as an app” for any website:

2 Likes
43

Well, that’s not the case on Android, at least.

44

On Android with Brave, some PWAs like Uber Eats or Mastodon will show as regular apps, but others like YouTube Music will show the address bar. That’s my experience currently. Like has been discussed above, web apps and PWAs can vary in their PWA-specific features on desktop and mobile.

Also, thanks for joining the discussion, @johnozbay! Great to have your insight!

45

Because YouTube Music isn’t a PWA It’s a shortcut. It never says install app, it says add to Home screen.

46

Fair point. The lack of consistency extends to “add to home screen” as well. Some, like YouTube Music, will still open in their own window while others, like Amazon, will open as a new tab within the browser on mobile. It’s really hit or miss how many features a web app may or may not have, lol.

47

Just wanted to share Standard Notes confirmed their web app is an actual PWA

1 Like
48

Source? Where are these? And how can people go back to audit them?

Sadly very few apps seem to offer this. I know Signal does, as does Briar off the top of my head - but this in the scheme of things seems incredibly rare when compared to the millions of apps available on the Google Play Store. Though this seems to a be similar situation with the total number of services meeting proper ‘spec’ for PWAs as Cryptee has done.

Though even with that said…

Even if you can somehow go back and audit prior code from any native application to audit things in the past, that’s going to add massive friction and a delay that doesn’t exist with web apps :person_shrugging: While I’m sure someone can attempt to hide something in a PWA as it’s not foolproof, I am struggling to see any downgrade in transparency PWAs have over native apps. Seems to only have advantages from a transparency POV. And this is even stronger for most of the apps the world uses - proprietary apps exclusively found on App Stores with zero transparency. Ex. Using Spotify on the web seems like a no-brainer compared to the native client.

If we compare the best of both worlds (reproducible builds vs properly managed PWAs) the ground seems to be closer, but realistically the way most apps are managed would likely greatly benefit from being in the web from a transparency, privacy, and even security POV.

Great summary of the situation!

Aside from everything mentioned I would just add that users ultimately have a lot more flexibility and control with web apps. They can use ad-blockers in their browsers, they can set up filter lists to block things they don’t like (Ex. I was able to block Twitter’s trending section because that’s just obnoxious) - and I get to have a universal experience across all operating systems. I like to always bring back the individual feature-set which is often ignored in technical discussions. The reality is in most situations, using sites or PWAs offers users more control and flexibility over their experience, even for non-privacy related uses. As another example, you can use a dark-theme extension to use Bumble in dark mode, which is not something they natively offer in any of their clients. (not saying I necessarily suggest these extensions, just using it as an example)

I personally see a much brighter future for web apps than native apps. From a transparency POV, a privacy POV, a security POV, and especially from a user control POV. Now I just need more services to make better ones :angry: Though I continue to find myself overwhelmingly impressed by the current offerings.

3 Likes
49

So for a low threat model person do you think it’s ok/safe to use E2EE web apps like Standard Notes and Bitwarden instead of the native apps?

I am thinking yes based in this whole huge thread.

50

Yes, but it has to be a PWA. Not just a shortcut to a website.

51

For a low threat model person as you just described yourself - I’d personally say yes. Regardless if it’s a PWA or a website. I assume your core concern is with E2EE, and if that’s the concern then that’s a fairly high-level threat unlikely to happen in the first place, let-alone to an average user.

That’s just my personal opinion on the matter based on all of the discussions above. Ultimately it’ll come down to your assessment of the information shared above if you feel these threats apply to you, no one here can make that final decision for you.

4 Likes
52

https://www.apkmirror.com/uploads/?appcategory=signal-private-messenger for one of countless examples.

This is a straw man argument. Most of these arguments are actually, when in fact we were discussing the security problems with executable code which gets downloaded from the internet on the fly, which nobody in this thread ever seemed to disagree with.

The point is still that versioned code downloaded from a verifiable source is more trustworthy than web apps. Most apps achieve this trust with something like an app store or package manager, where I can verify that I’m getting the same code as everyone else. Cryptee achieves this same effect by hosting their code on GitHub, which serves the same purpose by acting as an independent source of code which Cryptee can’t hijack to display a different version of the code to me compared to everyone else. In either case, trust is achieved by being open source, locally-run, transparently distributed (out of band) software; not because it’s a PWA.

Everything else I’ve already addressed, so I don’t think I need to rehash things if John isn’t interested in continuing this discussion.

3 Likes