[timvisee]

Maintainer here, thanks for posting!

Feel free to ask any questions.

Want to try it out? I've a public instance at: https://send.vis.ee/

Other instances: https://github.com/timvisee/send-instances/

A docker-compose template: https://github.com/timvisee/send-docker-compose

[alexmcc81]

I was wondering why I recognised your name - you're the main developer of ffsend. Thanks for all the work! I really hope you get more people interested in maintaining and developing Send.

[timvisee]

Yes! Thanks! :)

[ctde]

yes thanks a lot! also retrospectively for implementing basic auth in ffsend!

[Ameo]

Hey - love this project! I was able to get an instance deployed with Nginx reverse proxy without too much trouble. Password encryption doesn't seem to be working, but that might be some weird header issue thing with the reverse proxy setup and I'm not too worried about it.

One thing I was wondering is if/how expired files are cleaned up. I uploaded a large file, set it to expire after 5 minutes, and although I can't download it anymore I see that it's still in the files directory on my server.

I glanced through the code, but I didn't see any mechanism for periodically purging expired files or anything like that. Is there something that I missed, or should I just set up a cron job or something to delete all files in that directory older than a week?

[timvisee]

> but I didn't see any mechanism for periodically purging expired files or anything like that. (...) should I just set up a cron job or something to delete all files in that directory older than a week?

You're right. Expired files that don't reach their download limit are kept on the server. Due to implementation details there is no 'nice' way to do this from Send itself. If using S3 as storage you can configure a LifeCycle Policy, if using raw disk storage you can set up a cron.

See an example here: https://github.com/timvisee/send-docker-compose/blob/master/...

All uploaded files have a prefixed number which defines the lifetime in days (e.g.: `7-abcdefg` for 7 days expiry). So you can be a little smarter with cleaning up.

I should describe this clearly in documentation.

[Ameo]

Thanks for the quick reply! This makes sense and works fine. Thanks again for the great project

[newman314]

Why does it say "We don't recommend using docker-compose for production."?

I'd like to understand the reasoning behind this. Thanks.

[timvisee]

Good question. I don't have very good reasoning for it, and I haven't put it there. I might need to remove it.

Someone asked this before, here is my answer (bottom quote): https://github.com/timvisee/send-docker-compose/issues/3#iss...

[AdmiralAsshat]

What level of logging/privacy can we expect from a self-hosted instance? I had faith in Mozilla's commitment to privacy, but I don't necessarily trust some random dude's AWS instance.

[timvisee]

> What level of logging/privacy can we expect from a self-hosted instance?

It really depends on who is hosting it.

Send itself doesn't really log anything except for errors. A reverse proxy in front of it might be used for an access log, which is default with the docker-compose template for it. Files are always encrypted on the client, and it or its keys are never seen on the server.

If you're wondering for the instance I've linked: it runs on Digital Ocean. I have an access log (IP per request, for 24h), I can list encrypted blobs and their metadata (creation time, size), and that's pretty much it.

[NortySpock]

Naïve question here, but is there a config setting that would work without HTTPS?

I run a home server just for internal use and it might be nice to send files via a link for memes, jokes, quick one-shot uses rather than storing it on a samba share, etc, but it doesn't have a public-facing URL for confirming a LetsEncrypt certificate.

[timvisee]

If you really don't want to use a certificate, just configure the base URL to be a http: address. That should work fine! Feel free to open an issue otherwise.

[tialaramex]

Note that if you do this, rather than actually setting up HTTPS, outside of Send itself a bunch of stuff becomes impossible (you presumably don't want to do any of this stuff, but if you ever do try it just won't work) because you lack Secure Context, and gradually over time you can expect more errors and problems.

Already if you give me a plaintext HTTP link I'm going to have to consciously decide that's fine and click past the interstitial warning me it wasn't able to be upgraded to HTTPS, if you use it to inject an image somewhere that's otherwise HTTPS, the image just counts as broken unless I go out of my way to authorise it.

[jclulow]

You could self-sign a certificate, or if your internal URLs use a subdomain of a public domain you control you could use DNS challenges for Let's Encrypt.

[SLWW]

Have you had many issues with abuse?

For private instances could there be an option for requiring a login before upload?

[timvisee]

> Have you had many issues with abuse?

In the last year, I've had 1 DMCA request. And I've blocked one IP that was uploading half a terabyte.

> For private instances could there be an option for requiring a login before upload?

Not built-in, right now. But you can easily set up HTTP Basic Auth on a reverse proxy that you put in front of it.

[alexmcc81]

Do you have any major new features in mind you would like to implement (assuming you had time + help)?

[timvisee]

I don't have anything planned.

But with infinite time, I'd:

- add some form of authentication, to limit uploads for example

- add a way to preview files on the Send page itself

- provide integrations with other platforms

- resolve outstanding issues

[stavros]

Some simple authentication would be fantastic, so I can run my own instance and only allow myself to upload things.

[timvisee]

This can already be done with a reverse proxy and HTTP Basic authentication, but having it built-in would be nicer.

[stavros]

But then I'd have to give the password to anyone I wanted to receive files. I want to be able to send files to people but not have them be able to send to others.

Maybe adding HTTP basic auth is fine, as I mainly want to keep random bots from finding the service. I'll try that, thanks!

[timvisee]

You can exclusively configure it on the upload page. It's not super nice, but it works.

I have not seen any bots on my public instance by the way. It has been running for more than a year.

[skavi]

I was wondering where I had seen your name before, and then after scrolling through your GitHub, I realized it was your Advent of Code 2020 solutions in Rust. Those were absolutely beautiful.

[timvisee]

Thanks a bunch! That's awesome to read!

[antaviana]

How is end-to-end encryption achieved? By storing the password in the URL and not logging the URL when the file is fetched at the receiving end?

[timvisee]

Encryption is done with JavaScript on the client. The decryption key is attached as hash to the download URL on the client side as well.

When visiting the URL, the key never reaches the server because the hash-part of an URL is never sent and is a local-only thing. So there's no need to strip logging. The client downloads the encrypted blob, and decrypts it on the client.

More info: https://www.reddit.com/r/firefox/comments/lqegb5/reminder_th...

And: https://github.com/timvisee/ffsend#security

[ev1]

#xxxx contents aren't sent to the server at all, if you trust the underlying javascript running in browser.

[andredz]

You are welcome (poster here :-)). And thanks to you for maintaining a great, and useful, piece of software. I recently needed something like Firefox Send that could have files uploaded for longer than 1 day but no more than 7 days and Send (and your public instance) was perfect for such task.

[zie]

Thanks for maintaining this! I just upgraded our local mozilla copy to your version, works great and was seamless!

[carom]

Thanks for doing this. I used Send regularly and miss it.

[stavros]

This is fantastic, well done! A very useful service, and I loved it when it was Firefox Send. I'll be sure to use this now.

[mxuribe]

@timvisee I have no questions, but just wanted to thank you for your work on this!!! Thank you, thank you, thank you!

[timvisee]

:)