Wrap the web application with Electron

[ovalseven8]

Not sure about how many adjustments are needed for this, but definitely worth a try.

Advantages:

• Native look & feel of Threema and better integration (system tray, etc.)
• Security does not depend on TLS anymore (https://web.threema.ch)
• Session reconnection much easier
  • Many people delete browser data on a regular basis -> Reconnection is not possible
• Perhaps performance boost?

Edit: Electron has some major security problems.

[rugk]

Note that you can already use npm nativfier for a local desktop-client: #33

[dbrgn]

Someone already attempted something like this (with nativefier) and succeeded:

#33 (comment)

Security does not depend on TLS anymore

Why would that be the case? Electron is just a wrapper around webkit, as far as I know.

Main advantages in my opinion are the absence of browser plugins that interfere with WebRTC as well as no things like local storage clearing on close.

[ovalseven8]

Why would that be the case? Electron is just a wrapper around webkit, as far as I know.

Well, one can download the app the first time and check the signature and everything is ok. With https://web.threema.ch one has to check the certificate each time to prevent (possible) MitM attacks.

[rugk]

Why would that be the case?

Good question. But I think he means you could serve the files locally, so the JS /HTML files are all included in the Electron app.

[ovalseven8]

Good question. But I think he means you could serve the files locally, so the JS /HTML files are all included in the Electron app.

Exactly.

I've just tried Threema Web with nativefier and, yes, it works more or less! :)
In general, some adjustements would be needed for better look & feel and integration to the OS, but hey, it's a good sign that the App has already worked! :)

So perhaps Threema can release a native version someday. There are advantages!

[lgrahl]

Fork it, customise it, make a PR. It will get you there a lot faster than waiting for Threema to do it themselves. ;)

[ovalseven8]

Well, lacking JavaScript and Electron knowledge keeps me away from doing Threema's job here. 😉

[dbrgn]

With https://web.threema.ch one has to check the certificate each time to prevent (possible) MitM attacks.

We deployed HSTS and HPKP, so MitM attacks should be very improbable (hopefully impossible) if you've visited the site before.

Note that you can also use Threema Web from Rambox if your main goal is simply having a native app.

[ovalseven8]

Well, HSTS does not prevent MitM attacks, but it's of course a good thing to use. :)
HPKP, in contrast, is a very nice technology to prevent MitM attacks because it's only possible to MitM the first time you visit the website.

However, one should know:

• Not every browser supports HPKP (i.e. IE, Edge, Safari)
• In case you use i.e. Firefox: If you delete the website settings every time you close the browser all the saved pinned keys are deleted and so HPKP is useless

[rugk]

Not every browser supports HPKP (i.e. IE, Edge, Safari)

which are both not compatible with Threema Web at this time…

If you delete the website settings

Which is done by few people.

Anyway, it's not useful to discuss how/whether MITM is possible/realistic. Threema does a far good job to prevent it…
Anyway self-hosting or using a local version certainly has it's advantages. E.g. a threat I would say is a bigger risk is a compromise of the web.threema.ch servers. Or in genera, that a backdoor is served in the JS (taargeted attacks possible). That's what this protects against.

[lgrahl]

I also agree that it would be nice if Threema themselves distribute an Electron-based application.

[ovalseven8]

@dbrgn: Seems to be a reasonable choice too -> https://github.com/brave/muon

[EinsteinXXL]

Hi! I have made a desktop client with nativefier and added some features to it (tray, notifications, notification sounds). For all who are interessted, take a look here:

https://github.com/EinsteinXXL/Threema-Desktop-Client
https://threema-forum.de/thread-3028-post-30041.html (german site)

[kristian-b]

A desktop client would be very useful. Optionally published and updated via Windows Store and Apple OSX AppStore.

[ovalseven8]

Chrome will stop supporting HPKP and Threema Web security relies on it.

[dbrgn]

Chrome will stop supporting HPKP and Threema Web security relies on it.

Google suggests certificate transparency as an alternative to HPKP in their deprecation notice. The threema.ch-Domain already uses CAA headers on DNS level (see dig CAA threema.ch). Our certificate provider supports certificate transpareny since mid 2017. We will also introduce Expect-CT headers in the near future (although that's only supported by Chrome and Opera so far).

People that are worried about the chance of a MITM attack should self-host. It's always a tradeoff between security and convenience.

A wrapper for Threema Web is still on our radar, but Electron has its own share of security and performance problems. See signalapp/Signal-Desktop#1635 for example. Maybe we can also find a different solution, e.g. a simple embedded webserver for the self-hosted download.

[rugk]

An alternative way may be to make a smaller native wrapper application as a localhost server, which serves the files from localhost. There, an update-mechanism could also be included.

Another advantage would be that you can open it with any (supported) browser. It would also help against these "server-hosted/MITM" problems (so it would fix these security issues), but of course the disadvantage would be that it feels less "native" for the user as a browser widnow has to be open...

[ovalseven8]

I agree that Electron is not a perfect solution because of the mentioned reasons (especially overhead and security).

The perfect solution would be an additional native client using Qt5/Gtk3/etc., but I know it's not realistic at the moment, unfortunately.

Please be aware that the update process should be automatic/secure by default, i.e. using package manager for Linux and an updater for Windows with cryptographically signed releases.
Manually downloading and verifying new Threema Web releases does not sound like a good idea in general.

[kristian-b]

an updater for Windows with cryptographically signed releases.
A Windows Store app would be good. Store app updates are processed automatically.

[joelfischerr]

Well, lacking JavaScript and Electron knowledge keeps me away from doing Threema's job here. 😉

That hasn't stopped me and I have started on a very hacked together electron wrapper for Threema Web. It currently allows to either load web.threema.ch or to have Threema Web served from a local server included in the wrapper or to just serve the files locally without a server.
I'm currently a bit busy but I should be able to put it on github within the next few weeks.

[dbrgn]

@joelfischerr: Note that since Threema Web only consists of static files, you can entirely include those in the build, so that no external website is loaded.

[joelfischerr]

Oh right. That makes things easier. Should I include this repository as a submodule and then copy the threema-web.tar.gz into my application folder in electron or is there a better way to do this?

[dbrgn]

Probably you'll only want the tagged/signed releases: https://github.com/threema-ch/threema-web/releases I don't know Electron well enough though to know which approach is the best 🙂

[joelfischerr]

I think including it as a submodule and then building it before including it in the electron-wrapper is easier. And as I have basically started looking at electron last night, going with easier might be a good idea for now.

[joelfischerr]

Do I need to put my project under the GNU Affero General Public License if it includes Threema-Web as submodule?
I don't think including as submodule counts as redistribution, but if I were to add downloadable binaries to my repository which include Threema Web it would certainly count as redistribution.
Which would mean that it's not necessary to include a license unless I add downloadable binaries.

[rugk]

BTW that trust problem can also (partially) be solved by a browser extension, see #427.

[ovalseven8]

Mh, I no longer think it's a good idea to use Electron:
https://twitter.com/ortegaalfredo/status/995017143002509313
signalapp/Signal-Desktop#1635

[ovalseven8]

Here also a nice post by a person who extensively deals with Electron:
https://twitter.com/bcrypt/status/995350141589569536

[mimoo]

BTW I've been thinking about a way to do it for a personal app, and I was wondering why a lot of security-sensitive apps don't do this instead: a daemon (made with Go maybe, like that it's easy to do multi-platform) that runs a localhost webapp. When you run the daemon it can open the link in your browser with an auth token in a GET param. If the app is a single-page js app then it could store the auth token and refresh the page to remove the GET param. What's wrong with that approach?

[lgrahl]

I'm not sure what this approach is trying to resolve and why there is a need for an auth token. Maybe you can elaborate.

However, I don't think this issue here is mainly about security. This is more about having a separate application for the purpose of running the web client in a native manner with all its potential advantages.

[mimoo]

The idea is that you delegate a lot of security elements to the browser, allowing you to avoid complete RCE in some cases. The auth token is to avoid dns rebinding attacks. What are the advantages of having the web client look like a native app? The "Security does not depend on TLS anymore" and "Session reconnection much easier" points of this issue are taken care of by my approach.

[dbrgn]

I think there are multiple reasons why people are looking for a standalone application:

1. Security reasons: Delivery (preventing modification of the JS by an evil server or a MITM)
2. Security reasons: Sandboxing (independent from other tabs)
3. Convenience: Having a separate icon to double-click, and a separate window in your task manager

Any others?

• Issue 1 is partially solved by HSTS and HPKP, although HPKP is being deprecated in favor of certificate transparency checks
• Issue 1 is also solved by self-hosting the web content (although that could be made more convenient)
• Issue 2 can be worked around by using a separate browser (e.g. Opera) that is only used for running Threema Web
• Issue 3 is partially solved by using https://rambox.pro/

The best solution would probably be a fully native app that implements the webclient protocol (which we might document & publish soon), but that's a lot of work of course.

@mimoo you're aware that threema web is just static HTML+JS and that it just needs a plain HTTP server to run, right? (In theory double-clicking index.html would suffice, but the browser does not offer access to all APIs from file:// URIs)

[ovalseven8]

Well, in the start post I mentioned the following advantages. I changed my mind concerning Electron, but here perhaps a small overview:

Native look & feel of Threema and better integration (system tray, etc.)
I think it's just not possible if not using Electron. Personally, what I hear about Electron and security by people I trust, it's not a good idea to use that software for a security-critical software like Threema. In case we want to have native look & feel, we need a native client. But that's unrelated to Threema Web.

Security does not depend on TLS/server anymore (https://web.threema.ch)
Unsolved so far. Perhaps we can use the embedded webserver mentioned by @dbrgn, it depends on if it's doable/user-friendly.

Session reconnection much easier (many people delete browser data on a regular basis -> reconnection is not possible)
Unsolved so far.

Perhaps performance boost
I think this has to be solved in Threema Web itself, there is a lot space for optimizations in that area. And needed urgently! 😄

[lgrahl]

@mimoo I guess I need an example for protection against DNS rebinding to understand the attack scenario. I'm aware of RCE due to some issues with Electron but haven't looked into it.

[rugk]

Maybe the easiest way would be just a local webserver like https://www.mailpile.is/ e.g. does in a very userfriendly way. It can then access 127.0.0.1 and security stuff is covered.

[mimoo]

@dbrgn

Security reasons: Delivery (preventing modification of the JS by an evil server or a MITM)

My approach is a daemon that serves the webserver locally, so no evil server or MITM there

Security reasons: Sandboxing (independent from other tabs)

I'd argue that security/sandboxing is better on chrome than on Electron. I would agree with that point for a native QT app though. But you end up having to write different apps for different platforms.

Convenience: Having a separate icon to double-click, and a separate window in your task manager

I'd argue that it's more convenient to have a webapp that you can access from your browser (we live in our browser nowadays)

[mimoo]

@ovalseven8

Native look & feel of Threema and better integration

Yeah, I agree with that point. That's the main reason to have a native app imo, but the price to pay with Electron seems too high. The price to pay with QT is that you need to write different code for each platform, which seems high as well.

Security does not depend on TLS/server anymore

My approach solves that : o

Session reconnection much easier

Same, my approach solves that

[mimoo]

@lgrahl

I've never exploited one myself so I'm definitely not the best person to explain that. Here's a post about it. Bottom-line is that browsers are somehow broken when it comes to localhost so you need to protect yourself otherwise malicious pages on the web will be able to read the content served by your localhost app (and for what matters, any app running on your machine, but that's usually less of a threat).

By using an auth token, these tricks cannot access any relevant data from your localhost app without the knowledge of that auth token (which is only given by your running daemon)

[ovalseven8]

@mimoo: You mean that the data stored in the browser's local storage is then managed by the daemon?

The price to pay with QT is that you need to write different code for each platform, which seems high as well.

Qt is cross-platform, so it will run on all major operating systems.

[lgrahl]

@mimoo Thanks for the link. I don't think this is applicable to Threema Web since there is no session data that can be retrieved from a local server. Session data is stored using Web Storage which means it is stored inside of the browser/application and not on the server serving the files.

Regarding local serving: You can already do all of this today by cloning the project and running it with npm run serve. 😺

[lgrahl]

(@dbrgn FWIW it seems serve is broken atm but serve:live works)

[dbrgn]

@lgrahl yep regular serve is broken, but for debugging / development you use the live server anyways and for production you don't serve with npm.

[mimoo]

@lgrahl the attack allows you to see the page's response, so it could be private chats/texts

[ovalseven8]

The best solution would probably be a fully native app that implements the webclient protocol (which we might document & publish soon), but that's a lot of work of course.

Thumbs up for open-sourcing the web client protocol. 👍

[lgrahl]

@mimoo IIRC, DNS rebinding allows you to make a request to localhost from another page. That is a relevant attack for local applications that serve private data. However, Threema Web does not work that way. The server only exists to transfer a single page application that on itself reveals absolutely zero user data unless you...

a) actively scan the QR code displayed on the web app with your smartphone, or
b) actively connect to the app via restoring a previous session with a password.

Even if you could somehow access the session data, which is just the session key and a few settings, it is encrypted with a password chosen by the user. All other data exists temporary in RAM and is only accessible by the tab or window running the single page application. Hit F5 and everything is gone.

[Luckz]

The native client in the Qt sense would also have reduced system requirements / resource bloat as a major argument for it (in the assumption of it being far from Electron/Chromium), and reinventing the wheel against it.

[lgrahl]

I don't think this is a good idea any more. Adding the required necessities to make Threema Web a Progressive Web App might be an alternative.

[rugk]

Adding the required necessities to make Threema Web a Progressive Web App might be an alternative.

Hint: #407 😉

[lgrahl]

Closing in favour of #407