Remote Desktop

Design documentation for remote desktop and GNOME. Here GNOME can be either client or server. The primary client UI is Connections, and the primary server UI is currently in Settings.

Goals

  • Interoperate with other desktop platforms
  • Interoperate with hosted remote desktop services
  • Make remote desktop accessible to those without technical knowledge
  • Support common use cases

Use cases

Three main use cases:

  • User support: the person providing support connects to someone else's desktop, to help resolve an issue
  • "Server desktop": the desktop user is also the admin of a server which has some kind of graphical app (possibly a configuration utility), which they want to use
  • Personal remote desktop: the user has a machine that they use as remote desktop, because it provides a capability that their current desktop doesn't (maybe it's a different OS, has a particular app, is configured as a development environment, or has special hardware)

Environment types:

  • Client and server can be on the same LAN, or on different LANs
  • The server can be a personal machine administered by an end user, or it can be administered professionally be an organization

When the server is administered by and organization, we can expect there to be documentation on how to connect and which address/network identifier to use, since the host name alone won't work.

If the server is a personal machine than sharing the address to that machine becomes more difficult if the connection is over a WAN:

  • The client often needs to know the public IP of the server
  • The firewall might block remote desktop connections - might need ports opening for it to work
  • There are security issues with VNC - it isn't encrypted
  • IP addresses are dynamic so may change

Remote desktop connections between machines on the same LAN are easier, since you don't have these issues.

Relevant Art

Windows 10

The Windows remote desktop settings expose the hostname of the machine. Their network settings also allow the user to discover their public IP (it's a link to a page on Microsoft.com which displays your IP).

GNOME 40

Client (Connections):

  • Connections supports VNC or RDP.
  • Connections currently requires an address which includes the protocol prefix for the connection, eg: vnc://123.1.12.123 , or vnc://hostname.local, or rdp://remote-desktops.com/123456

Server (Settings):

  • Supports VNC only - no RDP.

  • Includes an URL to connect, in the format of vnc://<hostname>.

  • Can only connect to the machine while the user has an unlocked, active session (if you were to connect remotely the display would turn on and unlock).

Tentative Design

Mockups:

Future Enhancements

The main workflow challenge is how to identify the server over a WAN network, in a way that's simple for users. Some possibilities for improvements here:

  • Potentially implement "reverse connections" in Connections. This feature is already supported by Vinagre. The client user sends an URL to the server user. When the server user opens the URL, it allows the client to connect to them. Reverse connections allows you to bypass firewall restrictions. It would require gnome-remote-desktop to have "listen mode" for this to work out of the box (doesn't currently have this).
    • Reverse connections will not work when Windows is the server (reverse connections uses SSH, which isn't in Windows).
  • Implement service discovery through Avahi. Would allow discovery of remote desktop servers on the local network, presumably only between GNOME machines.
  • Automatic protocol identification in Connections - would make it easier to specify the network identifier.

On the server side, long term we want to support RDP and make it possible to have a proper remote session - allow logging in to the machine using a separate session from one that is already active.

Design/OS/RemoteDesktop (last edited 2021-07-28 16:42:23 by AllanDay)