Selecting a random send service

[cofob]

Hi! I'm the creator of the service fastsi.de, it's a gateway that redirects the user to a random working instance of open-source self-hosted services. This helps users to use self-hosted services, and helps services to distribute the load. It already has send services in it (e.g. https://fastsi.de/send redirects to a random working instance).

At the moment ffsend only uses the send.vis.ee instance, it would be cool to add an included option to get a working send instance via fastside and use it to upload a file.

This could be implemented via a separate flag, for example -r (--random-instance). I am willing to help implement this functionality if you approve this feature.

Of course, it's just as important to provide the ability to use a fastside instance other than the official one.

The advantages I see:

• The load on send.vis.ee will be reduced, distributed to other instances
• Increase decentralization and fault tolerance.

Cons I see in this approach:

• Different instances have different limitations, because of this some instances will not be able to upload a large file/set a large availability expiration time/large number of file downloads.
• Some instances provide poor upload/download speed.

[Kramtoske]

ffsend use whatever instance you provide with "-h"

[cofob]

ffsend use whatever instance you provide with "-h"

I know.
I'm not talking about that, I'm talking about the ability in ffsend to automatically select a random working send instance, without manually going to the fastside site (getting information via the fastside API), just via a separate flag. (-r, for example)

[cofob]

Since the standard send service (send.vis.ee) will be terminated soon I think this issue is still very important.

[cofob]

@timvisee please look.

[timvisee]

You're right! I'll find a suitable solution for this in time.

Since I cannot blindly trust other instances, I don't think selecting a random instance is a valid solution here. I think the alternative is to require to specify an instance yourself through the --host parameter.

[cofob]

Since I cannot blindly trust other instances, I don't think selecting a random instance is a valid solution here.

Why not? Encryption occurs on the client side, so there is no risk of information leakage. At most, metadata about the client (such as IP) leak, and in the worst case, the service simply won't work. It seems to me that this is much more convenient than entering the service manually using the -h flag.

[timvisee]

Encryption does indeed happen on the client. But I don't agree that makes it 100% secure in practice.

An uploaded file produces a share link. Opening that share link opens the web interface, which is controlled by the remote host. The web interface still decrypts on the client, but the remote controls the code for that.

When loading the web interface, there's nothing stopping the remote from stealing the encryption key which they can use to decrypt the file. I host send.vis.ee, which is why I can trust both ends. But I can't say the same about other hosts. Though picking a random host would be very convenient, that attack vector is something I cannot accept by default.

So effectively, one of the other hosts stealing stealing your content is one click of a link away. And, downloading through the web interface still seems to be the most common way of using Send.

Maybe there's some good middle ground to not make ffsend too cumbersome to use. One could be a globally configured host, so you only have to set it up once. Another option may be to still include a list of third party hosts with a prompt to warn about the potential security risk.