Firefox Send: Free encrypted file transfer service (opens in new tab)

FWIW, I built and successfully ran it on FreeBSD-current. The only hiccup I ran into was that it puked building due to not having /usr/local/lib in its lib search path & not being able to find libxcb. I had to manually add -L/usr/local/lib to the cc args and manually link it. Not sure if that is a FreeBSD issue w/Rust, or something in your package.

At any rate, the tool works! Thanks so much.

Python cli version at https://github.com/ehuggett/send-cli

disclaimer: I haven't used either cli version.

Love the demonstration on the Github page!

This is great, thanks :)

Mind if I port this to JS?

Thanks a lot. The first thought after seeing this was that I wish it had a CLI and I know I am lazy enough to never write one.

do I need install firefox to use this tool? looks neat!

This is such a fantastic tool to have, thank you so much!

This is neat, thanks.

Some of those points are relevant and some aren't. For logging in to a website, "just use SSL/TLS instead" makes sense, but not for this use case. There's better options nowadays for doing crypto in the browser, but I wouldn't be surprised if they were at least theoretically vulnerable to side channel attacks from JS running in another tab.

The main thing is that unless you're paying really really close attention to the JS that you're executing, you can't trust this any more than you can trust Mozilla and the security of whatever computer is serving their pages. I wouldn't use this for sending data that you're trying to hide from a nation-state, but it looks like a great option if you want to send a video to your grandma without posting it publicly on the internet or teaching her how to use GPG.

It's not outdated; it remains fundamentally true. But I'm uncomfortable with people calling it a "legendary rant" because it was dashed off and I never promoted it as any kind of last word on the subject. There are better arguments against browser cryptography than mine.

In particular: you'd hope that WebCrypto would have changed things a bit, but, of course, it doesn't: it leaves all the cryptographic joinery up to content-controlled code. You're probably somewhat less likely to have side-channel flaws if you use it, but in reality timing side-channels are more talked about than seen. Who would bother, when they can just deliver a script that exfiltrates secrets directly?

SubtleCrypto is a new browser-adopted spec for performing crypto operations natively. For example, instead of using Math.random() for random number generation, you can use https://developer.mozilla.org/en-US/docs/Web/API/Crypto/getR... in combination with the SubtleCrypto functions to work with keys securely

Your points around a compromised JS bundle are still possible but that has more to do with a company’s deployment/change management setup than JS itself imo

That article primarily comes down to this:

> WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you can safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.

In our case we aren't doing crypto inception where the cryptography is meant to secure itself. The crypto is being served securely (by ssl) and then used to solve the separate unrelated crypto problem of encrypting random files.

Fundamentally the situation has not changed much. You redownload the code every time and servers could deliver tailored compromised versions if ordered so by some TLA. Which means audits have limited values since they can't attest that what they have seen is actually what anyone gets.

Compare with native tools which you only download once, can check its signatures and which strive for reproducible builds so that multiple parties can verify them independently.

There was also a time just a few years ago when evangelists claimed JS/CS/etc. were just as fast as native (some said faster) and blasted you for suggesting otherwise, even when it was clear as daylight this was blatantly false. This mantra also suddenly just faded away once native compilers for these gained popularity. I guess reality hits you after some time.

Now I see a similar issue with security experts preaching that merely possessing a single piece of software with a single thing they classify as a 'vulnerability' implies you will be murdered within the next 24 hours, and it seems they'll happily DoS your computer, get you fired from your job, take your second newborn, and blow up your computer in your face if that's what it will take to make you finally feel real danger. Not sure why it takes people so long to see that reality isn't black-and-white, but better late (hopefully) than never.

There are many use cases where compromise through code-interdiction after warrant is a perfectly acceptable risk. Also considering what it replaces may further increase the weight of privacy gain. Absolutism is definitely not the way to go, and looking at the state of the tech community (eg. npm, apt, pip, pacman, check that sha256 sum) we left the design-it-right-first a long time ago. A valid argument, though I wouldn't defend it to the death, is that we need to work slowly back toward more secure behaviors rather than chasing absolutely secure technologies. I think send.firefox is a step back from dropbox for some.

SSL isn't the only crypto you'd ever want to do though. What if you want encrypt data so that it is encrypted all the way through the layers of the application to the database? That's a valid use case to use in tandem with SSL. Also I have to mention cryptocurrencies.

As long as there is a possibility, I say yes - not "if" but "when."

Humans are always the weakest link with the internet and someday, sometime, bad code (unknowingly) will be pushed and something will happen to someone.

Couldn't they do the same If crypto code was on server?

Seems like Send would have to be a built in browser functionality or maybe a plugin.

Not relevant to me as all of my sites are entirely secured with SSL.

boop: https://github.com/mozilla/send

Anybody have a nice docker version to run this at home?

Do you ever run into a problem when an overzealous email service or virus scanner pre-fetches the link and invalidates it before an actual person clicks on it? This used to happen with all sorts of links in emails, though I haven't heard about it in a while.

Does the link expire after a successful transfer? Curious what happens if the transfer fails mid transfer and needs a retry.

You should be able to whitelist https://send.firefox.com/ with the "Manage Permissions..." button right next to that option.

I block _all_ cookies except for a small list of sites (like HN...).

This is a current Firefox restriction: https://bugzilla.mozilla.org/show_bug.cgi?id=1413615

Along the same lines, a Gmail-esque Thunderbird web service would be amazing. I could finally de-google myself completely if that were the case.

Currently, I need to set up my own email hosting through a service like fastmail and then configure a desktop client(like Thuderbird) to use it.

A Mozilla Gmail-esque service would remove a lot of the friction there and probably bring in a bunch of users who are tired of google running everything.

You may be right, but I hate it. There is no reason I can think of to have all these tools integrated into a web browser, and the idea of having the Internet broken into silos based on your choice of browsers scares me.

We don't need another AOL Chrome.

Literally all they need to do is advertise tree style tabs. It's the reason half my office stopped using Chrome.

> By providing "extra" services attached to the Mozilla and Firefox brand

How is that different from the complaints people make about Chrome tightly integrating with Google?

> If Mozilla comes with Send, Notes, Password Manager all integrated in Firefox i see a good way to bring back some of the previous users that switched to Chrome

As a Chrome user I can confirm. But for me the main raison I use Chrome is for the dev tools a found them better than FF

The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is never sent to the remote server. Only people having the URL including the secret will be able to download and decrypt your shared file. See https://github.com/mozilla/send/blob/master/docs/encryption....

Generated by random and applied to the URL hash data that is not sent to the server. Hash data is data in an URL after the hashtag

It seems vulnerable to an active MitM - if the attacker is in a position to serve malicious JS that exfiltrates the data from window.location.hash.

I think the scheme is fairly robust against passive interception though.

I have no clue why you would suggest a tool that requires using a linux command line after telling firefox send doesn’t meet the needs of non-techical person.

>pip install --user pipe && pipe install magic-wormhole

What am I looking at here? On PyPI 'pipe' is listed as a "Module enablig a sh like infix syntax (using pipes)", and magic-wormhole's own docs just say to install with pip like anything else.

I remember elementaryOS had a GUI for this in its app store. Never got around to try it, Linux is not well known in the consumer world, let alone Elementary

First off, Mozilla believes in the service. Mozilla itself gets funding from donations and corporate backing (I think). The cost of bandwidth is small compared to other file share sites in that the files stored are temporary. The transient nature of the files means that the max storage space needed is relative to the concurrent number of users. Bandwidth also. That means sans a very clever DDoS their expenses should be manageable compared to say Google Drive, Dropbox, or MS One Drive.

I remember sending a signed PDF via Firefox Send and was at first horrified when I realized I couldn't get the file back after 24 hours but then relieved knowing that the recipient got it and then it disappeared from the internet. Very cool!

If they can't keep up, at least we'll always have the code: https://github.com/mozilla/send

I don't understand how they can afford the bandwidth...

If this were on AWS it would be around $0.09 per GB for downloads.

Read here for the why: https://github.com/mozilla/send/blob/master/docs/metrics.md

We'll find out by the end of the year »

Secondary - In support of Revenue KPI

We believe that a privacy respecting service accessible beyond the reach of Firefox will provide a valuable platform to research, communicate with, and market to conscious choosers we have traditionally found hard to reach.

We will know this to be true when we can conduct six research tasks (surveys, A/B tests, fake doors, etc) in support of premium services KPIs in the first six months after launch.

https://github.com/mozilla/send/blob/master/docs/metrics.md

Presumably Mozilla, just like they do for the sync and Web Push servers.

mozilla

Oh interesting. Their two hypotheses (which they will test) are that Send "can drive Firefox Accounts beyond the Firefox Browser" and that it will "will provide a valuable platform to research, communicate with, and market to conscious choosers..."

It sounds like they're investigating a premium service offering targeted at privacy conscious users. (The secondary hypothesis covers "revenue" and will be tested by conducting "research tasks ... in support of premium services KPIs.")

It's because this blog is for mainstream audiences who don't know what GitHub is and might be scared of all that code-y stuff if they accidentally clicked on it.

Wow that's really neat. Downside is it only works while the page stays open on the uploader's machine, while send.firefox.org uploads the file for a limited time to a central server so you can close the tab before the recipient downloads it.

> Anyone who obtains the link (e.g. via email interception) gains access to the file.

True, but, if a third party decides to use the intercepted link to download the file, and you have it set to a limit of 1 download, the file will self-destruct (if you trust Mozilla). This way, the recipient can know that someone has tampered with the communication, which is certainly an improvement over the status quo (email attachments).

The files are available up until they have been downloaded (from 1 to 100 times) or until a certain timeframe has elapsed (from 5 minutes to 7 days). See the screenshot at the article.

2.5GB file limit is a bit small for good quality TV shows (and especially movies).

Glad you like it (I worked on it). Just a side note, the cloud service will be going away in the future, but the ability to save it locally will remain.

Based on what I've read, the security model seems to be almost the same as email attachments?

The same reason it's Chromecast, not Googlecast.[1] Branding.

[1] The protocol is named Google Cast, but all the consumer branding is Chromecast.

I was confused too. When it worked on non Firefox browser it was a pleasant surprise. I'm guessing this is just to promote Firefox browser. Wouldn't surprise me if they added higher file limit after usage grows and with it a paid tier :)

IIRC The link contains an anchor `#abc123` which is the decryption key. Browsers do not send anchor parts of the URL to the server, and so the browser decrypts.

Hinges on the browsers never sending that key, though.

Client side JavaScript that encrypts locally befor uploading and puts the encryption key in the url you share with someone that never gets sent to Mozilla. Also client side decryption on the person you shared the link with. It’s end to end.

The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files.

If you want, you can also set a passphrase on the file to share via another channel

> How do they pay for the storage costs?

Using their revenue from search, like everything else they pay for.

> What's the upside for Mozilla?

"Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent."

Upside is that this is another reason to get a Mozilla account.

Google Search, Yahoo Search.

WebRTC and privacy don't exactly go together well.

Maybe they just don’t need too much storage since they expire quickly. This would be an interesting thing to graph, if they release the statistics.

Mozilla has quite a bit of money, most of it from their default search engine deals. I'd wager to guess that most of it goes to wages.

Yes. Tested on Chrome, Safari, and Edge.

The page states that it'll be available on all browsers and a android app is going to be released later this week.

Regarding the differences, this website does not seem to encrypt the files on the server, and does not provide links directly, so you need to provide at least one valid email address, if only to send the link to you to then send it to the party you want to share the file(s) with. It's also not open-source AFAICT.

I've tested this and the link seems to expire the moment the user starts a download.

Why have a file transfer for imp docs when you can have a single authoritative source of truth for those docs, along with version history and who changed what.

So why not just use Google Drive (or dropbox)?

I feel with features like secure file sharing (though only with other ppl with google accounts), reasonably good security[1] and Inactive Account Manager[2] it should work for legal docs. Especially considering Google is going to be around for a while.

I would rather use a Mozilla offering but they don't really have too many things for regular consumers outside of firefox and send.

[1]: https://myaccount.google.com/security [2]: https://support.google.com/accounts/answer/3036546?hl=en

Generate a temporary link that, when clicked sends an event to your system to deprecate the link and redirect the user to a presigned S3 download. In my case the file attachment was the product and it was important the system know when someone had downloaded, but a backend system that keeps temporary urls and requests a temporary download link from the file provider is a useful pattern. Nice thing about signed links is your server doesn't have to handle the file - it's between the client and storage provider.

The data that's synced when you log in is also encrypted, with a unique key derived from your Firefox Account called a scoped encryption key. Your key changes when you change your password. We, (Mozilla) don't know your key (and don't want to know it). Disclosure, I implemented the sync feature of Send.

True, without the email. Actually, I like we transfer for sending emails and notifications when the user has downloaded the attachments.

See https://github.com/mozilla/send/

most abuse mitigated by their limits on the number of downloads allowed and how many days it can stay online. Currently at 7 days max and 100 downloads. If they see abuse they could reduce this further.

about revenue, there are so many valuable directions this can go. It could undercut competitors in ways they cannot sufficiently respond to. (google responding in kind would leave them less reason to not add encrypted storage for drive) By stabilizing this platform they can start to build new privacy-enhancing apps on top. Calendar, contacts, etc. With more dependency on the platform, they will find areas where more storage, longer retention, will be income generating.

privacy may be the only frontier that can displace google,apple,microsoft.

Storage is extremely cheap. Especially for a service like Send which doesn't hold any data for a long period of time.

Elseways, It might be that they have bigger plans with it. This might be just a product to learn about market potentials.

Mozilla's manifesto is all about the Internet and Internet privacy. File sharing is one of the areas where the internet is losing privacy.

There's also a http://xkcd949.com/

Wouldn't you need both clients to be online at the same time to do that?

Looks like www.send.firefox.com was a mistake. It's not a valid way to access the service. The correct url is send.firefox.com.

Because some people just don't recognize a Web address if it does not start with www. I see that all the time with our subdomains.

You came up with a web service that lets anyone upload something and then download it via /uploads/123?

That's basically a hello world project. As you found out, the hard part is everything else, like funding it.

The end to end encryption necessitates a hard to remember uri anyway, so I don't think you can have both "secure" and "memorable".

Encrypting it with a random key that doesn't get sent to the server, but is in the URI that the user sends to the receiver means that only the sender and receiver know what the file actually contains. Means neither you nor law enforcement can know what you are storing unless the URI is captured.

Hah, found a record of the project (we did it at HackTX): http://techzette.com/2013-hacktx-winners-and-finalists/

It was called "Catch"

If you're still interested in this type of tool, I'm sure Mozilla would welcome your contribution: https://github.com/mozilla/send

A short PIN seems nice for personal use (maybe on a self-hosted service) but wouldn't a short PIN allow people to potentially guess random PINs and download files that they shouldn't have access to?

They did. But it didn't work with NAT so it died.

P2P means both machines must be able to talk to each other (occasionally difficult when both are behind NAT) and must be turned on at the same time. Using a reliable intermediary gives some flexibility.

Since it's encrypted end to end, presumably they will be oblivious to all that stuff?

The same way backup services and email servers deal with encrypted data. They have no way of knowing.

The file is decrypted in client-side JavaScript so presumably no

While I'm not sure if this is a reason not to use Chrome (you can use it in Chrome as well), trying Firefox is really just a couple of minutes work, and you can easily go back...

Here, I'll type the download link for you: https://firefox.com

I don't understand what you're asking. The use case is literally in the title ("file transfer").

There is end-to-end encryption, so unless they have homomorphic virus scanners I don't see how they would do this...

At maximum 200 downloads and an expiration of 7 days I don't think anyone will bother to be honest.

The encrypted file is stored in the cloud. The recipient downloads it from there and decrypts it.

P2P would be much better, but this isn't that.

They key is appended to the URL as a hash, which cannot be read by the server.

I recently switched back to iOS after years on Android, and on this point I've been very impressed with Airdrop. Dead simple UI, very quick transfer speeds, uses WiFi or Bluetooth as available. It's just a shame that it's limited to Apple devices.

What about https://syncthing.net/?

EDIT: I know you said without going through the internet. Syncthing can be configured to only transfer over specific networks (e.g. home LAN/WI-FI)

>I can't believe that there isn't a simple service to transfer data between my cellphone and my computer without going through the internet.

KDE Connect, https://community.kde.org/KDEConnect#What_is_KDE_Connect.3F i've been using it for years

A number of Android File Managers these days (Amaze comes to mind) include a toggle option to turn your phone into an FTP Server. You would then just pull it up on your computer via ftp://192.168.X.X and put an optional user/pass over it. I've used that for many years if I need to quickly transfer some documents or songs between devices.

Not technically internet so much as intranet.

Resilio sync [1] is a great service I've used to transfer files using P2P technology. It still uses the Internet, but avoids any intervening parties.

If you're using Android, you could just use USB transfer using Android File Transfer [2]. Super easy, super fast.

[1] https://www.resilio.com/individuals/ [2] https://www.android.com/filetransfer/

KDE connect works without internet access. I haven't used it on Windows, but it works fine for me on Ubuntu.

If you use Apple devices, it's called AirDrop and works surprisingly well. I use it a lot, between computers, phones, and ipads, within the family and sometimes with other people, too.

Does local wifi count? I use KDE Connect for sending files over wifi and a bunch of other things.

You may also want to check Syncthing, which others have also recommended.

I just use iCloud Drive. Files on my desktop and in my documents folder get automatically synced to my phone and vice versa. It's extremely easy and painless. I often find myself on my phone, saving a file to my iCloud desktop, and finding the file on my desktop the next time I open the lid of my laptop.

Tangentially related - I've always thought it's dumb that I can't just plug my iPhone in to any PC and have it show up as a removable storage device.

I'm sure people who know more than me will give me a list of great reasons why it's not straightforward to implement...

But it doesn't change the fact that I have this incredible device (iPhone X) with 256gb of blindingly fast NAND flash storage, of which I am only utilizing 30gb, yet I still have to tote around a f*ing stupid little plastic USB dongle if I want to copy some files around.

Besides AirDrop there is "Copy and Paste across devices" https://support.apple.com/kb/ph25168?locale=en_US

AirDroid is pretty handy on Android; file transfer, browsing your phone's files/images, sending SMS from your desktop browser (although Messages now does that native) etc. Much to my surprise, there's also an iOS version - https://itunes.apple.com/app/id1194539178

SMB over local network would be my default, I recall an app for using SMB with Android back as far as the 2.x days.

We have tons of protocols for transferring files over networks, there's no reason for them to go to the public Internet, nor for them to be mobile phone specific.

If you use GNOME, GSConnect is magical.

https://github.com/andyholmes/gnome-shell-extension-gsconnec...

In the Apple ecosystem, there's AirDrop which uses either Bluetooth or Wifi. You can quickly share files between any iOS and Mac devices very simply.

There is. It's called dukto (http://www.msec.it/blog/?page_id=11), and works on mac, linux, windows and android. It will use zeroconf to automatically find all duktos on the local network, and let you send stuff to them in a blink.

Proprietary but free as in beer.

You didn't say whether you are on iOS or Android, but if you are on iOS airdrop works very well.

You might be interested in KDE Connect, which provides (among other things) essentially a thin wrapper around SSHFS. It's the most convenient method of computer<->phone transfer I've found.

What I'd like to see is an app that runs a webserver on my phone to share a slideshow of pictures or videos to a browser on the lan. I haven't found this and I'm thinking about writing one.

Check out https://github.com/claudiodangelis/qr-filetransfer for computers and phones on the same LAN.

Works great, and I'm planning on integrating that functionality into my project which transfers files between laptops using only wireless cards, no LAN required. https://github.com/spieglt/flyingcarpet

I use Syncthing, personally. It usually works pretty great, the only real issues I've seen are with locked down internet connections (the sort which also seem to meter or block VPNs).

"I can't believe that there isn't a simple service to transfer data between my cellphone and my computer without going through the internet."

The correct way to do this is to configure your phone to emulate USB mass storage and then connect with a USB cable.

Your phone looks like a thumb drive. It's the easiest workflow in the world.

Unfortunately, this workflow is off limits because of some licensing requirement from MS for fat32 (or something) which is why neither android nor ios has this very basic, simple feature.