jitsi / jitsi-meet-electron

Jitsi Meet desktop application powered by :electron:

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Remote control return

PatAgglo opened this issue · comments

Hello,

The remote control functionality is expected to return in future versions of the jitsi meet electron?

This functionality is very important for me.

Regards

No short term plans for it, sorry.

This issue has some details on why it was removed: #431

If you understand the risks, then to get remote control back, you can either use an older version (e.g. 2.0.0 - 2.2.0), or you can rebuild the application with this boolean changed from false to true.

Going forwards, I can see two options:

  1. Put the feature behind a command-line flag or option in the settings. Display a persistent warning message when it is enabled, so users are reminded of the risk. Or,

  2. Fix the security concerns that make the feature unsafe at the moment.

I'd be very, very happy to get remote control back!

Just a thought:
I couldn't find any other secure and easy to use (no port forwarding) remote desktop control software.
All I found (TeamViewer, AnyDesk, Chrome Remote Desktop, ...) will definitely execute arbitrary closed source code on my PC.
So I'd rather choose a Jitsi-Meet server I trust and it'll be much more secure than with the alternatives!

If you introduce a command line option, or maybe a very big gui warning I'd be happy. Maybe something like: This will allow your communication partner AND ALSO the provider of the Jitsi-Meet server $SERVER_DOMAIN to control your computer.

Note:
Actually the only other open source alternative I found was the old-style XMPP-Jitsi application. But it looks like the development of that application has been stalled.

I'd be also very happy to get remote control back, thanks! ;-) I like the software very much, thumbs up!

Here is a patch to set the remote control enabled/disabled in Settings

If you run a private jitsi server, i think enable is not a real problem. Default is disabled.

jitsi_remote_control_parameter.diff.txt

Here is the fork/branch

https://github.com/ojehle/jitsi-meet-electron/tree/rc

commented

Hi there, would be really cool to have the feature back.
This feature would make this tool amazing, I could show some people that it's much better then other closed source SW...

i did a merge request, but rejected. i‘m checking the possibility to enhance the security by exchange a key. somebody requests your screen. a number pops up, when you accept. this number must be entered by the other and is used to encrypt the remote control channel. so if there is a server between doesnt matters anymore. its the same in teamviewer. and the server can be hacked, but never get a notice of the key, so he cannot decrypt.

the protection i did is to check, if the server entered in the settings is the same like the server of the conference. if its true and not the default remote control is allowed.

Or some client /server cert. Like OpenVPN, the server and client are authenicated against your own CA. Invoked when using your own Private Jitsi server.

I think it was responable to pull the feature of not secure, however the feature if required. Which my coding ninga skills were more up to scratch

@ojehle apologies for the noob question, I'm not a node dev, How do you apply the patch that you created on the fork that you made.

nothing special. i build the patched version according the developer infos in the documentation here

I cant build this project on my windows 10 machine. npm install errors etc. I am not a developer, so I need a deeper explanation on what is to do on a clean Win10 machine to build this project. Maybe someone has a tip for me on how to build @ojehle 's fork/branch!?

Any chance to get this into master branch? Maybe with enhanced Security?

Get what exactly? The code is there, just disabled. You can enable it by building the app yourself.

The remote control function will be great for helping your grandma out with computer problems remotely but of course it needs to be secure. Having a remote control function using Jitsi Meet is great for privacy and security since Jitsi Meet is open source, Jitsi Meet Electron is open source, Jitsi Meet Electron runs on Linux which many use for privacy and security and it is easy to setup and connect compared to other VNC apps which can be hard for "grandma" to connect to.

The only good alternative I know is TeamViewer which is proprietary and closed source. I hope to see Jitsi Meet Electron to have remote control functionality someday with security for this reason alone.

You don't have to reiterate, I know it was very nice to have. It was with a heavy heart that I had to disable it.

@saghul if there are ideas how to protect the remote control let me know.

i did the "small" protection for my jitsi server by adding the server hostname, for which i will allow the remote control. There is still the possibility on the server side, to intercept. with a private server (only for authenticated users), its under control of our company.

but other ideas

  • encrypt end2end remote control by a password (like timeviewer) (how to to this ? is there already a usable encrypted channel peer2peer channel in jitsi?)

more ideas are welcome..

Don't know if Zoom, Teams or other Tools protect from Administrator Access the Remote Control Data Streams?

with a private server (only for authenticated users), its under control of our company.

If you have control over the server and you supply your users with an Electron client which can only hit your server, you are fine.

The fix involves reversing the logic so the actual sharing starts at the client end when they press the button, but this code must be local to the client.

Please do not share links to foam with this feature enabled here. It's not safe to use except I very specific scenarios.

Do not trust anyone who shares such binaries.

Please do not share links to foam with this feature enabled here. It's not safe to use except I very specific scenarios.

Do not trust anyone who shares such binaries.

I put heavy notices in the README there not to use it unless you understand the risks, but, if you do not want it here, I understand. Would you rather me delete the fork entirely?

Feel free to have your fork, but please refrain from linking it here.

any news on that? imo thats a very important feature for all who do some online tutoring.
whats a bit confusing to me is that the advisory states that this will be fixed in 2.3.0, but i have currently 2.10 installed?
or does that only mean it is disabled since 2.3.0?
it would be really great if there would be at least some kind of config flag to turn this feature on when required and maybe warn the clients

No news. The advisory said no such thing. The security issue was “fixed” by disabling the feature altogether.

The meet.jit.si start page is still advertising the remote control feature

Where is that?

"Remotely control other participants desktop" - in the lower left box

@saghul Sorry for hitting on this issue again but, just to find more insight and try to make the roadmap more clear. In your view, the remote control, given the architecture of Jitsi and given the security risk, is something that would be definitely out of scope for this project roadmap? Or is it still very much on the possible roadmap, but it requires some expensive/significant changes to the code/architecture or even a new/updated version of the protocol for it to work securely, or so?

What about using the features that https://remotedesktop.google.com/ is built on so that electron app is not needed? This will probably require a new code base which with any luck might have no security bugs.

Can https://github.com/ojehle/jitsi-meet-electron/tree/rc be used w/o problems? ("98 commits behind jitsi:master")
Or should one build on his own, and for this change "const ENABLE_REMOTE_CONTROL = false;"?
(for master? Or which branch is matching up with the version you get for "sudo apt-get install" on linux?)

Wouldn't it be better to make RC a configurable option in /etc/jitsi/ for the official version distributed for "sudo apt-get install"?
It's already prepared with ENABLE_REMOTE_CONTROL.
So it should not be a big deal to make it usable this way for lots of users(?)

Please read the security advisory, I quote:

RCE via lack of consent in remote control: an attacker could run a modified Jitsi Meet server to trigger a user into enabling remote control and thus execute remote commands.

We will NOT make it configurable.

i really like jitsi, but remote control is - at least for me - a killer feature. and i also think in the more professional/business world is that.
why not enable that feature as config flag and then print a warning on the jitsi clients? so at least those who require that feature (and therefore can not use jitsi at all) are able to use it instead of zoom/ms teams etc.

and i am sure some would donate to fix the security concerns.

You can make your own build flipping that flag if you so desire.

commented

I see the point of making it a switch in the settings, maybe disabled by default?
Instead of making a fork just for this...?

I won't repeat myself. Next time I'll just lock this issue.

commented

Sorry, I just did not read above....I'll get more coffee!

Kinda disappointing that there is no insight on my proposal and instead people just come here and propose that the software should have a "PLEASE HACK ME" toggle.