Signal-desktop: Signal web version

[rajib-raiyat]

signal web version need very badly.

Please bring this feature. I need signal web version like whatsapp web

[Piblokto]

From what I've read. Moxie seems interested however it's a bit hard to do and make it perfectly secure and private considering they'd have to essentially build another platform for the web app.

[Piblokto]

Continuing on... this was a community member's response in one of the Signal Community Forums... https://community.signalusers.org/t/google-to-retire-chrome-apps-what-will-be-with-signal-desktop/469/6

[mathiasbynens]

The desktop app is already a web app on top of Electron. What does Signal need that Electron offers but the web doesn't (yet)?

[KoffeinKaio]

With the new influx of people coming over from whatsapp, not bc everything is encrypted but signal doesnt seem to sell your data - this is something I really miss.
Not only because its easy but I hate having to open 3 separate clients to chat with everyone, everyone has a browser installed, even on work devices.

Also as @mathiasbynens mentioned: in my book Electron is a fancy way to embed a browser website in a client environment (very basic viewing, i know)

In my opinion basing the decision against a web-client on "we have to rely on ssl, but ssl can be intercepted" is invalid.
https already is used for online-shopping, gov-related stuff cloud-data sync and so on, all of this data is as important as my messages.

---

Uneducated question: shouldnt it be possible with a webassembly / libsignal-javascript to implement it somehow securely?

[geirmarius]

Hey. Very happy to see this topic getting some attention. I commented on this issue a while back, with pretty much the exact same question as @mathiasbynens, but deleted my comment as I felt it was a dumb question after reading about it (It really wasn't! and I should have kept my comment) 🙈

I can't quite remember what or where I saw the "answer", but apparently there is some problems with verifying the client code on hosted webapps, which is why the electron apps run with local files and the executable can be verified? man in the middle attacks etc.. Proton apps (protonmail etc.) also have this problem and apparently it's one of their "great drawbacks" according to some. If this is completely wrong and I'm just talking garbish, I'm sorry, I'm in no way an expert or have any sort of knowledge in this field. (security, encryption etc.)

Personally that's a risk I'm definitely willing to put up with, but I guess the issue is people will _default_ to the web app which does not offer the best protection by default.

Also want to add to the discussion: One of the great benefits of the web is how sandboxed it is, so for an individual it's a lot more secure that the app is running in the browser, than having full access to the computer. That's exactly why I'm using protonmail, twitter, spotify and many others as PWAs.

[Chandler-Kluser]

I have just migrated to signal from whatsapp/telegram. Missed this web interface feature, what a pity!!

But well done for you guys to make a instant messenger opensource and private, starred the project!

[bartoliniii]

I think this is one of the biggest limitation when we think about reaching a wide range of users.

[coy123]

Facebook just forced messenger on the desktop web browser and I'm fed up. I also don't want to install a client for each messaging app on desktop. The bookmarks on the web browser work just fine. +1 for this functionality.

[enjikaka]

I also want a web app. A PWA is perfect and also partly solves #4901 as Microsoft Store crawls PWAs, and also allows Signal on for example Chromebooks.

Regarding the ancient comment people keep refering to: that's outdated information since long. See Service Workers.

[geirmarius]

I also want a web app. A PWA is perfect and also partly solves #4901 as Microsoft Store crawls PWAs, and also allows Signal on for example Chromebooks.

Regarding the ancient comment people keep refering to: that's outdated information since long. See Service Workers.

Yeah, this is the one I was referring to! Thanks for linking it. 😄
A ServiceWorker sounds like a good fit here for sure. (Which would be required for a PWA to prompt installation anyways!)

[harmic]

Rationale for having a web client:

• Many people are not allowed to install unapproved software on corporate computers
• Make it possible for an average user to use on a Chromebook. (Yes, you can install the Linux client on a Chromebook if you enable crostini, but that is a path which is beyond many users)
• Make it easy to use on non-ubuntu based Linux distros, or any other platform for which there is no existing desktop client built
• Make it easy to access your messages from computers in libraries, at a friend's place, and other locations where there is a device you can borrow but can't install anything on

Rationale against:

• You need to trust the server the client is being loaded from, the browser you are using, and the implementation of the TLS protocol to keep your messages secure. Same as you do when accessing eg. your bank account via the web.
• Development cost

Personally I think the pros outweigh the cons.

[bartoliniii]

@harmic, I think you are missing one key aspect. If the goal is to become a leader in the messaging market Signal has to be a convenient and flexible tool, not only safe.

Many users just are using theirs browsers to chat with friends. They don't change theirs habits just because of safety.
We have to remember that Signal competes with messengers from the biggest - Facebook, Google, Microsoft, Apple. They really know how to do good staff and thus collect millions of data about us. The question is what is the goal of Signal. To change the world or being just another (safer) communicator?

[rajib-raiyat]

@bartoliniii I like your opinion.

[cw2k]

Imagine:
Signal to be the most secure messenger in the world.

So why is that?
Well it' simple like that:
No one is using it ! lol
No users no (security) problems.

But why is that?
Guess there is no webclient.
Well there was one (kinda) but it was deleted / shutdown by the developers.
... the actual desktop client could easily turned into one.
It's user interface is already just web stuff ( java script )

This refusal of a web client was done in the name of security.

But why don't you developers let the user decide how much security he wants?
Well are we really that incompetent?

Imagine:
There is a webclient and a desktop app.
User that are very concerned about security use the desktop app.
... and the fearless rest (like me) are happy to have a webclient.
User of the desktop app may choose to bail out web client users because they may 'ruin' the security.
So why this is no solution?

Why I prefere a web client?
Most is already said here:
https://github.com/signalapp/Signal-Desktop/issues/4466#issuecomment-763174632
In addition to that my issue with the a separated desktop app is that is 'wastes' much system resources.
I have a only a SSD hard disk. To make it last longer by reducing the write operations I disabled the pagefile / swap.
So my PC just uses the RAM that is there - no virtual pagefile RAM hard disk trickery. If RAM is full I get error messages and I need to close apps. So I start to keep an eye on how much RAM an app uses.
Signal uses 500 MB of RAM. But it could be much more less if it would run in the browser and share the web and javascript engine with the browser instead running its own. When I run the Chrome Task monitor I see that telegram just get's along with half of what signal needs.

However at the moment I just gonna move away from signal.
I already made my experience with the 'security hardliners'.

On my smartphone signal brothers me with messages like. "abc is using Signal." Can't I disable that? I just wanna see real messages.

Well I now used to reply to people that I gonna move away from Signal and
Use Telegram
Because they have it all:
a webclient
a desktop app
a smartphone app

And I already have enough messenger apps.
So sad but true. For me Signal is of no use without a web client.

[jkaberg]

As someone already pointed out the app is in fact an web app. So how about atleast leaving the door open for selfhosters? We trust our own infrastructure.

How about makeing an docker container out of the web app and serve it on a selfhosted server? I obviously haven't put any serious thought into it, but one issue would be Electron. Any apphroach in this direction obviously needs an big disclaimer noteing the security complications going forward.

[jkaberg]

Well, gave it a shot. The UI doesn't properly load in the browser (just the loading screen with 3 dots, however no errors in dev console)

FROM node:12.13.0

ENV SIGNAL_ENABLE_HTTP=1
ENV PORT=443

RUN apt update && apt install -y python gcc g++ make git libgtkextra-dev libgconf2-dev libnss3 libasound2 libxtst-dev libxss1

RUN git clone https://github.com/signalapp/Signal-Desktop.git /app

WORKDIR /app

RUN npm install --global yarn
RUN yarn install --frozen-lockfile

RUN cp /app/config/production.json /app/config/local-development.json \
    && sed -i "s/true/false/g" /app/config/local-development.json \
    && sed -i "s/\ \&\&\ hostname\ ===\ \'localhost\'//g" /app/main.js \
    && sed -i "s/http\:\/\/localhost\:6380\///g" /app/main.js \
    && sed -i "/^\ \ \ \ \"dev\:storybook\"/d" /app/package.json \
    && awk '{print} /^\ \ \ \ port\:\ 6380\,/ && !n {print "    host: \"0.0.0.0\","; n++}' /app/webpack.config.ts > /tmp/webpack.config.ts && mv /tmp/webpack.config.ts /app/webpack.config.ts \
    && awk '{print} /^\ \ \ \ port\:\ 6380\,/ && !n {print "    disableHostCheck: true,"; n++}' /app/webpack.config.ts > /tmp/webpack.config.ts && mv /tmp/webpack.config.ts /app/webpack.config.ts

ENTRYPOINT sed -i "s/6380/$PORT/g" /app/webpack.config.ts && yarn dev

[harmic]

I'm unclear on how this is going to be progressed.

If this was a regular open source application, there would be nothing to stop anyone creating a web app, but in this case not only do you have to write a client but you have to connect to Signal servers, and the project does not want third party apps connecting to their servers.

As far as I can tell no actual signal organization members are commenting on this ticket - so maybe some other channel is needed to draw attention to this.

[sqwwqw5]

Well, gave it a shot. The UI doesn't properly load in the browser (just the loading screen with 3 dots, however no errors in dev console)

FROM node:12.13.0

ENV SIGNAL_ENABLE_HTTP=1
ENV PORT=443

RUN apt update && apt install -y python gcc g++ make git libgtkextra-dev libgconf2-dev libnss3 libasound2 libxtst-dev libxss1

RUN git clone https://github.com/signalapp/Signal-Desktop.git /app

WORKDIR /app

RUN npm install --global yarn
RUN yarn install --frozen-lockfile

RUN cp /app/config/production.json /app/config/local-development.json \
    && sed -i "s/true/false/g" /app/config/local-development.json \
    && sed -i "s/\ \&\&\ hostname\ ===\ \'localhost\'//g" /app/main.js \
    && sed -i "s/http\:\/\/localhost\:6380\///g" /app/main.js \
    && sed -i "/^\ \ \ \ \"dev\:storybook\"/d" /app/package.json \
    && awk '{print} /^\ \ \ \ port\:\ 6380\,/ && !n {print "    host: \"0.0.0.0\","; n++}' /app/webpack.config.ts > /tmp/webpack.config.ts && mv /tmp/webpack.config.ts /app/webpack.config.ts \
    && awk '{print} /^\ \ \ \ port\:\ 6380\,/ && !n {print "    disableHostCheck: true,"; n++}' /app/webpack.config.ts > /tmp/webpack.config.ts && mv /tmp/webpack.config.ts /app/webpack.config.ts

ENTRYPOINT sed -i "s/6380/$PORT/g" /app/webpack.config.ts && yarn dev

You are in the right direction, I've been wanting to do this for a while now.
IMHO, official PWA support will be the most realistic and friendly to end-users and developers.

[augnustin]

I agree with @harmic. I would even say that no web interface is NOGO for me. :/ I definitely don't want to install all of your desktop apps that use web technologies and do exactly what the browser can do...

Besides, can't the front-end be shared between the web app and the electron one? Hence it shall not be so much extra work, shall it?

[KoffeinKaio]

A bit of a workaround maybe:

Setup a Matrix Server (Synapse, Riot or element-web, mautrix-signal, signald)

Works surprisingly well and supports a wide range of other bridges to messengers.

[jkaberg]

I'm unclear on how this is going to be progressed.

If this was a regular open source application, there would be nothing to stop anyone creating a web app, but in this case not only do you have to write a client but you have to connect to Signal servers, and the project does not want third party apps connecting to their servers.

As far as I can tell no actual signal organization members are commenting on this ticket - so maybe some other channel is needed to draw attention to this.

The POC was simply to use the Electron/desktop app as an base for web frontend. Thus its still the desktop app, just renderd in an browser instead of Electron

A bit of a workaround maybe:

Setup a Matrix Server (Synapse, Riot or element-web, mautrix-signal, signald)

Works surprisingly well and supports a wide range of other bridges to messengers.

Yeah that works, but IMHO not very feasible for even for an power user/selfhoster

[jkaberg]

I have no plans to continue the POC, I guess it needs some code changes to work properly and thats out of scope for me.

I've moved on, Signal just isn't what I though it would be.

[KoffeinKaio]

Yeah that works, but IMHO not very feasible for even for an power user/selfhoster

While it wasn't that hard tbh, it may be a new way to support and use signald as backend for developing a webapp instead of trying to modify the existing client.

Setup a Matrix Server (Synapse, Riot or element-web, mautrix-signal, signald)

My whole setup is dockerized, while it does require some configuration its fairly easy.
If I find the time to remove all passwords/secrets from the config I'll share the setup.

[jkaberg]

@KoffeinKaio I tried that approach a few weeks back, and running all thoes dependencies/containers/resource hogs just for Signal simply is a no-go here. I also think the experience was quite lacking when everything was running.

Just my 2 cents 😄

[venthur]

I appreciate the efforts, but I feel this discussion is going in the wrong direction. The original request was not to locally run a docker container that emulates what https://web.whatsapp.com does, but basically asking Signal to provide https://web.signal.org