[HN Gopher] Send: A Fork of Mozilla's Firefox Send
___________________________________________________________________
Send: A Fork of Mozilla's Firefox Send
Author : andredz
Score : 374 points
Date : 2021-05-05 17:25 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hojjat12000 wrote:
| Naive question: The github page says 62% of the languages used in
| this repo is FreeMarker. I checked the repo and every file I look
| at is js, what and where is FreeMarker?
| timvisee wrote:
| I don't know. Have been asking myself the same question the
| past month.
| TheDong wrote:
| I think it's the locale files, like this one: https://github.
| com/timvisee/send/blob/master/public/locales/...
|
| If you look at github/linguist, that's what recognizes
| languages in repos. It has this rule for FreeMarker: https://
| github.com/github/linguist/blob/32ec19c013a7f81ffaee...
|
| It seems a .ftl extension means FreeMarker to linguist, so
| those localizations show up as such.
| timvisee wrote:
| It should be excluded from the stats as it's marked as
| documentation though:
| https://github.com/timvisee/send/blob/master/.gitattributes
| TheDong wrote:
| It shouldn't be excluded because that pattern doesn't
| match any of the files.
|
| If you run `git check-attr --all
| public/locales/foo/send.ftl` with the current .gitattr
| file, you'll get no attributes.
|
| If you update the attr match to `public/locales/**` or
| `public/locales/**/*.ftl`, then the `check-attr` command
| above will match it and show 'linguist-documentation'.
| niea_11 wrote:
| I think this has something to do with the repo being a
| fork.
|
| The parent repo doesn't have this issue. The "languages"
| list doesn't mention Freemarker on
| https://github.com/mozilla/send
| chungy wrote:
| GitHub's language "detection" is ridiculously naive and
| basically limited to examining file names only, not content.
| niea_11 wrote:
| I can't find any freemarker templates on the project, but
| apparently it's using i18n files with an ".ftl" extension which
| is the default extension for freemarker templates.
|
| Ex:
| https://github.com/timvisee/send/blob/master/public/locales/...
| sciurus wrote:
| Yeah, those files are for https://projectfluent.org/
| tym0 wrote:
| Is there a way to use ffsend if I drop some basic auth in front
| of the upload?
| timvisee wrote:
| Yes! `ffsend upload --basic-auth USER:PASS FILE`
| voiper1 wrote:
| I'm liking croc with a CLI on each end.
| psanford wrote:
| croc just had multiple major vulnerabilities discovered that
| required protocol breaking changes to fix:
| https://redrocket.club/posts/croc/
| andredz wrote:
| There's also a CLI for Send (ffsend):
| https://github.com/timvisee/ffsend
| SubiculumCode wrote:
| I'd like to set this up one up of my own servers...
| fouric wrote:
| This is excellent! I've been missing Firefox Send ever since they
| took it down.
|
| However, it needs to be hosted somewhere.
|
| ...and if I'm going to be using a hosted service, I'd like the
| ability to easily pay for it (so that it doesn't eventually
| collapse or resort to shady things like ads), either though
| donations or microtransactions for bandwidth/storage.
|
| Unfortunately, there's no good microtransaction service.
|
| Wasn't Mozilla working on one? Where did that go?
|
| ...and thus, we've gone full circle.
|
| And I'm typing this comment in a Chrome browser, because my
| company is migrating away from Firefox due to "security issues".
| timvisee wrote:
| This is a comment for my instance specifically, but you might
| find it nice to know:
|
| The https://send.vis.ee/ is mostly funded by donations right
| now. I do not plan to take it down, unless the cost becomes a
| problem. I'll never resort to ads.
|
| If this ever happens, I'll likely show a warning beforehand.
| Some time later I'll disable the upload page, and will take the
| rest of it down the week after. Files have a maximum lifetime
| of a week anyway. So if you discover this when uploading, you
| can simply switch to some other service. Existing links should
| not break.
|
| There's a donation link on the bottom of the page
| (https://vis.ee/donate). But feel free to use it without a
| contribution.
| cassepipe wrote:
| Oh, I forgot about that one. Yet another Mozilla project that
| worked well that was abandoned. (Remember Firefox OS?
| https://killedbymozilla.com/) I know what you're thinking : They
| did not abandon Rust ! Well I just learned from a post that
| recently made it to the HN front page that management was
| considering dropping Rust. The only reason they did not was
| because of someone who fought hard for it.
| dralley wrote:
| It wasn't "abandoned" it was shut down because it was being
| used by malicious parties to deliver malware, and worse.
| timvisee wrote:
| 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
| StavrosK wrote:
| 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.
| AdmiralAsshat wrote:
| 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 wrote:
| > 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.
| alexmcc81 wrote:
| 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 wrote:
| Yes! Thanks! :)
| ctde wrote:
| yes thanks a lot! also retrospectively for implementing
| basic auth in ffsend!
| newman314 wrote:
| Why does it say "We don't recommend using docker-compose for
| production."?
|
| I'd like to understand the reasoning behind this. Thanks.
| timvisee wrote:
| 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...
| alert0 wrote:
| Thanks for doing this. I used Send regularly and miss it.
| zie wrote:
| Thanks for maintaining this! I just upgraded our local mozilla
| copy to your version, works great and was seamless!
| skavi wrote:
| 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 wrote:
| Thanks a bunch! That's awesome to read!
| antaviana wrote:
| 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 wrote:
| #xxxx contents aren't sent to the server at all, if you trust
| the underlying javascript running in browser.
| timvisee wrote:
| 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/r
| eminder_th...
|
| And: https://github.com/timvisee/ffsend#security
| alexmcc81 wrote:
| Do you have any major new features in mind you would like to
| implement (assuming you had time + help)?
| timvisee wrote:
| 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 wrote:
| Some simple authentication would be fantastic, so I can run
| my own instance and only allow myself to upload things.
| timvisee wrote:
| This can already be done with a reverse proxy and HTTP
| Basic authentication, but having it built-in would be
| nicer.
| StavrosK wrote:
| 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 wrote:
| 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 wrote:
| Naive 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 wrote:
| 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.
| jclulow wrote:
| 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.
| Ameo wrote:
| 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 wrote:
| > 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 wrote:
| Thanks for the quick reply! This makes sense and works
| fine. Thanks again for the great project
| SLWW wrote:
| Have you had many issues with abuse?
|
| For private instances could there be an option for requiring a
| login before upload?
| timvisee wrote:
| > 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.
| neodymiumphish wrote:
| I know everybody's posting tons of alternatives already, but I'm
| curious why https://transfer.sh isn't included. It has very
| simple instructions for encrypting against a recipient's Keybase
| GPG key, works from the site or command line, and has 14 days of
| retention.
|
| Just curious, since I keep seeing Wormhome mentioned, but I never
| seem to see anyone mention Transfer (unless it's just a lesser
| known option and I happened to hear of it early).
| Black101 wrote:
| Best HN post in months...
| matham wrote:
| Do you know what led Mozilla to stop this experiment (I'm
| assuming spam)? Will this not be an issue for your instances as
| well?
| gsich wrote:
| Storage in S3 is not cheap.
| timvisee wrote:
| They said they stopped due to spam, but there might be more to
| it because they also had quite a lot of layoffs that period. I
| don't know.
|
| I can imagine spam being a problem with such a service with a
| well recognized brand name.
| IainIreland wrote:
| The announcement is here: https://support.mozilla.org/en-
| US/kb/what-happened-firefox-s...
|
| Quick summary: it was being used for malware and phishing,
| aggravated by the trustworthy-seeming firefox.com URL.
| simias wrote:
| I think the shifting "product focus" is probably the main
| factor here, simply because such a service being used for
| malware hosting was completely predictable from day 1. When
| they started they probably thought that it was worth it, then
| later on they changed their mind. That or they were
| incredibly naive.
| itake wrote:
| This is self-hosted, so probably easier to apply security
| through obscurity.
| redkoala wrote:
| That means no security at all. Without a way to link files
| being hosted to identity or inspecting the contents of the
| files, there is no barrier to prevent spam and illegal files
| from being hosted.
| Black101 wrote:
| they have a public instance... and just like Mozilla's
| version you can self-host... but either way we need more
| services like this.
| TedDoesntTalk wrote:
| > we need more services like this
|
| I don't know. The internet had hundreds of file sharing
| sites at one point. They all suffered fates similar to the
| epic MegaUpload although with not as colorful founders as
| Kim DotCom.
|
| I don't see how having them again would be different than
| last time?
|
| https://en.m.wikipedia.org/wiki/Megaupload
| rany_ wrote:
| > They all suffered fates similar to the epic MegaUpload
| although with not as colorful founders as Kim DotCom
|
| Well it doesn't matter as much in this case because
| "Send" is a temporary file host.
| Jhsto wrote:
| After trying all these WebRTC options and the NAT traversal
| service (STUN, iirc) always being down, I ended up using IPFS
| instead. With public gateways from CloudFlare it is very easy to
| effectively drag and drop files and have them accessible via the
| IPFS-to-HTTPs gateway.
| TedDoesntTalk wrote:
| Doesn't IPFS have problems with persistence? IOW you can't
| guarantee a file will be available?
| nkellenicki wrote:
| As long as you keep your node up and running your content
| will never disappear. So if you just want to share files with
| friends I can see this working well - just keep your node
| available.
| Jhsto wrote:
| There's two persistence types: pinned and unpinned files.
| Pinned files persist, but someone needs to seed them at least
| occasionally. Unpinned files get eventually garbage
| collected. If you want to share a file, you don't need to pin
| it if the recipient for example tells you when the download
| is complete. In this sense, all these WebRTC examples are
| more equivalent to unpinned files.
| dennis-tra wrote:
| https://share.ipfs.io/#/ is also very convenient for simple p2p
| file transfers.
| iagovar wrote:
| How does this work. Does the file need to pass through a
| server before reaching the other end? or is it streaming
| directly between sender and receiver?
|
| Also, does it need to put the whole file in RAM first?
| dennis-tra wrote:
| There is a server involved for mediating peer discovery but
| the file transfer itself is p2p.
|
| Regarding your second point: I'm actually not sure if the
| file is copied into memory or if the browser just keeps a
| reference. I haven't tried it with large files yet.
| livre wrote:
| For the rare times I have to do this I run a local server and
| the free version of CloudFlare argo tunnel. It provides an
| https url so the upload/download is safe from ISP snooping,
| there are also no size limits, you can send a 30GB file if you
| need to do that.
|
| https://blog.cloudflare.com/a-free-argo-tunnel-for-your-next...
| kickscondor wrote:
| Some other WebRTC file transfer options:
|
| * https://wormhole.app/ (my recent fave, by creator of
| WebTorrent, holds for 24h, https://instant.io by same)
|
| * https://file.pizza/ (p2p, nothing stored)
|
| * https://webwormhole.io/ (same, but has a cli)
|
| * https://www.sharedrop.io/ (same, does qr codes)
|
| * https://justbeamit.com/ (same, expires in 10 minutes)
|
| * https://send.vis.ee (hosted version of this code)
|
| * https://send.tresorit.com/ (not p2p, 5 GB limit, encrypted)
|
| I track these tools here: https://href.cool/Web/Participate/
| dschep wrote:
| There's also https://snapdrop.net which seems extremely similar
| to sharedrop.io but has an additional useful feature of letting
| you send messages which I sometimes use to send links to
| devices that aren't logged into any service.
| kickscondor wrote:
| Ah neat! I've added all of the links in the comments here to
| my list - great to see what's out there and to combine our
| collections.
| fckthisguy wrote:
| As I recall, there's a difference between file.pizza and
| webwormhole. file.pizza allows the sender to specify files and
| then generates a share url, whereas webwormhole creates a share
| link first. The latter can be useful if you're not sure exactly
| what you'll send before you share the link.
| iagovar wrote:
| Hmmm, it seems like https://webwormhole.io/ has changed from
| last time I used it. https://wormhole.app/ seems more similar
| to what I remembered as frontend.
|
| I remember trying many of those services and I decided to use
| this one because I could send large files without any problem
| (was trying to move sqlite dbs that were several Gbs, as it
| seemed to stream the file instead of trying to store it on ram
| first, but now I see wormhole.app allows up to 10GB, and I
| don't remember to have any limit.
|
| WebRTC services seem to have problems to get up to speed, but
| for streaming files between devices it seems the best solution
| in terms of friction.
| lxgr wrote:
| The speed problems interestingly seem to be caused by a bug
| in an implementation of SCTP used by most (all?) WebRTC
| browser implementations:
|
| https://github.com/saljam/webwormhole/issues/55
|
| The symptom seems to be that the SCTP data rate drops with
| increasing latency (which used to be a problem with very old
| TCP implementations too, but all modern ones handle high-
| latency networks much better).
| dennis-tra wrote:
| I've also built a file transfer tool (CLI) with emphasis on
| decentralization. It's a fully decentralized p2p file transfer
| tool based on libp2p:
|
| https://github.com/dennis-tra/pcp
|
| I'm currently trying to make it interoperable with
| https://share.ipfs.io/#/ which resembles the functionality of
| the posted tool.
| kickscondor wrote:
| Seems very similar to 'hyp beam':
| https://github.com/hypercore-protocol/cli
| Ansil849 wrote:
| > I track these tools
|
| How frequently do you validate that they are still functional?
|
| I tried File Pizza several months ago, and neither I nor the
| recipient could get it to work.
| kickscondor wrote:
| Links are checked at least once daily - I do have a few that
| are recently broken that I need to address - but File.pizza
| is okay again. I have switched the main link to Wormhole,
| because it's now my preferred option - and because File.pizza
| has been up and down for me in the past as well.
| Ansil849 wrote:
| The website is up - the actual transfer service no longer
| seems to function in modern browsers. Have you (or anyone)
| had a successful transfer via File Pizza recently?
| tyingq wrote:
| Just tried with a tiny file, it tries to work, as I can
| see the filename/size on the receiver end. But, it never
| downloads. It does say "Peers: 0, Up: 0, Down: 0".
| kickscondor wrote:
| Ok - I see. I suppose I will need to find a way to verify
| some of these links a bit deeper. Thank you for doing the
| footwork on this!
| seriousquestion wrote:
| Thanks, useful site!
| elliebike wrote:
| I'm a fan of Kipp! Not p2p, but has optional encryption
|
| https://kipp.6f.io/
| fljsdflsdfjdslf wrote:
| Missing https://dropbox.com/transfer
| ehsankia wrote:
| Is that using WebRTC, or are they hosting the files on their
| backend?
| ctpide wrote:
| We build a web app for e2ee file transfer:
|
| https://arcano.app
___________________________________________________________________
(page generated 2021-05-05 23:00 UTC)