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
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?
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.
I'd like to understand the reasoning behind this. Thanks.
Someone asked this before, here is my answer (bottom quote): https://github.com/timvisee/send-docker-compose/issues/3#iss...
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.
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.
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.
For private instances could there be an option for requiring a login before upload?
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.
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
Maybe adding HTTP basic auth is fine, as I mainly want to keep random bots from finding the service. I'll try that, thanks!
I have not seen any bots on my public instance by the way. It has been running for more than a year.
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...