[HN Gopher] Send: Open-source fork of Firefox Send
___________________________________________________________________
Send: Open-source fork of Firefox Send
Author : leonry
Score : 137 points
Date : 2024-10-19 12:17 UTC (10 hours ago)
(HTM) web link (send.vis.ee)
(TXT) w3m dump (send.vis.ee)
| metadat wrote:
| This is cool, sharing files larger than 1GB still remains
| challenging these days.
|
| How easy is it to self-host? I don't see any Docker instructions.
|
| https://gitlab.com/timvisee/send
|
| P.s. Kind of odd that the site links to Github, but the GH repo
| is only a mirror of the official Gitlab.
| ranger_danger wrote:
| https://github.com/timvisee/send-docker-compose
| Faaak wrote:
| swisstransfer.com, up to 50GB
| rompledorph wrote:
| A minor bug. It's not possible to copy and paste the link from
| the UI. Using Firefox on iPhone
| mlok wrote:
| I wonder what limits sends to 2.5GB ?
| ranger_danger wrote:
| There doesn't appear to be a technical reason, it appears to
| just be a default configuration setting that was a holdover
| from Mozilla's imposed limits when Firefox Send was still
| around.
|
| https://old.reddit.com/r/selfhosted/comments/1bwqxit/is_ther...
| LWIRVoltage wrote:
| There are other variants with different file size limits
| https://github.com/timvisee/send-instances Maybe performance
| based or something depending on those hosting these instances?
| gunalx wrote:
| Exactly what i need to be able to not depend on m0zilla
| deskr wrote:
| As a side note, you can also simulate various network problems in
| the linux kernel via tc: https://www.baeldung.com/linux/network-
| failures-simulation
| Arubis wrote:
| Best of luck to the author! My understanding is that anything
| that makes large file sharing easy and anonymous rapidly gets
| flooded with CSAM and ends up shuttering themselves for the good
| of all. Would love to see a non-invasive yet effective way to
| prevent such an incursion.
| KomoD wrote:
| > ends up shuttering themselves for the good of all
|
| mostly because it's difficult to handle all the abuse reports
| aranelsurion wrote:
| I wonder how that'll play out in this case, since everything
| uploaded here expires at maximum 3 days. Maybe they can
| "handle" abuse reports by simply auto-responding in 3 days
| that it is now removed.
| Vinnl wrote:
| I've been using this version for a while, presumably it's just
| gone under the radar enough. So please don't upvote this too
| much, haha.
| ghostly_s wrote:
| If it's truly e2e how would they even know what's being shared
| on it?
| immibis wrote:
| Because some people would tell them. For example, the FBI
| would look at a child porn sharing forum and observe a lot of
| people sharing Send links. Then they would go to the
| operators of Send servers, and "strongly suggest" that it
| should shut down.
| KomoD wrote:
| > and "strongly suggest" that it should shut down.
|
| I don't know about that, is there any documented case of
| that?
|
| I feel like they'd probably just contact them and ask for
| removal of the file(s) and to forward any logs?
| chasil wrote:
| I have been using both Swisstransfer.com and filetransfer.io
| since Firefox Send shut down.
|
| How have they dealt with this?
| plingbang wrote:
| For a case when file sharing is intended between individuals or
| small groups there's an easy solution:
|
| _Anyone who got the link should be able to delete the file._
|
| This should deter one from using the file sharing tool as free
| hosting for possibly bad content. One can also build a bot that
| deletes every file found on public internet.
| giancarlostoro wrote:
| That then ruins perfectly valid use cases that someone could
| maliciously delete the file for.
| atoav wrote:
| But it allows sending. That might be an okay tradeoff,
| depending on what you're aiming for.
|
| Anonymous file hosting isn't something I'd be keen to
| offer, given the nhmber of people who would happily just
| abuse it.
| ipaddr wrote:
| Or the link expires after a download.
| lovethevoid wrote:
| For Firefox Send, it was actually malware and spearfishing
| attacks that were spread.
|
| The combination of limited file availability (reducing the
| ability to report bad actors), as well as Firefox urls being
| inherently trusted within orgs (bypassing a lot of basic
| email/file filtering/scanning), was the reason it became so
| popular for criminals to use. Like we've seen in the
| spearfishing attacks in India[1].
|
| [1]: https://www.amnesty.org/en/latest/research/2020/06/india-
| hum...
| neilv wrote:
| Do we know whether this uploading is motivated by actual pedo
| reasons, by anti-pedo honeypot reasons, by sociopathic trolling
| reasons, by sabotage reasons (state, or commercial), or
| something else?
|
| It's discouraging to think that privacy&security solutions for
| good people might end up being used primarily by bad people,
| but I don't know whether that's the situation, nor what the
| actual numbers are.
| Barrin92 wrote:
| It is just pedophiles. A user posted here on HN a while ago
| that they ran a Tor exist node and the overwhelming majority
| of it was CSAM or other cybercrime. Here in Germany they
| busted some underground forum and a single individual had
| 35TB worth of it at home. There's no great conspiracy, the
| criminal underworld is huge and they use every service that
| doesn't clamp down on it in some form.
| bachmeier wrote:
| If you don't want to self-host and you don't want to trust
| someone else's service (I don't know anything about this server)
| you get Bitwarden Send with the $10/year premium plan.
| KomoD wrote:
| > and you don't want to trust someone else's service
|
| You still have to trust Bitwarden aka someone else's service?
| jacooper wrote:
| Its e2e encrypted, and the client and server code is open
| source/source available.
| notpushkin wrote:
| This is also end-to-end encrypted, and the client and
| server code is open source/source available.
|
| The reason to use Bitwarden could be that you already trust
| it with something else, and could have taken time and audit
| that it is indeed legit, or trust others to complain loudly
| if they find something wrong with the code. Personally, I'd
| self-host it (or the open source, lighter on resources
| Vaultwarden), just as an additional safeguard.
| hypeatei wrote:
| How can you guarantee the build is from the open source
| code? (i.e. doesn't contain a small patch with hostile
| behavior)
| MatekCopatek wrote:
| I didn't know about Bitwarden Send, thanks! Although I did just
| check it out and it says the limit is 100 MB, which is
| typically too little.
|
| EDIT: I'm on mobile, apparently it's 500 MB on desktop.
| chme wrote:
| There is also filebin.net: https://github.com/espebra/filebin2/
|
| And pwndrop: https://github.com/kgretzky/pwndrop
|
| And lots of others.
| benatkin wrote:
| The title heavily implies that Mozilla's is closed-source. It
| isn't: https://github.com/mozilla/send
|
| Actually since it says forked it implies that Mozilla maintains a
| closed-source version. No, it was cancelled.
| promiseofbeans wrote:
| The Thunderbird team is working on a fork!
|
| "The Thunderbird team was very sad when Firefox Send was shut
| down. Firefox Send made it possible to send large files easily,
| maybe easier than any other tool on the Internet. So we're
| reviving it, but not without some nice improvements.
| Thunderbird Send will not only allow you to send large files
| easily, but our version also encrypts them" -
| https://blog.thunderbird.net/2024/10/thunderbird-annual-repo...
| cpeterso wrote:
| Firefox Send used E2E encryption. The key was generated on
| the web client and not shared with the Send server.
|
| https://web.archive.org/web/20200226024845/https://www.wired.
| ..
| Vinnl wrote:
| That's weird, I thought the original also decrypted them.
| (You pass the key in the hash fragment, which your browser
| doesn't send to the server.)
| benatkin wrote:
| It could incidentally be closed source, then. I stand
| corrected.
|
| Sometimes devs & teams of devs wait until their code is
| finished to put it online. I tend not to - most of my
| unfinished code open source code is online. I understand the
| pros/cons of each way though.
| gpm wrote:
| Slightly off topic: I'm a fan of solutions like
| https://webwormhole.io/ - which lets you send the file directly
| from one computer to the other via webrtc instead of uploading to
| a middleman server... at the expense of not being able to
| generate a link that you can send to someone else and forget
| about.
| blacksmith_tb wrote:
| I am partial to croc[1] which will send directly on your local
| network, or encrypted through a relay across the 'net.
|
| 1: https://github.com/schollz/croc
| KomoD wrote:
| For local transfers (mainly between my phone, pc and laptop)
| I've been using LocalSend, works great.
| CT4u8798 wrote:
| For local network sharing between my devices I tend to use
| LocalSend [0] which is absolutely brilliant, pretty much replaced
| my USB stick for transferring files/folders between devices on
| the same network.
|
| [0] https://localsend.org/
| burcs wrote:
| I recently launched www.64.surf that uses the URL to send files,
| obviously a much smaller file size, but was fun to build
| regardless.
|
| Basically, base64 encode the file, inject it in the URL and then
| allows you to share it with other people.
| NetOpWibby wrote:
| Cloudflare issue when loading the URL
| 0x073 wrote:
| Then you send the file as base64 prefixed with your URL?
|
| Where is the use, except that's cool to build?
| eptcyka wrote:
| If the URL contains the file, what is the difference between
| sending the URL and the actual file contents in practice?
| leonry wrote:
| A command line version by the same author:
| https://github.com/timvisee/ffsend
| deknos wrote:
| Is there a version of this, where i can allow emailadresses to
| upload things/download things/share things with other
| emailaddresses?
|
| Like firefox send but some version of authentication via email? I
| am aware that i would need a way to send emails so the
| emailaddresses get authentication
___________________________________________________________________
(page generated 2024-10-19 23:00 UTC)