Seafile is a secure, reliable, and performant file sync and share solution. I have been using it since about 2014, occasionally trying out other solutions, but keep returning to Seafile. It has a fairly large feature list and works on every major OS/mobile-device. Self-hosting it has been painless and performance is rock solid. This post describes one particular feature that is useful to me and is present ONLY in Seafile (to the best of my knowledge).

(I am not associated with Seafile in any way. Just a happy user.)

Background

These days, there are a number of solutions for syncing your data among all your devices, including potentially keeping a copy in “the cloud”. Some of these solutions make various claims to respect your privacy. Some are open source and self-hostable as well. And yet, since the past ~14 years, I have come across only one solution that meets ALL of my requirements, especially because it is the ONLY one that meets one particular requirement. A requirement that I can’t quite believe is unique to me.

Key requirement

In addition to the usual requirements of good basic sync capabilities, availability of cross-platform and mobile clients, secure sharing via password-protected and expiring links, version history, etc. a key requirement for me is:

Having access to otherwise securely stored data from any random computer has saved me quite a few times. Especially when traveling abroad without carrying a computer.

How to make the encrypted data on the server browseable from any computer through a browser? Assuming that the interface to browse unencrypted files already exists for authenticated users, there are a couple of options for browsing encrypted files

OPTION 1: Ideally, that encryption password never leaves the client browser. The browser receives encrypted data from the server, decrypts it locally, and presents it. But,

OPTION 2: If the encryption password does get sent to the server, then the server should not store it for more than a configurable length of time while taking reasonable precautions to protect it.

It turns out that Seafile is literally the only software (that I know of) which fulfills this requirement, via OPTION 2 above. The data stored in seafile can be encrypted by default. You enter the encryption password once for each client/device and thereafter, the encryption is transparent on your devices. The encrypted data is not accessible through the Seafile web interface, after logging in, unless the encryption password is entered, which is removed from the server’s memory after, I think, one hour.

Security and threat model

At this point security purists will raise several valid points

  • For OPTION 1, if the server serves up the JavaScript, then it cannot really be trusted

  • For OPTION 2, if the encryption password is sent to the server, then all bets are off

While these points are indeed true, I believe a decent security/usability tradeoff can be obtained by self-hosting the server software, following general guidelines to secure the server, and scrutinizing the updates. But under which threat model would this belief hold? As an average Joe,

  1. I would definitely like to protect my data from non-targeted attacks and employees who have access to server-side infrastructure
  2. I would like to make it rather difficult for targeted attacks from “hackers” and employees who have access to server-side infrastructure
  3. I do not intend to secure data against infinitely resourceful, targeted attacks from industry and nation states.

As an individual with limited time, resources, and knowledge, I do not think it is possible to protect against 3. above. For 1. and 2., spinning up a virtual machine on Linode, Digital Ocean etc., installing a stable Linux server distro, installing Seafile and taking basic security measures (firewalls with ports blocked by default, using key based SSH access, applying security updates regularly, TOTP 2FA everywhere along with a strong password, etc.) probably suffices. Yes, Seafile’s encryption scheme has been criticized as being weak and for leaking metadata. While the criticisms are valid, I do not think they strongly affect my use case and threat model. I rarely browse the encrypted files through the web interface. The principal threat in this setup, in my opinion, is if the server is somehow compromised and an expert attacker is then able to retrieve the password that is stored in the server’s memory for one hour.

What alternatives to Seafile exist?

None - if the requirement of accessing client-side encrypted data on self-hosted server from a browser, is to be met.

  • If you don’t care about accessing the data from a browser, and wish to jump through some hoops then Cryptomator could be used with any cloud provider. Support for mobile platforms varies and is generally cumbersome.
  • If you don’t care about having a server at all, then something like SyncThing or Resilio sync works for peer-to-peer synchronization. But SyncThing does not support iOS while Resilio Sync is proprietary closed source.
  • NextCloud continues to gain more attention and traction. When using it in the past, I’ve been plagued by poor performance and sync issues. Also, the fact that NextCloud loudly and proudly proclaimed having End-to-End-Encryption (E2EE), then shipped an implementation where files in sub-folders would silently be not encrypted, let that stay broken for months, then mildly tuned down the E2EE rhetoric on their website by claiming it as an experimental feature… makes me want to never trust NextCloud again. E2EE still seems broken as of this writing. It’s been over 2 years.
  • pCloud offers closed-source client-side encryption as a feature that costs extra and the files can not be accessed without the pCloud client.
  • Tresorit also claims end-to-end encryption, but is closed source and it is not clear whether it allows accessing encrypted data through the web browser.
  • Most of the other popular cloud storage providers (Dropbox, Google Drive, Microsoft, …) do not seem to support end-to-end encryption.

I’ve often wondered why it is that Seafile is the ONLY solution that meets this requirement? Is this inherently a bad requirement to have from a Security perspective? Is it that this requirement can not be implemented in a truly secure way, so nobody else implements it? Do most other users not have this requirement at all? Why?

In any case, I continue to be completely satisfied with Seafile. Since 2014 and over numerous upgrades, it has not broken for me even once and continues working impeccably.