[Alpha] Greenline - A qml Whatsapp client for Ubuntu Touch

brenno.almeida

Hi everyone! I've been working on a qml Whatsapp client for Ubuntu Touch for a few weeks, now I think its good enough for its alpha release.

The app is not complete, there's still a ton of work to do, and probably many bugs. If you want to test it out, feel free to install in your device, and get back here if you find any bug so I can look at it. The Whatsapp protocol is awful to work with, I'm posting this early to gather feedback about edge cases.

Consider this app as Alpha, don't use it expecting to be 100% functional or complete, but use it to give feedback and help with the development.

Also the app runs unconfined to setup a background daemon, more on the architecture bellow.

Releases here: https://github.com/brennoflavio/greenline/releases

Once its stable, I'll publish to the store. Now more details about it.

Architecture

This app is composed of 3 parts:

Golang Daemon

This daemon managed by Systemd connects to Whatsapp servers and runs continuously in the background, gathering events and pre processing them. Also:

Manages your encryption keys
Serialize whatsapp events, stores in a queue
Expose a JSON RPC endpoint to read and send messages, among other operations
Syncs users avatars, media, and other data
Sends notifications

Python Backend

Event driven backend that pulls events from the daemon and acts on them, building a chat room and message database. It also sends events to the frontend, updating the message list in real time

QML

The frontend is entirely written in qml and communicates with python using pyotherside

In order to pull messages in the background, it needs to run unconfined.

arubislander

@brenno.almeida Do users of this app run the risk of Meta blocking or otherwise disabling their their accounts after a while, for using an unofficial WA cliënt? Or does this use the same.API as the browser is using?

pparent

@brenno.almeida

Very nice!

How do you interact with Whatsapp protocol? Did you reverse ingeneer it yourself? Do you use an existing library?

brenno.almeida

@arubislander @pparent app uses whatsmeow, a golang implementation of Whatsapp Web socket. So from Whatsapp perspective, its like you're using Whatsapp Web.

The risk of being banned using unofficial tools is never 0, but extremely low if you don't abuse the tool. Its the same risk of using the WhatsApp Matrix bridge for example, that uses the same library behind the scenes.

pparent

@brenno.almeida

Nice! Your app could be very useful especially to receive notifications in background with lower battery costs.

Hope the whatsmeow library can remain reliable in the long run!

Maybe you would like to post some screenshots of your app?

sahirul

Is it possible to log in with a phone number in this application?

brenno.almeida

@sahirul not yet, but is planned. For now, qr code only

brenno.almeida

Lots of changes since my original post. Some highlights:

Better name resolutions
Sync history chats
Fixed some bugs around logging out and disconnecting
Better performance when loading many chats
Add video and image messages
Sticker support
Better avatar sync and resolution
Swipe to copy messages
Reply messages are shown
Faster startup sync

Latest release: https://github.com/brennoflavio/greenline/releases

pparent

@brenno.almeida

I have a question, given that 3 have 3 separate parts to your app ( goland, python and QML), did you ensure the security of communication between them? How is it enforced that no other app, or process will be able to access the Whatsapp private data?

For example you say that the goland module exposes a JSON RPC endpoint, but are there security measures to make sure that this endpoint can be accesed only by your app, and no other app or process?

Thank's a lot for your work!

brenno.almeida

@pparent not yet! But I can expand on this topic.

First, the communication between go and python happens over a unix socket. This ensures that all communication is local between parts. This app does not expose your data outside the phone neither open ports (outside the WhatsApp socket). Notifications are also fully local (ubports push server is not used). But any unconfined process can access the socket and manage your account, three's no protection against that.

Also its important to mention that your encryption keys, messages and contacts are stored as plain text in 3 SQLite databases in the app data folder. This is necessary to do e2e encrypted communication with whatsapp, and it's similar to how Whatsnew or any other Whatsapp web client works by design.

This means that an attacker with a non root shell access in your device can steal your keys and send messages on your behalf for example. This is also true for our other Whatsapp web clients.

On Android, the official client uses a sandboxed storage to protect those keys, so only the app or a root user can access the keys. But as far as I know there's no such mechanisms in Ubuntu Touch for us to use.

gpatel-fr

@brenno.almeida said:

On Android, the official client uses a sandboxed storage to protect those keys, so only the app or a root user can access the keys. But as far as I know there's no such mechanisms in Ubuntu Touch for us to use.

oh thanks a lot for this remark. Finally I'm getting a glimpse of what is meant by 'our banking app can only work on secure devices'. I know that Google Play protect has other mechanisms but I did not see what could not yet be done on Linux phones.

ikoz

@brenno.almeida said:

as far as I know there's no such mechanisms in Ubuntu Touch for us to use.

Have you seen the secret-tool package? It's similar to using GNOME keyring.
You can also write your own keyring mechanism assuming your daemon starts before any app. It will store the keys in plain text when the phone is powered off and thus rely on full storage encryption. When the device boots up, the daemon will read the key from the file, store it in its memory and encrypt the file with the file's content as key. This daemon will communicate with your app via dbus or similar and send the keys only to the appropriate app id.

pparent

@brenno.almeida

Ok so another confined app does not have permission to access your messages and data, via this Unix socket?

pparent

@ikoz said:

Have you seen the secret-tool package? It's similar to using GNOME keyring.

Though it is to be noted that a porblem we have currently with App-armour profiles, is that it won't let you communicate with the keyring in DBus via the api libsecret. It is a problem for browsers like "Chromium for UT" or "Min Browser" that get non-functional password manager because of that.

projectmoon

@pparent said:

@ikoz said:

Have you seen the secret-tool package? It's similar to using GNOME keyring.

Though it is to be noted that a porblem we have currently with App-armour profiles, is that it won't let you communicate with the keyring in DBus via the api libsecret. It is a problem for browsers like "Chromium for UT" or "Min Browser" that get non-functional password manager because of that.

I am currently packaging Aria (Misskey client) and ran into the same problem. Had to patch it to store the credentials in a JSON file under ~/.local/share.