1. 55

Try it out at: https://send.firefox.com/

  1.  

  2. 26

    I’ve been building a fully featured CLI tool for Firefox Send, supporting this new release.

    For anyone that is interested: https://github.com/timvisee/ffsend

    1. 9

      Magic Wormhole works pretty well for some overlapping use cases. Differences from Firefox Send:

      • Synchronous (sender waits for transfer)
      • Data is never stored on 3rd-party server
      • No URLs, just pronounceable short codes
      • Both parties need to install a Python package
      1. 4

        file.pizza is similar, but uses webrtc and works in the browser, so you could realistically use it with non-technical users.

      2. 8

        I just tried uploading a 350MB file as a test, and it looks like it doesn’t generate your unique URL for copy/pasting until it’s done. I remember ge.tt years ago would change the location bar almost immediately to the unique URL, and if someone else loaded the page while you were still uploading they still got a “please wait” page (or did it allow partial/streaming downloads? I forget). I’m always surprised when I don’t see similar functionality on file sharing sites these days. Is there some technical reason Mozilla avoided it here?

        1. 8

          I don’t know the real technical reason.

          What I do know, is that the service currently only responds with the actual share URL after you’ve fully uploaded your file (it isn’t the interface holding it back). The actual share entry is probably only created when it has confirmed your upload didn’t fail. The fact that Amazon object storage is used probably also plays a role. The share URL contains a share ID and secret. The secret is generated by the client, and known before hand.

          So, the method of encryption isn’t the problem here. I think the method of storage, and wanting reliable uploads resulted in this decision.

        2. 5

          I trust Mozilla so I will take them at their word that the file is being encrypted end-to-end. (And I know I could go read the code.) But can there be a way for a lay user to see that a file is actually encrypted? A user can compare a visual hash of the entire contents of the file. But how can they know it’s strong encryption? Perhaps we need to move the E2E support to the browser or the OS.

          1. 19

            I can confirm that they do (as I’ve been reversing it to build ffsend). The file content, along with additional metadata is encrypted on the client. The hash part of a share URL contains the secret required to decrypt a file, and is thus never sent to the remote server. They’re currently using 128-bit AES-GCM along with some derived keys using HKDF SHA-256, as described here, so decide for yourself.

            1. 5

              Cool, thanks for the info! I never doubted that, but I’m just thinking out loud about ways we can make this obvious to non-technical users (something like the green lock in the URL bar.)

              1. 4

                It’s actually really funny how close this is to a project I wrote on a weekend a few years back at my first security company. The main difference was mine was focused on text oriented blobs instead of files, so I didn’t do metadata: https://blacknote.aerstone.com/

                I also used NaCL instead of relying on AES-GCM. My testing also made me hyper skeptical about JavaScript random number generation, to this day I’m not certain how to solve that problems and still highly suggest that people steer clear of JavaScript for high entropy needs.

                1. 4

                  Any idea why it’s 128-bit? I thought FF had 256-bit.

                  1. 3

                    I think this (and the following comments) answer it: mozilla/send/issues/86

                    1. 4

                      That a weak argument. Looking at big picture, though, the kind of folks that will be able to break the crypto can already afford 0-days from brokers to hack those Firefox users. So, probably not that important.

                      1. 3

                        It’s a horrible argument. There is very little difference to the developers to choose the stronger ciphers, especially since it is using the client for encryption. When I did this I just used NaCL and stuck to actually ya know…. listening to cryptographers. I really don’t understand why you wouldn’t select the more forwardly secure option.

                        1. 2

                          The only times it makes sense to go weaker by default are legacy (no choice) and resource-constrained microcontrollers (also no choice). This shit is running on desktops that routinely do 256-bit crypto. No excuse.

                          They so need to remember other developers might imitate whst popular projects do. Gitta set a good example with good defaults.

              2. 5

                This is VERY cool. Countless people I know have gone through the hassle of signing up for Dropbox when what they really wanted was to be able to send files.

                1. 3

                  I feel like I’ve been using this for at least a year, is it really actually new? Or did it just go from open beta to stable release?

                  1. 2

                    The user experience is the same. The internals have changed.

                  2. 3

                    Very interesting to see an alternative to WeTransfer that is hopefully less shady!

                    1. 3

                      Wonder if it would be worth offering paid subscriptions as well for larger files.

                      1. 2

                        How does this work if Skype snoops on the URL as you share it?

                        1. 3

                          Anyone having the full URL will be able to download the file as long as it’s available. Thus, if a Skype employee, or someone else manages to obtain the URL they’ll be able to download. You can set an additional password though, which you share through a different channel making the URL useless without it.

                          1. 4

                            I think Vaelatern might be referring to the habit that Skype et al. have of issuing a HEAD/GET for every URL in every message, for their “link preview” features. This probably doesn’t affect Mozilla Send though, as the shared URL is for an HTML document which contains the real download link, right?

                            1. 4

                              My bad! Nope, that doesn’t affect it at all. You have to explicitly click a download button on the share page. Only when the file is fully downloaded the download counter decreases.

                        2. 2

                          Standard question: Is there a WebRTC p2p alternative that doesn’t require a server?

                          1. 3

                            Yes file.pizza, although you still need the server to connect the two peers together.

                            1. 2

                              A huge thanks to WebTorrent which we use for the file transfers under the hood.

                              Interesting.