barsliner.blogg.se - Syncthing without homegroup

#SYNCTHING WITHOUT HOMEGROUP INSTALL#
#SYNCTHING WITHOUT HOMEGROUP UPDATE#
#SYNCTHING WITHOUT HOMEGROUP FREE#

The browser trusts only a few root certificates but not the ones provided by the website. How Syncthing can use TLS but without all these complications? For example, Let’s Encrypt requires that you can write a file at a specific location, or the Amazon Certificate Manager needs that you put a CNAME record to the domain. It provides authentication so that the client can be sure that it communicates with the other client and no adversary can listen inīut when you configure HTTPS for your website, you need to prove access to a domain to get a valid certificate.It provides encryption with up-to-date algorithms.

This solves the two problems with encrypted communication: Syncthing implements the TLS protocol, the same that the browser uses when you connect to websites via HTTPS. Why it can work this way is due to how it implements communication between the peers. There is no central server that provides a common connection point for the clients.

#SYNCTHING WITHOUT HOMEGROUP FREE#

It’s no longer a decision between trust and no trust but between a free solution and a paid one. There are hosted solutions, but using one changes the financial situation. This setup doesn’t need any trust other than the packages used.īut running and maintaining my own server is a pain. I can run my own server, use the client from third-party repositories (such as the main Ubuntu repo) and set a password.

#SYNCTHING WITHOUT HOMEGROUP INSTALL#

And third, the server is also available as open-source so I can install it on a machine I control.

Equally important, the client is open source so that I can be reasonably sure that the encryption is implemented well.

This way the server can not look into the files.

First, it supports client-side encryption.

This works similarly to Dropbox, but there are 3 important differences: I’ve done that, but it’s not a solution I’d recommend to anybody. Of course, you can use an encrypted filesystem (like eCryptfs) and share only that with Dropbox, but it’s a pain to configure and run. I never liked the idea that I’m sending files to a provider and only “company policy” stands in the way of it abusing them. But when there are ways to eliminate this trust they are usually more secure alternatives. You need to trust the provider, and it is the way of business in many services.

And maybe not, but you can do little beyond trusting it.

Maybe it does not look into your files and takes good care of security.

#SYNCTHING WITHOUT HOMEGROUP UPDATE#

Moreover, Dropbox provides the client too, so even if it implements zero-trust encryption Dropbox can push an update to change that. The downside is that this is a machine that Dropbox controls and has access to all your files. The clients don’t need a direct way to communicate which is usually a pain due to firewalls, NATs, and dynamic IP addresses. This is a convenient setup as it relies on a central server that is globally reachable. Then if another client comes online it downloads all changed files. When one client detects a change it uploads it to the Dropbox server. It creates such directories once the currently needed debian-workarounds (see comments) are in place.Dropbox uses a central server to store your files and the clients connect to it. And there is already a proof-of-concept script to try out. The Debian wiki has a page about actually making use of its default user-private-group setup. Yunohost is already using the /home directory and has a special place for media files.īut I think there may be just some smaller configuration additions missing that could be really useful, not just as an advanced use-case, but likely for all users.įile sharing and collaboration might be immensely simplified if all users and user groups could automatically get collaboration directories that automatically take care of providing proper access permissions.