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:
#4466 (comment)
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

[LiloBzH]

Hi

Web Version to use RamBox for example !

[1Yanik3]

This feature would be amazing for me, as it would solve the problem of not having a secondary-device client for every single platform

[adioe3]

This feature goes fundamentally against Signal's design: it's peer-to-peer (messages are sent device-to-device where the Signal servers facilitate transport only). Having a web version would mean Signal servers are also a peer thus would collect your data so they can present it to you via the web interface. This defeats the main point of the software as it cannot guarantee privacy anymore due to a centralized infrastructure.

[harmic]

I don't think that is correct - the encryption / decryption that secures the users messages can be done equally well in a web app as it can in the existing desktop app. In other words it should be possible to write a web app that is a peer. The main security risk (mentioned earlier in this thread) is that the client (web app) would have to be fetched from the server, so there is a risk that a compromised version of the web app is downloaded. The same risk exists if you are not careful about verifying the desktop app when you download and install that.

…

On Thu, 26 Aug 2021 at 13:44, adioe3 ***@***.***> wrote: This feature goes fundamentally against Signal's design: it's peer-to-peer (messages are sent device-to-device where the Signal servers facilitate transport only). Having a web version would mean Signal servers are also a peer thus would collect your data so they can present it to you via the web interface. This defeats the main point of the software as it cannot guarantee privacy anymore due to a centralized infrastructure. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4466 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBQWCZYJK75HTDUZOZ76TLT6W2CNANCNFSM4QMVXMNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[adioe3]

I don't think that is correct - the encryption / decryption that secures the users messages can be done equally well in a web app as it can in the existing desktop app. In other words it should be possible to write a web app that is a peer. The main security risk (mentioned earlier in this thread) is that the client (web app) would have to be fetched from the server, so there is a risk that a compromised version of the web app is downloaded. The same risk exists if you are not careful about verifying the desktop app when you download and install that.

I see multiple problems there:

1. each peer keeps its own local data store so the data at rest is not on my devices anymore (web peer saves to Signal server) and I now depend on the security of Signal's servers not just for facilitating transport but also security of my messages at rest (FBI loves it when they can subpoena shit like this)
2. pulling a MITM attack on a web version is trivial (tweak a router in a coffee shop, filter some packets/spoof DNS/whatever.) whereas it is harder with a verified binary version running on my laptop (even if it is an Electron packaged web application - it doesn't load the UI from a remote location, has a baked-in certificate, etc.)
3. verifying a download once is annoying but doable, good luck verifying a newly-fetched-on-each-load web app

IMHO point 1 already disqualifies this feature as we'd be giving up a lot of security for a bit of convenience but I would love to be proven wrong...

[fabricedesre]

IMHO point 1 already disqualifies this feature as we'd be giving up a lot of security for a bit of convenience but I would love to be proven wrong...

The web app doesn't have to store data on the server, it can keep it locally stored in indexedDB. There are even ways to use sqlite.js with an indexedDB backend which could help with porting the desktop signal to the web!

[gund]

And there is also WebRTC which is designed for a native P2P realtime communications and completely removes the need for any centralized servers to store messages =)

[geirmarius]

And there is also cache APIs and serviceworkers so you only need to fetch a new client when you want/when there is an actual update. Pretty much exactly like a native app.

You can write a service worker to save/store/cache the client once on first (ever) load and never have to fetch a new client again until you manually (or automaticlly) wish to do so.

[Fmstrat]

I have updated @jkaberg 's Dockerfile for the latest version of Signal Desktop. I run into the same problem he did. I'm not even really sure where to start debugging the JS, as the index.js and chromium.js files that load are actually HTML files in the response.

Perhaps someone else can help identify where to go next.

To use:

docker build -t signal-web .
docker run --rm -p 443:443 --name signal-web signal-web

Then visit http://localhost:443 (Yes, http)

FROM node:14.16.0

ENV SIGNAL_ENABLE_HTTP=1
ENV PORT=443

WORKDIR /app
RUN curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | bash &&\
    apt update && apt install -y python gcc g++ make git libgtkextra-dev libgconf2-dev libnss3 libasound2 libxtst-dev libxss1 libxshmfence1 libatk-bridge2.0-0 libdrm-dev libgtk-3-dev git-lfs sudo &&\
    usermod -aG sudo node &&\
    echo "node ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/user && chmod 0440 /etc/sudoers.d/user &&\
    chown node:node /app

USER node
RUN git clone https://github.com/signalapp/Signal-Desktop.git /app &&\
    git-lfs install &&\
    yarn install --frozen-lockfile &&\
    yarn grunt &&\
    yarn build:webpack

USER root
RUN chown root:root /app/node_modules/electron/dist/chrome-sandbox &&\
    chmod 4755 /app/node_modules/electron/dist/chrome-sandbox

USER node
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

[jkaberg]

@Fmstrat cool, if you ever get it work properly - let me know. For now, I've settled for this

FROM ghcr.io/linuxserver/baseimage-rdesktop-web:focal

RUN \
 apt install curl && \
 curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add - && \
 echo "deb [arch=amd64] https://updates.signal.org/desktop/apt xenial main" | sudo tee -a /etc/apt/sources.list.d/signal-xenial.list && \
 apt update && \
 apt install --yes --no-install-recommends signal-desktop && \
 echo "signal-desktop" > /defaults/autostart && \
 rm -rf \
    /tmp/*

EXPOSE 3000
VOLUME /config

Beware of dragons (this runs an VNC and web server, which in turn gives you signal-desktop in the browser - not very ideal, but hey its working. config is in /config, so volume that).

[venthur]

Did you create a corresponding issue in the forum before closing this issue? I couldn't find it.

[enjikaka]

Rather cringe of Signal to close sooo many feature requests like that... Den tors 30 sep. 2021 16:05Bastian Venthur ***@***.***> skrev:

…

Did you create a corresponding issue in the forum before closing this issue? I couldn't find it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4466 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGWHD2FQ3KLJPOG3O5CZCDUERVCDANCNFSM4QMVXMNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Fmstrat]

@jkaberg Hey, I'll probably play some more with it this coming week, but I've tried your method and I just get a blank black screen with the cursor and left-hand clipboard when visiting <site>:3000. Any suggestions on what could be going on there?

[ashutoshsaboo]

Was this closed abruptly? Are there no plans to even consider this despite the widespread request in support of this? A web version has obvious advantages already detailed above by many users - portability and accessibility from anywhere & everywhere.

[riedel]

For those who came here to find updates:

https://community.signalusers.org/t/web-app-for-signal/1272

https://community.signalusers.org/t/is-there-a-way-to-run-signal-desktop-in-browser-chrome-firefox-edge-etc/1143/

Forums seem to be a nice way to keep users away from developers... (sorry for the sarcasm)

[Fmstrat]

@riedel I long ago started up synapse, signald and a mautrix/signal bridge in Docker as a Matrix setup. It allows me to use Element as a UI on desktop/mobile/web as a front-end for Signal, IRC, Whatsapp, etc. Works fantastically.

[clocksmith]

Would love to see an update on this choice considering the latest Web APIs. Genuinly interested why building a secure signal web client is currently infeasable in 2024, and what has changed, if anything, since the last analysis.