Skip to content

Eliminate backend allow-list #987

@jbash

Description

@jbash

I would really like to be able to use Seedvault, but I gave up on it years ago because it doesn't support any backends I'm able (or willing) to provide. And I see a whole bunch of requests for this or that backend, with most of them being things that probably have SAF providers available. The ones I would like to use definitely do.

My understanding is that Seedvault actually works with many, most, or all SAF providers, but there's a hardcoded list of the ones it's willing to use. I've seen hints at three reasons for this:

  1. Worry that a backend won't be available when it's time to do a full restore. I don't think this is a good reason.
    Full restores are rare. It may be inconvenient, but it's not unreasonable to copy a backup repository to a USB stick if you need to restore it. It is unreasonable to have to use a USB stick for every incremental backup. And it's sometimes possible to provide a read-only view of a repository in a backend where it would be impossible to provide a read-write view of the same repository. For that matter, although it may be unnerving, installing an arbitrary backend provider seems unlikely to break a restore, especially one that would itself install that same provider.
  2. Some kind of missing API support in some backends. If this is real, I think the answer is to just test a backend for the needed support when a user tries to choose it.
  3. Lack of confidence in the cryptography. But this makes very little sense when you already have WebDAV enabled, since WebDAV could be storing the repository basically anywhere. Anyway I get the impression the cryptography has improved.

If the worry is that naive users will be confused, well, naive users are always confused. But surely the right answer to that is to put it in some kind of expert mode, not to completely deny the functionality.

If the worry is that you'll be responsible if some third-party SAF provider fails to properly store the files you give it, all I can say is that you're not responsible for that. If you use SAF the way it's supposed to be used, and a provider doesn't give you the service you're supposed to get, that's not your problem.

I don't see any discussion of this anywhere, but I'm sure it's been discussed. For all I know, you revisit it every six months. I'm just begging you to be sure you really still believe that the restriction makes sense. Because the software is embedded in ROMs, it's often hard, and perhaps dangerous, for end users to create their own forks, so it really matters what the stock version does.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions