Thank you, yes, I think architecturally there are great advantages to splitting up an app like a client/server even when designed primarily to be accessed over localhost.

Obviously the “server” API is extremely sensitive and I think you have to assume it is effectively exposed to the outside world, even with a 127.0.0.1 binding and a firewall.

I guess if you make localhost users literally login and establish a session then you could consider yourself safe. But it’s a weird experience logging into a local application. So whatever you are doing to authenticate the request as local, it has to be unspoofable.

I just don’t think I trust the HTTP headers enough!

Yeah, we don't trust just anything that comes in on that socket. For example, we implement standard CSRF mitigations like checking Origin/Referer headers. We also don't use DNS at all in the local frontend/backend interactions and require the Origin to be exactly "127.0.0.1" (or the IPv6 equivalent) which is what we bind to.

(Edit: I just looked it up again and I'm 99% sure that web pages can't override the Origin header, especially when making cross-origin requests.)

It seems like there could be unexpected interactions with other services running on 127.0.0.1, which don't even have to be HTTP to cause problems - eg what if there's a service that echoes back the request in the response if it receives a request it doesn't understand? A remote web page could probably use that to bounce its request to your service but appear to come from 127.0.0.1.

> I just looked it up again and I'm 99% sure that web pages can't override the Origin header, especially when making cross-origin requests

What about other, potentially unprivileged software running on your machine that can?

If you've got rogue software running on your machine, all bets are off.

Not necessarily. It could be running in a sandbox, or as unprivileged user, and accessing your app's API over localhost would allow for privilege escalation.

I see your point. But in my book, that's still rogue software. And that's a terrible sandbox. :)

I see your point, but you're saying:

> Yeah, we don't trust just anything that comes in on that socket

Well, you are, you're trusting it came from a browser so the Origin header is correct, right?

A login is not enough because of cross site request forgery. A site on the internet can include css, scripts or images from your service and generate get and post requests to it with the users credentials.

Interesting! How do you go about binding an unused port on client machines?

Use port :0 to let the OS choose one.

But for now we just hard-code a port. I personally prefer this since it's easy to use and convenient to remember. But if a lot of client machines have conflicts, I guess we'll change that...

Why not just change that? You are already in the same host, you can write the port that the server bound to on startup to a file and just read that from the client.

I've implemented something similar and went through the same stage "I will wait until someone complains" and they will happen, just prevent them right now :)

So how do you compare to arq backup or borg backup? Other than your choice of using a web browser tab for UI?

Great question. More details coming out soon on our mailing list and Twitter---and there's so many factors to consider---but in short, Relica:

- is designed for consumers who are not technically skilled

- works on Linux and BSD (I don't think Arq does)

- offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times

- allows you to backup to local disk, friends' computers (or your own) running Relica (with authorization of course), or the cloud, which is totally managed by us so non-technical users can use it

Relica also does client-side encryption and deduplication, of course. Backups can also be restored directly with restic (open source), without requiring a reliance on Relica.

Basically, Relica is a good balance of "user-friendly" combined with features for power users.

>offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times

How does that work?

We replicate your upload after it leaves your computer (at the packet level - we can't decrypt your data, we don't even have the key for it). There were quite a few technical hurdles we had to overcome to make this work, but I gotta admit, it's really cool to see it in action. :)

I recognise that username! Hello.

This does raise the question of how fast the upload will be - how's your network?

Switching from Dropbox to OneDrive doubled my upload speed simply because there's better peering from my ISP to Akamai vs whatever Dropbox was using at the time.

Hi there! Our upload infrastructure is designed to scale to anywhere in the world where we decide to put up relays. That makes the speed variable depending on where you are and where the relay is. We are still testing on our staging infrastructure and haven't deployed to our production networks yet, so it's hard to say right now what our speeds will be. But I'd love to know more about what your speeds are like now and what you expect with your backup service. Could you tweet at either me (@mholt6), @relicabackup, or email support-at-relicabackup.com and I'll get back to you on that?