4 ms·

> I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. We're doing exactly this prime-time with Relica: https://relic

by mholt 8y ago

> I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. We're doing exactly this prime-time with Relica: https://relicabackup.com https://relicabackup.com (sorry, not much on the landing page yet, but we have emailed out some info about the UI already [1]). That technique will allow us to distribute backup software that works the same for macOS, Linux, BSD, and Windows, right away; screenshot: [2]. And it's very lightweight. An added benefit of this approach: we were able to take its REST API and, after writing a small custom Go package, we instantly gained an elegant CLI [3] so it has a headless mode too! With all the functionality of the GUI [4]. I haven't seen much consumer software that does this, and I'm not sure why, so I feel like we're taking a bit of a risk, but I think (hope) it will pay off; the benefits have already started becoming clear and they're definitely appealing. [1]: https://mailchi.mp/2b5e7f57e400/a-brief-introduction-to-relica https://mailchi.mp/2b5e7f57e400/a-brief-introduction-to-reli... [2]: https://twitter.com/relicabackup/status/1005105584260067329 https://twitter.com/relicabackup/status/1005105584260067329 [3]: https://twitter.com/relicabackup/status/1006204516344086528 https://twitter.com/relicabackup/status/1006204516344086528 [4]: https://twitter.com/relicabackup/status/1006206423821254656 https://twitter.com/relicabackup/status/1006206423821254656

zaroth 8y ago
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!
- mholt 8y ago
  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.)
  - orf 8y ago
    > 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?
    - mholt 8y ago
      If you've got rogue software running on your machine, all bets are off.
      - Ajedi32 8y ago
        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.
        mholt 8y ago
        I see your point. But in my book, that's still rogue software. And that's a terrible sandbox. :)
        orf 8y ago
        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?
  - caf 8y ago
    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.
- tinus_hn 8y ago
  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.
mafro 8y ago
Interesting! How do you go about binding an unused port on client machines?
- mholt 8y ago
  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...
  - piva00 8y ago
    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 :)
woolvalley 8y ago
So how do you compare to arq backup or borg backup? Other than your choice of using a web browser tab for UI?
- mholt 8y ago
  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.
  - voltagex_ 8y ago
    >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?
    - mholt 8y ago
      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. :)
      - voltagex_ 8y ago
        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.

by mholt 8y ago

zaroth 8y ago

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!

mholt 8y ago
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.)
- orf 8y ago
  > 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?
  - mholt 8y ago
    If you've got rogue software running on your machine, all bets are off.
    - Ajedi32 8y ago
      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.
      - mholt 8y ago
        I see your point. But in my book, that's still rogue software. And that's a terrible sandbox. :)
        orf 8y ago
        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?
- caf 8y ago
  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.
tinus_hn 8y ago
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.

mafro 8y ago

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

mholt 8y ago
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...
- piva00 8y ago
  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 :)

woolvalley 8y ago

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

mholt 8y ago
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.
- voltagex_ 8y ago
  >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?
  - mholt 8y ago
    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. :)
    - voltagex_ 8y ago
      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.