I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
If your thought is just "disable automatic updates", there's no reason you couldn't do the same by declining new versions of a web app. Unless you built it yourself (as a web app or native app), you need to include the servers and DNS in your trust model.
To me, it seems entirely isomorphic. The only material difference I see is whether automatic updates are on by default (an OS/browser vendor issue, not anything inherent to the tech).
> Isn't this the exact same security posture as a native app with automatic updates turned on?
It's not, I don't think so. For instance, if you install Signal on your Android, the apk was signed by Signal, sent to Google and distributed by Google. Google cannot modify it, because Signal has to sign it. So in order to make you install a "malevolent" version of Signal, Google has to collude with Signal.
Of course you can download and install the apk from Signal's website, in which case Signal may give you personally a malevolent version. But you can easily compare that file to someone else's. On Android there are verifier apps that allow you to check that.
Finally if E2EE does matter a lot to you, you can compile Signal yourself from the sources, and even go as far as auditing those sources yourself.
You don't get to do any of that on the web. When you load ProtonMail in your browser, you don't have any practical way to verify that the code your browser is running is the same as everybody else who is running it around that time. You have to trust Proton that they give you code that prevents them from reading your emails. It is better than nothing or course, but it still means that you have to trust Proton.
This can be solved by a nobus backdoor.
> if you install Signal on your Android, the apk was signed by Signal, sent to Google and distributed by Google. Google cannot modify it, because Signal has to sign
I'd stress that for specifically Signal this seems to indeed still be true, but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them), and even customized by Google for your specific system.
Google requires it for all apps created after August 2021. *
---
> On Android there are verifier apps that allow you to check that.
If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
I only know APK redistributors such as apkmirror that might let you check the individual app version, but they don't have API access and only host some apps.
And again, now almost apps on Google Play are signed by Google and customized on the fly for your device, so you typically can't really confront them.
---
* Except that apparently, since a couple months ago Google allows you to use their HSMs?
Even this magnanimous concession though is “strictly for enterprise organizations with mandatory compliance, regulatory, or policy requirements to retain key custody in an external Google Cloud KMS instance” (https://developers.google.com/android-publisher/api-ref/rest...).
There's some chance that they can't access these keys; but the app needs to be compiled on their servers, so yeah, plenty of ways for them to meddle with it, and probably even to issue signing requests.
This seems to have been introduced in July, it's the first time I hear of it
> but almost apps on Google Play are now signed by Google (with keys either generated by them or provided to them),
Yes! Google's goddamn "bundles" seem to be enforced to everybody. I guess part of Google "not being evil" and all. Another reason why initiatives like EU's Digital Markets Act are needed, I guess.
And yet another reason to use GrapheneOS, of course.
> If you mean Accrescent, it only checks the app's signature, not the hash of the individual versions.
No, there is an app called "AppVerifier" actually. That's the one I meant.
> No, there is an app called "AppVerifier" actually. That's the one I mean
https://github.com/soupslurpr/AppVerifier , right? It only checks the signature (the certificate)
> And yet another reason to use GrapheneOS, of course.
Which always recommended to use the Play Store, though
> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?
Mostly. But the alternative shouldn't be a native app that updates itself, but rather a native app that is updated by a package manager. The big difference is traceability and auditability: With a trusted package manager (and even in good app stores) the company can only decide to push an update to everyone or to no-one. There is no way to push an update just to the pesky journalist or whistle blower. A covert attack is really hard to accomplish this way.
Exactly, to me there are two requirements:
* The cryptography must be sound. That's the obvious one, if it's not encrypted then it's not "end-to-end" encrypted.
* There must be a practical way for the user to "verify" (with some definition of verifying) the client they are running.
A web browser doesn't provide that at all. It does not mean that everything else provides it: there are many ways to provide a Desktop app that break E2EE, but that is a different discussion. My point is that fundamentally, the web browser does not provide that. It's not that the laws of physics prevent it, it's just that the web browser never chose to provide that.
> it's just that the web browser never chose to provide that.
Yes, this exactly. If we wanted ‘verifiable’ app distribution via browser, then we’d need browsers to implement some way to cross check the code downloaded vs a publicly published list somewhere - similar to certificate transparency or what WhatsApp is trying to do with an extension [1]. Without that, web apps are left working with a weaker threat model.
[1] https://engineering.fb.com/2022/03/10/security/code-verify
Yep! Just nitpicking here, but...
> or what WhatsApp is trying to do with an extension
I remember looking into it, and while it is interesting, I think what it allows to verify is that the intermediary (Cloudflare, I believe) didn't tamper with the code being served. Which in the end allows the user to verify that the code they run comes... from the server they trust.
And even that is not super practical, I find.
It would already be a huge improvement if browsers warned you when a web app has been modified, and gave you its hash
It would, but at this point, do you need a browser really? Like the big advantage of the web is that users load the latest version of whatever you serve, and they don't have to care about updates. In many cases that's desirable. But it fundamentally doesn't work for E2EE.
I am not trying to say "browsers should not exist, everything should be a desktop app". I guess I am more defending "some use-cases work better in a browser, others work better as desktop apps". And I have the strong feeling that over the last years (decades?) there has been a very strong push by web people to say "everything should run in the browser".
I wouldn't really say that the advantage of the web is that users load the latest version, there's plenty other real advantages of the web.
A browser allows you to run an app on any device (to a degree), so it definetely seems useful to me.
I'm actually not a fan of web apps, JavaScript and anything that came after XHTML, but it sure is/would be convenient to be able to run the same software on every device, without even having to recompile it.
The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
> I'm actually not a fan of web apps
Same here, I personally like to load "websites" in my browser, and to download "apps"... like as "desktop apps".
> but it sure is/would be convenient to be able to run the same software on every device
Oh yeah that's for sure. I can't help but to think that with a fraction of the resources that went into supporting webapps in browsers, it could have improved native systems a lot.
But even then, Kotlin MultiPlatform (KMP) is making me optimistic. With Compose MultiPlatform (CMP) I am hoping that it will make its way to desktop apps, too.
> without even having to recompile it.
If recompiling is the price to pay to have diversity, I'm fine with it. If 100% of the computers ran the exact same OS, it would simplify many things, but that one OS would certainly not be what I want to run.
> The single reason I dislike browser "apps" is what we've been discussing here, that you can't check what you're running (well, also that it's hard to control their internet access).
I dislike the fact that they force me to have a modern browser at all. I like having control over my OS, it's not for being forced to run everything in Google Chrome.
> I dislike the fact that they force me to have a modern browser at all
Yeah that's true
> But even then, Kotlin MultiPlatform (KMP) is making me optimistic. With Compose MultiPlatform (CMP) I am hoping that it will make its way to desktop apps, too
I personally hate Kotlin, but yeah it's one more option ;)
Automatic updates should be read as "automatic backdoors".
> Isn't this the exact same security posture as a native app with automatic updates turned on?
Inconvenient truth, but it is so to a degree. I am disturbed by the lack of attention to that by many security gurus.
One difference is that with web apps you're practically updating them every single time you launch them.
It depends on how the automatic updates are handled.
App updates can be cryptographically signed with a key that’s kept offline and only held by a few people. Your trust in the app can be equal to your trust in those people, multiplied by your trust in the technology that keeps those offline keys safe from compromise.
Your trust in a web app will be equal to your trust in the people running the server multiplied by your trust that the server isn’t compromised. Since the server is necessarily always online, that trust will be much lower.