7 ms·

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/ https://send.vis.ee/

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/ https://send.vis.ee/ Other instances: https://github.com/timvisee/send-instances/ https://github.com/timvisee/send-instances/ A docker-compose template: https://github.com/timvisee/send-docker-compose https://github.com/timvisee/send-docker-compose

alexmcc81 5y ago
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 5y ago
  Yes! Thanks! :)
  - ctde 5y ago
    yes thanks a lot! also retrospectively for implementing basic auth in ffsend!
AdmiralAsshat 5y ago
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 5y ago
  > 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.
SLWW 5y ago
Have you had many issues with abuse? For private instances could there be an option for requiring a login before upload?
- timvisee 5y ago
  > 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.
zie 5y ago
Thanks for maintaining this! I just upgraded our local mozilla copy to your version, works great and was seamless!
alexmcc81 5y ago
Do you have any major new features in mind you would like to implement (assuming you had time + help)?
- timvisee 5y ago
  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
  - StavrosK 5y ago
    Some simple authentication would be fantastic, so I can run my own instance and only allow myself to upload things.
    - timvisee 5y ago
      This can already be done with a reverse proxy and HTTP Basic authentication, but having it built-in would be nicer.
      - StavrosK 5y ago
        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 5y ago
        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.
NortySpock 5y ago
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.
- jclulow 5y ago
  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.
- timvisee 5y ago
  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 5y ago
    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.
newman314 5y ago
Why does it say "We don't recommend using docker-compose for production."? I'd like to understand the reasoning behind this. Thanks.
- timvisee 5y ago
  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#issuecomment-823525647 https://github.com/timvisee/send-docker-compose/issues/3#iss...
antaviana 5y ago
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?
- ev1 5y ago
  #xxxx contents aren't sent to the server at all, if you trust the underlying javascript running in browser.
- timvisee 5y ago
  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_the_firefox_family_and_the_firefox/gois1eq/ https://www.reddit.com/r/firefox/comments/lqegb5/reminder_th... And: https://github.com/timvisee/ffsend#security https://github.com/timvisee/ffsend#security
alert0 5y ago
Thanks for doing this. I used Send regularly and miss it.
Ameo 5y ago
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 5y ago
  > 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/gc.cron 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 5y ago
    Thanks for the quick reply! This makes sense and works fine. Thanks again for the great project
skavi 5y ago
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 5y ago
  Thanks a bunch! That's awesome to read!
StavrosK 5y ago
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 5y ago
@timvisee I have no questions, but just wanted to thank you for your work on this!!! Thank you, thank you, thank you!
- timvisee 5y ago
  :)
andredz 5y ago
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.

alexmcc81 5y ago

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 5y ago
Yes! Thanks! :)
- ctde 5y ago
  yes thanks a lot! also retrospectively for implementing basic auth in ffsend!

AdmiralAsshat 5y ago

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 5y ago
> 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.

SLWW 5y ago

Have you had many issues with abuse? For private instances could there be an option for requiring a login before upload?

timvisee 5y ago
> 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.

zie 5y ago

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

alexmcc81 5y ago

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

timvisee 5y ago
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
- StavrosK 5y ago
  Some simple authentication would be fantastic, so I can run my own instance and only allow myself to upload things.
  - timvisee 5y ago
    This can already be done with a reverse proxy and HTTP Basic authentication, but having it built-in would be nicer.
    - StavrosK 5y ago
      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 5y ago
        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.

NortySpock 5y ago

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.

jclulow 5y ago
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.
timvisee 5y ago
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 5y ago
  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.

newman314 5y ago

Why does it say "We don't recommend using docker-compose for production."? I'd like to understand the reasoning behind this. Thanks.

timvisee 5y ago
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#issuecomment-823525647 https://github.com/timvisee/send-docker-compose/issues/3#iss...

antaviana 5y ago

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?

ev1 5y ago
#xxxx contents aren't sent to the server at all, if you trust the underlying javascript running in browser.
timvisee 5y ago
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_the_firefox_family_and_the_firefox/gois1eq/ https://www.reddit.com/r/firefox/comments/lqegb5/reminder_th... And: https://github.com/timvisee/ffsend#security https://github.com/timvisee/ffsend#security

alert0 5y ago

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

Ameo 5y ago

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 5y ago
> 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/gc.cron 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 5y ago
  Thanks for the quick reply! This makes sense and works fine. Thanks again for the great project

skavi 5y ago

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 5y ago
Thanks a bunch! That's awesome to read!

StavrosK 5y ago

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 5y ago

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

timvisee 5y ago
:)

andredz 5y ago

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.