Hacker News Reader

Comment by nightpool | Hacker News Reader

Desktop applications are uniquely auditable by security professionals in a way that web sites inherently aren't. It's very, very hard to hide "send this unencrypted message to evilserver.com" in a desktop app in the same way it's possible to in a web app (because the web app could serve the evilserver.com code only to the targeted subject under surveillance and send only good code to the rest of the world). And mobile apps have the explicit review pipeline you mention. So web apps need some sort of "frozen, trustable, third-party reviewed" version to be able to match the security of desktop apps.

View on HN

Code delivery happens in desktop apps too, when you download the binary from evilsite.com, or when you receive an auto-update, they can give you a different binary than the security professionals reviewed. That's assuming the professionals even reviewed the binary, and not the source evilsite.com claimed it was built from.

It would also be difficult for said professionals to detect IP-(range)-specific backdoors (with as much obfuscation as you like; only send on Tuesdays; encrypted using a string constant elsewhere in the binary), in App Store delivered binaries that are harder to vary per downloader.

Some web apps - [Cryptee](https://crypt.ee/threat-model) is a notable example - address this with a "trust on first use" approach, that makes any change to the (web) code require approval, but that's in the same realm as a desktop app, where you've trusted it on the first download, and trust it to have actually followed through on that promise.

That's not really fair in the day and age of Electron apps. If the Electron app downloads JS code to run in its embedded browser / NodeJS runtime, then it's subject to similar attacks. Hypothetically, so too could any traditional desktop binary download and execute code. An audit will only reveal that such capability exists, not whether or not it is being abused.

If that's genuinely part of your threat model, then you simply must run on-premises code only, backed up by robust network controls that allowlist very specific parts of the Internet.

Indeed Microsoft Teams once contained a bug where specially-formed HTML messages could trigger arbitrary code execution when received.

Any platform where the security model is two steps:

1. Check if the message contains any code. If so, reject it. 2. Scan the message for code and eval() it.

is extremely susceptible to code execution bugs.

Correct. I do not think applications with such a vulnerability should ever be used or marketed as "end-to-end encrypted", since that implies a promise that a malicious or suborned vendor could not be compromise your communications—which, in the case of remotely loaded code, is misleading. I think this is table stakes for any e2ee communication app (e.g. Signal can do this easily since Apple and Google and many third-parties audit their code) but if it conflicts with your current app design, you should be realistic about whether a true e2ee-required threat model can be accommodated by your app.

There’s more tooling for non-professionals to keep a leash on desktop app network usage, too, like LuLu[0] and OpenSnitch[1]. There’s ways around these tools as there is with anything else, but it raises the bar a bit since the user is unlikely to let random programs connect to servers they have no good reason to connect to, once made aware that the attempts are being made.

It’s not as reasonable for the layman to do this on the web, since it’s par for the course for a single visit to a big commercial website to kick off connections to dozens of unintelligible domains, and to sometimes break if these connections aren’t allowed. OS-level tools like LuLu aren’t of much help here because significant limitations on the servers a browser can connect to essentially break the browser, which leaves you with extensions like NoScript and uMatrix which for the explained reasons aren’t as straightforward to operate.

[0]: https://objective-see.org/products/lulu.html [1]: https://github.com/evilsocket/opensnitch

You just described Manifest v3 Chrome extensions hosted on the Chrome Web Store. No remotely loaded code, frozen assets, third party review.

For what it's worth, the threat model for Chrome extensions is not the same as that of arbitrary websites. You can probably reasonably accomplish some things in extensions that are untenable on web pages.

Correct. I know that there's a lot of concerns about Mv3 and I don't want to downplay them, but from a security perspective the team absolutely made the right and necessary calls that are required to prevent the (currently widespread) abuse of browser extensions for tracking and ads injection, not to mention malware distribution.

I would trust an audited, Chrome-or-Firefox-store distributed browser extension to implement end-to-end encryption. I don't think that extends to UI elements injected into the page itself though—the UI elements where you're typing your messages have to be separate from the rest of the page to prevent malicious web apps from overwriting them and capturing your input before sending it on to the extension themselves.

> Desktop applications are uniquely auditable by security professionals in a way that web sites inherently aren't.

Except for the desktop applications that simply pop up a web view to load the web site from the internet.

(Looks at Discord, Slack, Zoom)

Not all Electron apps are this way, for example LM Studio stores its interface locally and therefore doesn't rely on loading it from a remote server at application start time. But a surprising number of them are.

There is "Signed Pages" by the developer of EteSync. It is a browser extension, that checks webapps based on signatures in the html file. The addon then warns the user if the signature is not correct or - if I remember correctly - the source changed. This allows you to be sure what webapp code was delivered. But it seems like it did not really get used outside of his own projects. https://github.com/tasn/webext-signed-pages

The page you linked even says "While this doesn't protect you from a malicious developer". The whole point of e2ee is that it needs to be able to protect you from a malicious developer. Native apps do this by having local, auditable code. Web apps don't.

That said, this project could be extended with something like a public certificate transparency log showing which versions of the code have been signed and making the code associated with each signed version available for third-party inspection, which would help plug this loophole. I haven't seen any proposals for how to do that with web standards yet, but I expect that some people have thought of a few of them. While it would be very different from the web we have today (no dynamic server-side templates, only APIs!), I think it would be a welcome innovation for web security

Reply on news.ycombinator.com