Send: A Fork of Mozilla's Firefox Send (opens in new tab)

We recently made a one-line change that massively reduced GPU usage, specifically:

- Intel integrated graphics: 60% reduction

- AMD Radeon: 40% reduction

- Apple M1: 10% reduction

What was the change? We removed "opacity: 85%" from the <canvas> element. We were using opacity to slightly darken the animation but now we just darken the texture image directly.

You can "hide" it with uBlock Origin by blocking large media elements in the popup.

100% agree - I've used Wormhole a few times when I try to quickly get data into interactive VM sessions, because it works great otherwise, but the graphics consistently grind the whole thing to a halt.

I really don't get the reasoning. It looks kind of cool, but it makes it super unusable for a bunch of use cases from very old computers to interactive sessions on raspberry pis to constrained VMs. And those are exactly the kind of places where I want friendly easy tools to copy files across for quick system admin or to get logs back out! Doesn't seem like a good tradeoff.

Set webgl.disabled to true if you're using Firefox.

And if you have a sucky connection, it's slow has hell to load.

Turn on "reduced motion" setting on your Mac.

Wouldn’t it be easier for you to manage what you expend your battery on?

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).

Seems very similar to 'hyp beam': https://github.com/hypercore-protocol/cli

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.

Is that using WebRTC, or are they hosting the files on their backend?

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.

I swear I've tried it several times over several years. I've never gotten it to work.

Yes! Thanks! :)

> 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.

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...

> 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.

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.

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.

> 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.

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

Thanks a bunch! That's awesome to read!

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

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

:)

The README on the repo itself links to gitlab, including the "create an issue" link: https://github.com/ClearURLs/Addon/#contribute

Yes, the problem is that it's "not micro enough". The value of this service is low enough that it's not worth it for me to self-host, and the financial overhead of cloud providers is enough that it would cost far more for me to spin up a dedicated instance than pay someone for the fractional cost of usage of their instance.

More generally, I want the ability to make microtransactions (substitute "extremely low-friction donations" if you will) for everything that could be "free" but also costs money (bandwidth, compute, storage), because no matter how much free time I have, there will always be services that I could benefit from, but are low-enough-value that it's not worth it for me to self-host or get a cloud host myself.

Probably more related to financial security...

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.

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.

they have a public instance... and just like Mozilla's version you can self-host... but either way we need more services like this.

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?

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.

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.

The other option too would be just to clone the repo locally and use grep, find, etc. That seems the simpler option if you just want to perform a search.

Yeah, those files are for https://projectfluent.org/

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.

So fixed right?

It would be nice to set arbitrary (or at least Bearer) Auth tokens too in case you put it behind some oauth enforcing gateway like authelia

Can't any cloud storage service be used to deliver malware?