Big changes coming to Kopia UI

General
1

TL;DR This post proposes rewriting KopiaUI in Go and getting rid of Electron-based app, this is good for security, but may change how the UI behaves, your feedback is appreciated

Background

KopiaUI (the desktop application) is a small, yet quite complex application. It has very minimal user interface (tray menu), but to present the repository UI, it uses Electron - very large and complex technology stack with many dependencies.

This complexity makes it hard to secure against OSS supply-chain attacks. This post proposes rewriting the app using different technology, to make it smaller, easier to secure and hopefully easier to work with going forward.

Issues

  • KopiaUI has many dependencies (currently ~1170) on open-source NPM packages. The NPM ecosystem is notoriously hard to secure because of its complexity and there have been recent attacks on low-level NPM packages used by many, which wreaked havoc across OSS projects that had dependency on them. Kopia luckily wasn’t affected but it’s a matter of time before the next attack like this and it could affect us too.

  • Electron is huge (around 80-100 MB compressed, up to 500 MB on disk) because it embeds the entire Chromium browser so downloads are necessarily going to be that big, even if KopiaUI does not have that much code by itself.

  • Kopia UI is written in Javascript which is not the primary language for the project, as most of Kopia is written in Go

Proposed change

We will replace Electron app with a small Go app with minimal dependencies, which sits in the system tray and leverages web browser for the UI.

Since the underlying HTML UI is ultimately served by kopia server and not KopiaUI, we can use a web browser that the user already has installed: when one opens a repository window, the new KopiaUI will launch a browser window pointing at http://localhost:some-port in a default web browser (Safari, Edge, Chrome, etc.) and present exactly the same UI as today.

Impact of the change

  • [+] since the app will be written in Go, we will eliminate all NPM security concerns
  • [+] this should reduce the build time by ~10 minutes
  • [+] the KopiaUI app download will be much smaller (hopefully <20MB, installed size should be <50MB).
  • [+] we’ll have better testing for the app logic
  • [-] we will need to develop custom code signing and release pipeline (currently handled by electron-builder from NPM), this will take some time to get right.
  • [+/?] we will need to develop custom auto-update support (also handled by electron-builder). This could actually open up smoother auto-update experience, because KopiaUI app will likely not need to be updated much, so updates can bring in just kopia
  • [+] KopiaUI will download the latest kopia on first run and keep it up-to-date.
  • [?] the repository windows will be part of a web browser app and not KopiaUI app. This should be very minor impact, since the KopiaUI app does not have any UI of its own beyond the Tray menu.
  • [?] some are not possible in a browser (such as local directory selector) and will have to be emulated - this will likely add things like path autocompletion, so is probably a good thing.

Timeline

In terms of a timeline, I’m hoping to have a preview of this app as a separate download in v0.10 (we will still have Electron as a main option) in early 2022. Once the app is on par with current KopiaUI v0.11 will have it as the only UI option.

If there’s significant interest in keeping Electron mode, we can move it to separate repository and maintain there, but old KopiaUI won’t be part of official kopia builds past v0.11.

Feedback

We appreciate your feedback. Since it appears that majority of Kopia users rely on the UI, I’m curious what you think about this change and it might impact you.

Also, any help is appreciated, we’re always looking for folks to contribute to the project, since this is quite a major effort, we can accelerate it with external contributors.

6 Likes
2

In short, we win on all fronts ? More secure, easier to maintain, no missing features… Only benefits, right ?
So let’s go :slight_smile:

1 Like
3

I think this is really good - getting rid of the bulky electron and dependencies is great from a security perspective. Can we have a single binary for the entire application? It made sense to have a separate UI binary if we are bundling electron, but now that it will be removed, it might be less confusing to stick with one binary. The binary can serve the UI on localhost via a terminal command, for instance, kopia ui or something along those lines.

4

+1 for getting rid of the Electron bloat. One potential caveat to keep in mind: Relying on the user’s browser environment will also potentially result in some support/maintenance effort related to its quirks, e.g., outdated/incompatible/obscure browsers, plugins, etc.

1 Like
5

I like that change, since kopia runs in places where electron doesn’t.

6

Thanks for the proposal and for all your great work with Kopia and KopiaUI.

I am rather reluctant to this proposed change and I dare to argue a bit against it. Why? Because I like the app for being a separate and well defined app and not being something more that lives in my Browser as Tab 22 of 25;-) . It would be more or less the same as Duplicati offers it with the Tray App/UI in the Browser combination. Besides that, I would like to suggest:

  • Focus first on the feature completeness of Kopia-UI compared to Kopia CLI. Especially the Linux world has n+1 backup solutions which live in the CLI. But it has not that much modern solutions with a carefully crafted and easy to use GUI.

  • Invest time in navigation and in guiding of not so tech-savvy users

  • Offer a standard user mode and an advanced mode. In the standard mode, offer a wizard which takes not so tech-savvy user by the hand

  • Look for neat details, for example respect locales for date and time format (24h clock, DD.MM.YYYY, etc.) in the UI, restore file/directory to its original location, restore all metadata (creation date/modification date/access date, etc.) of a file or directory

  • Think about Desktop Environments without a system tray like Gnome etc.

3 Likes
7

You’re making some great points. Usability of UI is significantly more important than the format of app itself.

1 Like
8

@wechsler Good points.
Because you mentioned Desktop Environments without system tray (e.g. Gnome): What would be an approach for this? I ran into Kopia-UI disappears to background after second start · Issue #1031 · kopia/kopia · GitHub
AFAIK, there is no replacement for system tray and also no alternative to show that an application is running in background…

9

Hello Josef,
in Gnome Vanilla as well as in Ubuntu they utilize workarounds like “AppIndicator and KStatusNotifierItem Support Extension” for the first or “Ubuntu Appindicators” (built in) for the latter. Both seem to be merely the same for me. However, it is a workaround and how to cope with applications running in the background and needing an always visible indicator in the system tray, well this is a question the Gnome dev team should answer. In the meantime I think is makes really sense to stick to “Kopia is a real desktop application with its own interface” path. because with that there is no dependency to a system tray.

10

Maybe I’m doing it wrong, but I’m using the “UI” through the server… Is this something different?

kopia server start --insecure --without-password

Then I pointed my browser to localhost:[PORT]. I use Chrome browser (on Gnome, so no app indicators or system tray) but all I did was:

  • Click the three dots
  • More Tools
  • Create Shortcut
  • Check the “Open as Window” box

Now the UI looks just like any other app on my PC.

image
image1092Ă—381 59.9 KB

It lives in my app launcher where I have it pinned, because I’m new to Kopia and I like watching it work.
image

When I open it, I get this,

image
image1669Ă—828 62.8 KB

Nice and clean this way.

2 Likes
11

Hello mattzab,

As far as I understood this discussion is geared towards KopiaUI " Graphical User Interface (GUI) : It is a desktop application, called KopiaUI , that offers a friendly user interface." and whether is should be substituted by a new Go Application living in the system tray and using a Web Browser for UI.

13

KopiaUI is very cool, but I didn’t use it, I prefer to use CLI because CLI is simpler, reliable and flexible.

14

I have similar questions, how is the Go+browser different from server+browser shown here? why not just using the latter(i.e. make the server more usable by non-CLI users, say wrap it into a click-to-install binary)?

15

Yes, that will be a wonderful thing. Electron is really, really a crap. In fact, I would agree for bundling the UI in single binary

16

I think a GUI app would be great if there are enough resources to see it through.

Electron GUI does not work for me on Linux with swaywm / Wayland.

For this I use the web UI which I think is more portable across systems.