Add Send (Firefox Send fork) to the File Sharing and Sync Page

Site Development Tool Suggestions
1

Any opinion on Send.vis.ee?

2

I moved this post to its own thread, so that adding Send (which is a fork of Firefox Send) to Privacy Guides can be discussed and evaluated.

Source code:

GitHub - GitHub - timvisee/send: Simple, private file sharing. Mirror of https://gitlab.com/timvisee/send
GitLab - Tim Visée / send · GitLab

Development doesn’t seem to have stagnated.

Feel free to weigh in on this, and we can eventually evaluate it for inclusion.

3 Likes
3

It gets suggested regularly in #main on Matrix, too.

4

Honestly a really great web app and has really good CLI which allows for many integrations.

5

I use it as well occasionally, pretty nice website

6

Ok, ok, I admit, this one is on me. I pushed before anyone had the time to settle this :joy:

9

To be fair, while i like Send as a project, im feeling uneasy to recommend any non official instance.
The reason is that you always have to trust that the instance is not giving you a backdoored implementation.

Even though nothing stops bigger companies from backdooring it, they have a reputation to uphold. Random instances can be created and disappear overnight with your data.

2 Likes
10

If we were to recommend Send, we would recommend the software, and at most, we’d offer an instance list, just like we do for projects like Invidious, Piped and Nitter. We cannot make that decision for people.

Though it is definitely something to consider because unlike the aforementioned projects, you’re trust a Send instance with potentially sensitive data.

This is why I think we really need to be careful before recommending projects like these to ensure that the software itself is sound.

11

@matchboxbananasynergy it is encrypted locally so why do you believe it receives sensitive information? One could always use the CLI to be 100% sure the code run is original.

12

The problem is that folks will just load the page which can include the backdoored version of the code. This is a problem with all web based cryptography, which is why folks should try to use fixed clients where possible. No normal user is gonna check the code during normal usage, nor do most folks even know what to look for.

Now a big company like Mozilla would get into trouble if it were found out, but some random instance someone popped up can disappear overnight without any trace left.

1 Like
13

I completely understand that Send is end-to-end encrypted. However, there are two concerns to consider here:

  1. The instance issue that @Niek-de-Wilde mentioned. (Again, we wouldn’t be recommending a specific instance).
  2. Do we know whether Send is sound with regards to how it handles files since the fork? I’m sure the developer that’s maintaining it is very capable, but we can’t take the fact that this used to be a Mozilla product as face value, as a lot of changes have been made since then.

Ideally someone who can take a look at relevant part of the codes could help us evaluate and ensure that all is well.

Also, sidenote, and a question to people who want to see us add this:

Would you want us to list Send (along with an instance list), as well as ffsend (the CLI tool)?

14

I agree with you both. Web-based clients can pose additional risk. But I would say that if you trust the author of the fork you probably trust their web based instance too. I would say it’s probably best to only list their instance and mention other instances exist but you will have to trust them.
I would definitely mention the ffsend cli, that inherently is more secure but it is probably best to also list the web version as this is far more convenient for most.

I have pretty actively followed the development since the fork, surely could have missed something but I didn’t spot any suspicious changes.

Would definitely good if more people would have a look at it here:

1 Like
15

After further deliberation, Send and ffsend as a CLI tool look like a project that we’d like to add to the File Sharing and Sync page.

If anybody has any lingering arguments as to why we should or shouldn’t add it, please let us know. Any information to help us finalize our evaluation is very much appreciated!

3 Likes
16

One minor objection, I like Send but I don’t think you can add it in isolation without comparing it to direct competitors such as:

  • Snapdrop - GH
  • Securedrop - GH
  • And even GSConnect/KDE Connect for direct file transfer (Linux only) - GL 1, GL 2
17

Thank you for your reply.

Feel free to correct me if I’m wrong, but I don’t believe that the projects you mentioned fulfill the same use-case that Send does.

  1. Snapdrop

We have looked at and rejected this project before as it doesn’t seem to be as mature as we’d want it to be, and looking at its issue tracker didn’t inspire too much confidence.

However, even if it was a choice we could recommend, it doesn’t fulfill the same niche as I think (and correct me if I’m wrong here), Snapdrop is a tool for transferring files in your local network, not outside of it.

  1. The same goes for KDE Connect/GSConnect.

  2. Securedrop can be used to send files over the network, however it requires a very specific and elaborate setup, while Send is an easy way to share files with a friend, for example, in a way that’s safe and end-to-end encrypted.

1 Like
18

You’re right, ‘direct competitors’ was the wrong phrasing from me.

  • Snapdrop has the largest following, 13k GH stars, and thus it should be mentioned, if only to say why not to use it. Otherwise this app will be asked about again and again “Why Send and not Snapdrop”. Snapdrop gets a lot of mention on other forums from what I’ve seen. If PGs goal is to be a source of truth in the community then ‘ruling out’ options is just as valuable as including them and strengthens your argument for an app, in my opinion.
  • Shouldnt tools for transferring files using the local network also be added to that page? Yes not a direct competitor but it’s a separate use case to be explored. Especially if your threat model is such that you do not connect usb devices to your laptop and would prefer a quicker solution than encrypting, uploading to the cloud and re-downloading again on the other device.
  • You’re right, not a direct competitor for this use case, but highly relevant to those with the right threat model and thus should also be explored in my opinion.

My underlying point is if you include only Send people with differing threat models or use cases may see it as ‘The’ tool to use, when in fact other tools may fit their threat models more.

Apologies for not being more clear or being a little pedantic.

20

Do you folks believe that we should list Send and ffsend in separate cards, or should we list Send and mention ffsend within that card?

On one hand, we could list ffsend under a “Command-line tools” category, but it sounds silly when you think about the fact that it’s the same thing. It would be the same as listing Onionshare and Onionshare-CLI separately.

Thoughts?

21

I believe the correct way to format this would be one section with Send in a card:

Send is a fork of Mozilla’s discontinued Firefox Send service which allows you to send encrypted files to other users. Files are encrypted so that the server cannot read them, and they can be optionally password-protected as well. The maintainer of Send hosts a public instance, you can use any other public instance, or you can host Send yourself.

and then below the card (just as a plain paragraph) say something like:

Send can be used via its web interface or via ffsend, a command-line client. If you are familiar with the command-line and send files frequently, we recommend using the native client to avoid JavaScript-based encryption. You can specify the --host flag to use a specific server:

ffsend upload --host https://send.vis.ee/ FILE
3 Likes
22

Yes i think both in seperate cards would be a good idea imo like @jonah suggested

1 Like