element desktop installed in multiple path

[ghost]

Description

element installed to version dir in %APPDATA%\Local\element-desktop on windows. thius cause issues with firewall that block app by path since it constant changes. each new version is new rules and prompts

also both folders are full copy of each other which adds up. for me its ~250MB per folder and they dont get auto clean when updating. for small disks this can add up to big problem in time if users dont know

tangent this path seems wrong and should be in program files for windows not a user specific dir for main program, just config

Steps to reproduce

• install old element version
• note install path
• update
• observe new path

element installed in one path and overwrite for update. then rules can stay in place and not interrupt work

Logs being sent: no

Version information

• Platform: desktop

For the desktop app:

• OS: Windows 10
• Version: Element version: 1.7.33 olm version: 3.2.3

[ghost]

@SimonBrandner is this being fix? every update make a mess

[SimonBrandner]

@SimonBrandner is this being fix? every update make a mess

1. I am not a part of the Element team, I am just an outside contributor
2. Pining members of the team won't make things faster, there are some 4 900 open issues and all of these need to get attention, you just need to be a little patient

[ams-tschoening]

Not uncommon

The label O-Uncommon doesn't make too much sense, because the default deployment in Windows is like that and each and every Windows user will hit the same firewall problem. All users need to allow the firewall changes for each and every update.

Problems with my Bluetooth headset

This is not only annoying, but seems to degrade functionality as well: I already recognized multiple times that after an update, starting a call to someone and that call getting interrupted by the firewall question, that call doesn't use my configured headset anymore, but the Windows default speaker and microphone of my laptop instead. I need to close the call and simply restart it and the configured headset is used again, like it was the case before the update without the question of the firewall. I don't need to change any configs, really only quit and start the call again.

This looks to me like when starting the call and choosing the devices to use for a call, the app is not prepared for additional waiting seconds because of the firewall dialog and falls back to system wide audio config for some reason. Even though the headset doesn't have anything to do with the firewall rules at all.

Why are changes to the firewall needed at all?

Because of those reasons I already tried to disable P2P communication and stuff, but at some point audio and video calls always stopped working without allowing those firewall rules. OTOH, those firewall changes don't make too much sense, because I'm behind a NAT router with disabled UPNP, so there simply is no external traffic reaching my client firewall at all.

So where does the traffic come from? Which interfaces does the app listen on for which reason? Firewall wouldn't be triggered when listening on e..g localhost only.

Junctions for more stable paths

At least for Windows there seems to be a shortcut referencing some additional loader not stored in a version specific directory, most likely to keep the shortcut functional after upgrades. Windows and its new start menu based on search stuff is pretty bad in maintaining changing paths to shortcuts.

C:\Users\tschoening\AppData\Local\element-desktop\Element.exe

Though, that loader starts version specific EXE for the real work in the end and that path is considered by the firewall rules. That second EXE is what actually listens on interfaces.

C:\users\tschoening\appdata\local\element-desktop\app-1.11.24\element.exe

Windows supports a file system concept named Reparse Points and one usage of those are Junctions, which actually is a directory level link maintained by the file system. The good thing about those is that compared to e.g. Symlinks in Windows, Junctions DO NOT require admin permission by default! So they are totally compatible with the current deployment model of the app. the approach would be to create a Junction e.g. named current for each and every upgrade linking to the most recent version specific directory. The first loader would simply need to start the real EXE using the Junction path:

C:\users\tschoening\appdata\local\element-desktop\current\element.exe

That would allow the firewall to recognize that paths didn't change at all and simply keep using existing rules. The only downside is that per upgrade that Junction needs to be deleted and re-created, but that shouldn't be too much of a problem. Junctions can even easily be created at the shell:

mklink /J LINK_NAME DESTINATION_DIR

[t3chguy]

The installation is handled entirely by https://github.com/Squirrel/Squirrel.Windows/ I suggest opening an issue there.

[ThiefMaster]

Apparently there's a fork which fixed it: https://github.com/Squirrel/Squirrel.Windows/issues/1816#issuecomment-1158456641

I don't think any end users opening issues on squirrel.windows will help - there are in fact 4 issues on this topic already, some open for years.

[t3chguy]

Unfortunately not something https://www.electron.build/ supports

[ThiefMaster]

I'm not familiar with your build processes, and I understand that it may not be as easy as changing some config variable somewhere to use the fork instead - but considering how annoying this is to users, maybe it's worth looking into it even if it's more complicated?

FWIW, the current logic is annoying not only because of the repeated firewall prompts but also because the tray icon goes to the overflow list again after every update instead of staying in the always-visible area.

[t3chguy]

It'd involve forking electron-builder to add Clowd support, this isn't something we have the bandwidth to do with our team size right now. Contributions welcome of course.

[ams-tschoening]

each new version is new rules and prompts

What about that part of the issue? Did you check on which interfaces you listen for what reason by default? Do you really need to listen globally? AFAIK that is what triggers the firewall dialog, listening on localhost should be fine. I have many apps and services listening on localhost only without explicit firewall rules.

[t3chguy]

Did you check on which interfaces you listen for what reason by default?

We don't listen on any. It is Electron/Chromium's WebRTC listening on them for STUN discovery to enable peer-to-peer calls to work.

[vertigo220]

Commenting just to point out there are at least four other issues that have been created and closed as duplicates of this or others, creating quite a mess of interconnected issues that I had to follow one to the other to find my way here, to one that neither is clear that it relates to the firewall problem or shows up when searching for "firewall." So while this particular issue doesn't seem to have a lot of interest, that's very misleading.

Here are the related issues I've found (note this is further complicated by the confusing difference between the desktop and web repos):

https://github.com/vector-im/element-web/issues/#18946 https://github.com/vector-im/element-web/issues/#15973 https://github.com/vector-im/element-web/issues/#18938 https://github.com/vector-im/element-web/issues/#14788