element-desktop opens external browser to sign out of sessions

[dougmccluer]

Steps to reproduce

Go to All settings -> Sessions
scroll down to "Other sessions"
pick one of the sessions and click on "Manage this session"

Outcome

What did you expect?

I expected to be presented with the option to sign out of the session

What happened instead?

My web browser opened and took me to https://account.matrix.org/account/?action=org.matrix.session_view&device_id={device_id}

Why is this bad?

• I don't want my web-browsing activity associated with my Matrix account - that includes recording details about my browser alongside my matrix device id in server logs. I expect all functionality related to my Matrix account to be available within the app. Considering the desktop app is electron this expectation seems on its face to be pretty reasonable.
• the "Manage this session" link does not indicate that it will open externally. By contrast, the button at All settings -> Account -> "Manage account" at least has an icon that indicates it will open externally. The "Manage this session" link gives no such indication, so users have no reason to expect that clicking it will open an external browser.

Operating system

Linux: Debian 13

Application version

Element version: 1.12.3 Crypto version: Rust SDK 0.14.0 (c3b7918), Vodozemac 0.9.0

How did you install the app?

apt repo: https://packages.element.io/debian/

Homeserver

matrix.org

Will you send logs?

No

[florianduros]

Hi! If you don't want to use account.matrix.org to manage your session. I suggest that you choose another homeserver which is not using MAS (https://servers.joinmatrix.org/).

About manage session, your suggestion to add icon to indicate it will open externally is imo correct

[dougmccluer]

Hi! If you don't want to use account.matrix.org to manage your session. I suggest that you choose another homeserver which is not using MAS (https://servers.joinmatrix.org/).

Hi @florianduros!
The issue here is not about which server/domain manages the session. It's about which client is used. Why can't element-desktop talk to account.matrix.org itself, or using a browser other than the default?

The current flow assumes 1 device = 1 browser = 1 identity. And that may be true for the most common user, but it's certainly not true in every case. Even if it's necessary to handle the auth flow in a different application/browser, the user should be allowed the opportunity to select which application to use on a per-case basis, or which account container within the browser should be used to open the URL. Note that it's also possible to be running element-desktop on a device or container that doesn't have access to any browser.

I think it's acceptable to default to the 1 device = 1 browser = 1 identity paradigm, but expose some configuration options in settings that would allow advanced users to override this behavior if they have different needs. For a working example of an app that implements this pattern, take a look at: https://www.jetbrains.com/help/idea/settings-tools-web-browsers.html

[t3chguy]

Why can't element-desktop talk to account.matrix.org itself

Because MAS (and most other OIDC IdPs) do not allow a client to submit a username+password via any form of API, only via the IdP's own Web UI.

the user should be allowed the opportunity to select which application to use on a per-case basis

There are existing tools for use-cases like this, like Choosy.app on Mac and similar on other environments. Electron just uses xdg-open I believe.

Note that it's also possible to be running element-desktop on a device or container that doesn't have access to any browser.

That is not inherently supported, we may add it as a dependency to the deb package if that clarifies that.

For a working example of an app that implements this pattern, take a look at: jetbrains.com/help/idea/settings-tools-web-browsers.html

I think this is an inappropriate comparison, that is an IDE which is literally used for building applications which involve Web UI, so of course it has additional tooling to configure your web browsers given it is 1) for developers 2) for web applications.

[dougmccluer]

Because MAS (and most other OIDC IdPs) do not allow a client to submit a username+password via any form of API, only via the IdP's own Web UI.

Is it possible to load and display external web content within an electron app?

I think this is an inappropriate comparison, that is an IDE which is literally used for building applications which involve Web UI, so of course it has additional tooling to configure your web browsers given it is 1) for developers 2) for web applications.

When I said, "For a working example of an app that implements this pattern, take a look at: https://www.jetbrains.com/help/idea/settings-tools-web-browsers.html" I wasn't suggesting that Intellij and element-desktop are built for the same purpose. The point was to give, for reference, an existing implementation of a UI pattern that allows users to customize how the app handles web urls - the example speaks to "how", it doesn't speak to "why". The reasons why it's useful to do in element-desktop are different from the reasons why it's useful in Intellij.

[t3chguy]

Is it possible to load and display external web content within an electron app?

Yes, with the following issues:

1. Lack of user trust, tools like password managers won't be able to verify you're entering your credentials until the right origin
2. Lack of things like webauthn, so IdPs like PockedId entirely won't work
3. Certain IdPs may brick function to a user agent containing "Electron" which could be in ways which are not programmatically detectable (Eg translated errors saying to open in a real browser)

[dougmccluer]

Lack of user trust,

Speaking on behalf of this user - element-desktop reaching out without warning into another application to leak information has done a lot more to undermine trust. I know that probably sounds like criticism and probably makes you feel defensive and inclined to insist that it's wrong to want compartmentalization in the first place. If this does come off that way I'm sorry - it's not my intent to chastise or attack anyone. I just hope you will try to view it from my perspective:

• I wasn't expecting element to send information through my browser.
• It's important to me that it doesn't.
• When I adopted this app it didn't.
• It started doing so without giving me a choice, and without warning me about it or giving me a chance to migrate to a different app or home server.

It really feels like a rug-pull - I used to have more privacy, and now I have less. My autonomy and freedom to choose were taken from me, and my intentions were subverted. I feel less secure. What reason do I have not to assume there will be more rug-pulls in the future?

tools like password managers won't be able to verify you're entering your credentials until the right origin

If it's a password manager that's only designed for web apps, then I can see how that might be the case, but if that's how I wanted to interact with element then I would be using element-web. I chose element-desktop because I wanted a stand-alone desktop application, completely compartmentalized from my browsing activity. I chose it expecting a native-desktop experience, including a native model for interaction with my password manager.

Lack of things like webauthn, so IdPs like PockedId entirely won't work

Building native webauthn support into the desktop app seems like a great idea! Sounds like Discord thought so too: https://discord.com/blog/how-discord-modernized-mfa-with-webauthn
Has this library been evaluated? https://www.npmjs.com/package/@electron-webauthn/native

Certain IdPs may brick function to a user agent containing "Electron" which could be in ways which are not programmatically detectable (Eg translated errors saying to open in a real browser)

That really sounds like a bug in the IdP. Is this a hypothetical argument, or is there an actually observed example of this?

Again, I have no objection to giving users the option, to use their default browser for this, or even for making that the default option. My only objection is forcing existing users to take that route with no alternative

[t3chguy]

That really sounds like a bug in the IdP. Is this a hypothetical argument, or is there an actually observed example of this?

IdPs make all sorts of similar decisions to "protect" users from clickjacking and nefarious applications.

I agree an application should not open a browser unless the user is explicitly clicking a link or a similarly obvious action button, though ultimately it is up to the Design team what the User Experience looks like.

I'm only against turning Electron back into a web browser where then we also have to ensure your secrets are protected against any bugs in Electron where the IdP could possibly exfiltrate your encryption keys, and we'd have to re-implement a bunch of browser functionalities (like webauthn) most likely by growing our 3rd party library list significantly...

Has this library been evaluated? npmjs.com/package/@electron-webauthn/native

10 weekly downloads, solo contributor, 0 stable releases - especially with the amount of npm packages which have been exploited in recent attacks it is not a good looking candidate.

The alternative to all of this is code/qr flows for authentication. Element Web/Desktop already support being used to bootstrap an Element X Android/iOS device using QR code login, the reciprocal flow is coming soon. QR code flow still requires affirmation in a web browser in the IdP to authorize the new session.

OIDC supports simple code flows used by services like Netflix/Youtube to log into a TV where entering your credentials (webauthn?) is impractical. This would also solve the issue of a jailed browser not being able to send the auth flow back to Element Desktop via a scheme handler. If this is something you'd care about you'd likely want to open an issue against the Matrix spec so that this becomes a thing it supports so we can adopt it.

[dougmccluer]

10 weekly downloads, solo contributor, 0 stable releases - especially with the amount of npm packages which have been exploited in recent attacks it is not a good looking candidate.

Makes sense. Perhaps though it may be useful as a reference/guide for an implementation authored within the org ?

QR code flow still requires affirmation in a web browser in the IdP to authorize the new session
OIDC supports simple code flows used by services like Netflix/Youtube to log into a TV where entering your credentials (webauthn?) is impractical. This would also solve the issue of a jailed browser not being able to send the auth flow back to Element Desktop via a scheme handler.

Having more options for devices to mutually authenticate each other is definitely a good thing!
Ultimately though, the thing that's harmful, and that conflicts with what I expect is many people's motivation for choosing matrix, is forcing everything to depend on a centralized identity provider that can only be accessed via a remotely served javascript app running in an external general-purpose web browser.

ultimately it is up to the Design team what the User Experience looks like

What's the most effective way to report a UX issue to a product owner/designer?

I acknowledge that I'm trying to have a "this product design has stopped serving my use case" conversation, while it's possible @t3chguy may want to limit this to a "is the implementation correct according to the design spec", conversation. If it's the case that Github issues are only visible to engineers who have no ability to influence UX decisions and there's a better venue for this kind of product feedback, do let me know - I don't want to waste anyone's time with irrelevant discussion! :)

[t3chguy]

Makes sense. Perhaps though it may be useful as a reference/guide for an implementation authored within the org ?

We don't have the bandwidth to maintain additional native code which needs testing on many environments, hence the use of Electron in the first place.

What's the most effective way to report a UX issue to a product owner/designer?

There isn't really one, especially as the product person responsible for Auth doesn't really look at Element Web/Desktop issues, primarily at MAS issues. Ultimately the product people are all very busy with customer commitments now.