search

mollyim / mollyim-android

Enhanced and security-focused fork of Signal.
GNU Affero General Public License v3.0
1.37k stars 78 forks source link

Desktop Client #225

Open kwpxxx opened 8 months ago

kwpxxx commented 8 months ago

Is there an existing request for this?

Feature description

Signal's default desktop client is extremely weak. You can put the database in an encrypted container for security but besides that there's still some room for improvement

sycam0r-e commented 7 months ago

besides that there's still some room for improvement

Namely?

LoveIsGrief commented 7 months ago

I don't know how many contributors molly-im has, but this seems like a big ask - even if some cross-platform framework were used to write Molly. Dealing with the particularities of mobile and desktop in one code-base would probably not be much fun.

There have been discussions on the signal community forum for years now due to the use of electron, but nobody, in all that time has taken the task upon themselves to write a separate desktop client and stuck with it.

As an outsider, this feature request looks very out of scope of this project.

miles992 commented 6 months ago

The biggest issue of the signal client (as well as other messenger clients) is the use of electron, it makes them horribly vulnerable to chrome 1-days. Using electron for apps with security focuis is sort of a bad choice.

LoveIsGrief commented 6 months ago

Nothing is invulnerable to X-days. No software is perfect as it is conceived by a flawed being. In any case, I don't believe that arguing the faults of signal's desktop client are not of a concern to this project as it's

  1. not a the signal desktop client project
  2. an android project

If you are unhappy with Signal's desktop client tell Signal that (create an issue or voice your opinion on the forum in the existing thread), make your own, or pay somebody to make a different one.

miles992 commented 6 months ago

Well, this request is about a possible Molly desktop client and people asked for room for improvements towards Signal. No idea what you saying. About 1-days, with Chrome being a very prominent target and a near to natural patch gap towards apps using it, that is something to be taken into account if making decisions (usage, development). POC are often available. And it's easier / cheaper for an attacker to re-use a yet to die 1-day than burning 0-days. That has nothing to do with flawed or less flawed, it's simply an economical thing these days. People with high security requirements such as journalists, researchers or other possible targets of attackers with deep pockets need to think about such scenarios. That is why I think it has to be part of the threat model which should be worked out before making a design decision including technological ones.

sycam0r-e commented 6 months ago

There really isn't much information in OP's post to be fair. I also think that this is out of scope for the project. It's ultimately decided though of course by lead dev @valldrac who will close this issue or keep it alive as he sees fit. :)