element-hq
element-desktop authentication and device management via web browser expose users to security risks
Your use case
What would you like to do?
Log in to my homeserver matrix account without element-desktop automatically opening a web browser.
Why would you like to do it?
Because running element-desktop in one sandbox / jail, automatically opening a web browser that runs in a separate sandbox / jail is not possible (or quite complicated) to configure. Meaning the "automatically open homeserver authentication dialogue via web browser" function opens a browser in the wrong jail context, typically that means completely unjailed. Then, the homeserver URL is https, which exposes the users' home folder to all weak spots in the browser security. A malicious homeserver operator (or a third party) could inject exploits into the authentication page that might then be able to access the users homefolder, unprotected by the sandbox normally used.
Edit/addition: Same problem is - since some recent change - true for the new device management: trying to delete / sign out a device also requires to use a web browser, and again does not provide a link to manually copy & paste but auto-opens the web browser, disregarding jail configurations.
How would you like to achieve it?
Log in to my homeserver matrix account without opening a web browser. Alternatively, being able to copy & paste a link myself and get a login token that I can copy & paste back into element-desktop.
Have you considered any alternatives?
The copy & paste solution is the considered alternative.
Additional context
The sandbox here is firejail, and the browser gets opened via DBUS (if I understood that correctly), which is another problem in and of itself.
With reference to https://github.com/element-hq/element-desktop/issues/2689 :
When omitting the need for DBUS (electron problem to require DBUS for safe storage implementation) via e.g. --storage-mode=force-plaintext (use at your own risk), the core problem I am having here is going away:
With DBUS unavailable, the web browser for authentication / device management is actually opened within the same sandbox/jail as the element-desktop application, no longer exposing the environment outside of the jail to browser security flaws.
So I guess this issue could also be solved by an upstream fix to electron (if I understood #2689 correctly) - if that project is willing to get rid of the godawful (imho) DBUS interface.
I think Electron for Linux is leveraging Chromium's existing password store code for its safeStorage, so likely the fix could be made there also
i currently also struggle with a jailed browser and element running in flatpak. having a simple copy and past token would really help. for me it is currently not possible to log into element. are there any easy workarounds (like "fetching" the required data from firefox console and enter flatpak and run some command or put the fetched data in some config file of element? the current UX is quite bad. solutions like "disable firewall", "disable jail", "use native element installation", ... are not the ones i am looking for (i really miss the username and password fields directly in element) any help is appreciated
edit:
system: element is running in flatpak firefox running in firejail
workflow:
- start element
- click sign in
- click continue
- firefox opens with
https://account.matrix.org/consent/<redacted> - logging in in firefox
- pressing continue (in firefox) does nothing.
i assume element:// handler is somehow missing and firejail restricts the access from firefox to element. so having a simple copy paste token would really be a good thing.
(i really miss the username and password fields directly in element)
You could choose a matrix homeserver which doesn't require the use of oidc.
(i really miss the username and password fields directly in element)
You could choose a matrix homeserver which doesn't require the use of oidc.
which would mean to loose all contacts and history. not a real option.
(i really miss the username and password fields directly in element)
You could choose a matrix homeserver which doesn't require the use of oidc.
I agree with @c33s that this is a bad solution. Mostly because - as far as I am concerned - no application should ever launch a web link without my approval, and without me being to inspect the link before opening it.
If I am not mistaken, when I first mentioned this login problem months ago in the Element matrix room, @ara4n had agreed that providing links for the user to copy & paste themselves would be an option worth considering.
I think the element team should consider it, for the sake of transparency in what information of the user is exposed to which web server (for all the user knows right now, the URL opened could be something outside their homeserver with a redirect, sniffing on their activities - it wouldn't even have to be malicious intent by element, it could be the homeserver being compromised and commicating the wrong authentication server URL).