Add an ability to change the jitsi fallback URL

[andyg1001]

Description

For private homeservers, creating a video conference in a shared room creates a widget that uses the "https://app.element.io/jitsi.html" webpage which leeches potentially private information (e.g. user details / homeserver details) to a public website.

Steps to reproduce

• Create a public room
• Add users to that room
• Start a video conference
• Look at the source for the widget

Describe how what happens differs from what you expected.

The documentation here suggests that a local copy of jitsi.html can be used. I'm not really sure what that means? Local to the homeserver or local to the client itself? I'm not even sure if the latter is possible with Android clients, for example.

What would be really nice is if the "well-known" url can supply this like it can provide (already) the "preferredDomain" value.

Version information

• Platform: desktop, Android, iOS

For the desktop app:

• OS: Windows, Linux
• Version: 1.7.12

[t3chguy]

The jitsi.html in the widget event is there as a fallback for clients without jitsi support. Element will use its local one. Mobile elements don't use jitsi.html whatsoever as they use a react native integration.

[andyg1001]

Hi t3chguy, thanks for the feedback. I did a test and you are right (of course 😉) -- blocking app.element.io in my network firewall shows that as a result everything works until you do the "popout widget" button in Element Desktop. At that point, it errors because the popped out version uses the aforementioned website.

Would it be possible to fix this, please? The well-known url route would be an good one since hosting a variant of the jitsi.html file on the homeserver website would be easy enough thing to do.

[turt2live]

Fixing the fallback isn't really feasible or practical - it controls such a tiny bit of the functionality that it serves mostly as a placeholder, and it only shows up if you're on a client that doesn't have a URL to use (such as Desktop).

[nE0sIghT]

We already have permalinkPrefix why not reuse it for jitsi?

[benparsons]

@chagai95 has observed that even in the case where there is a dedicated custom URL for the Jitsi in an existing Jitsi widget (eg if the call was started on another ele-web instance), desktop will still open the link on app.element.io.

What they would ideally like is to be able to set the URL from .well-known so that multiple clients can take the same value for the URL.

[chagai95]

Here it is hard-coded on Android:

https://github.com/vector-im/element-android/blob/afa2f13dda88a42ee70f81808ae0868a5c2b79f7/vector/src/main/java/im/vector/app/features/call/conference/JitsiService.kt#L75

And here on iOS:

in BuildSettings.swift there is a hard-coded define for the web app URL
static let applicationWebAppUrlString = "https://app.element.io"

[turt2live]

I think we fixed this with preferredDomain being accessible over .well-known? Changing the hardcoded fallback still isn't feasible due to how v1 widgets work. You can, however, change the default for what it uses to create calls which then gets populated.

[chagai95]

Could you elaborate or link my to the relevant issue? I would like to understand more about how this works and why it's not possible to fix... We would like to use different web instances for each customer and this means they will be depended on our web instances if we don't build customized apps for each customer...

[turt2live]

the only dependence should be in extremely rare scenarios where the widget isn't being rendered by a client - the URL is otherwise intercepted by the clients before it even renders the Jitsi widget.

If there's a case where the app.element.io link leaks outside of the widget frame, we would consider that a bug and it should be fixed. As a fallback though, a well-behaved Element client should be intercepting it regardless of the fallback URL, so an option to change the fallback URL becomes a bit arbitrary and hard to justify the maintenance cost.

[chagai95]

Didn't it always show when you pop out a widget? We have that behavior set as the default for us... I think if you don't pop it out you can't screen share from jitsi due to another bug.

[turt2live]

The only screenshare bug I'm aware of is element-hq/element-desktop#683 which would mean deploying your own desktop app to trigger, or some other config management system which changes a bunch of different variables.

We do kinda want to get rid of the popout button on Jitsi widgets though given it can cause problems for authenticated environments, however this is long distance work. We also have medium-ish term plans to swap Jitsi out for Element Call, which eliminates some of this concern.

The widget security model also comes into play here: we can't necessarily trust that deployments won't put deceptive values into their config, so would we be reducing the security level of the Jitsi support? (as an example question we'd have to ask as part of this)

[chagai95]

We deploy our own desktop app(s) and have a fork which fixes the authenticated issue when you pop jitsi out. I guess we'll have to wait for Element call and hope this doesn't pop up in an unexpected way.

In general the principal we're trying to follow at Aarenet is to have it fail rather than fallback on Element, I understand that's not a good choice for you but for us if some Element domain suddenly pops up because we merge from upstream and miss this, it could be at the most a security risk and at the least a trust issue depending on our customer...