Firefox Send file sharing service launches officially
Firefox Send, a file sharing service by Mozilla, maker of Firefox, is now available officially. Mozilla launched Firefox Send as a Test Pilot project in 2017; the first experiment that launched as a web service with accompanying browser extension.
Firefox Send allowed users to upload files to the service so that they could be shared with others. Files would be encrypted automatically by Firefox Send to protect the data from unauthorized access.
Mozilla retired Test Pilot in early 2019 but many of the projects lived on either as browser extensions or as standalone web services.
Firefox Send
Firefox Send is a free file sharing service that anyone may use; a copy of Firefox is not required to use it. Just point any modern web browser to https://send.firefox.com/ to get started.
You may add files with a total size of up to 1 Gigabyte as an unregistered user for sharing. The file size limit increases to 2.5 Gigabytes for registered users. Firefox account owners may sign in using the account, and anyone else may sign up for a Firefox Account to share up to 2.5 Gigabytes and may also manage uploaded files from other devices and change expiration limits. Creation of an account is free; there is no paid version.
You may drag and drop files that you want to share with others on the Firefox Send site or use the upload button to use the file browser to pick files instead.
All selected files are displayed with their name and file size after selection. Firefox Send displays the total file size and options to add more files to the queue.
Uploaded files expire automatically after a set period or a set number of downloads. The default expires them after one download or after the first 24 hours. You may raise the limits to up to 100 downloads or 7 days. Downloads may expire as early as 5 minutes after a successful upload.
Password protection is the only other option provided. Firefox Send uses end-to-end encryption to protect files; adding a password improves the protection further.
Note that some configuration options require a Firefox Account. You need an account if you want to increase the allowed number of downloads or change the time the uploaded files are available. Password protection works without account, though.
Firefox Send displays a link after the upload that you may copy. Firefox Send users without account may terminate the link at any time if they use the same device and don't leave the page that lets them do so.
You still need to share the link somehow if you want others to download the files.
Closing Words
Firefox Send is a useful service to share files. You may use it to share files with others, or upload files for personal use instead. The use of end-to-end encryption and password protection makes the service very useful for that, and the size limit should be fine for most file sharing purposes.
The service is ad-free and free to use for anyone at the time. Preventing unlimited downloads and downloads that don't expire makes the service unattractive for large scale file sharing purposes.
Sören Hentzschel notes that the first beta version of the Firefox Send Android app may be released as early as next week.
Now You: Do you use online services to share files?
“Do you use online services to share files?”
No, I run my own servers to do that.
they’ll make ya Pay for it eventually, you can bet on that
I prefer sharing my files via torrent; you set it as private without any tracker urls, send it to the recipient and give him your ip:port address. Why? Because upload/download can be easily resumed, there’s no middleman and most people know how to use torrents. Nothing is more fun than uploading a 2GB file with 2Mbit/s upload speed and the browser crashes or you lose the connection at 90% completed…yay, let’s try again and waste another 2 hours.
By torrent? What’s the program you use?
Can be any torrent program, i’m using qBittorrent
1. Tools -> Torrent Creator
2. At path, select the file or folder you want to share; Piece size Auto, check all 4 checkboxes, leave all other fields empty
3. Click Create Torrent
4. Send the torrent file to your recipient and give him your ip:port address (port can be found in Tools -> Options -> Connections)
Then:
the recipient needs to open the file, go to Peers tab, right click, select “Add a new peer” and paste your ip:port
If the previous doesn’t work:
the recipient needs to open the file, you go to Peers tab, right click, select “Add a new peer” and paste his ip:port
It works as long as at least one party is connectable…if both are behind NATs/firewalls with closed incoming ports, then it sadly won’t.
Sounds interesting. But several points strike me as ‘curious’.
1. There are quite a number of other, established file sharing products – why the need for another one?
2. Even though the file is encrypted on the local host – who has access to the key? Perhaps encrypting the file before letting Firefox Send encrypt it would suffice?
3. Firefox Send is touted as a ‘free’ service without ads – how can that remain viable? Will it transition to a paid service sometime later? Or will it just disappear?
4. Where and when does the decryption take place? If I send a file to someone it obviously needs to be decrypted for them to use it.
Perhaps I should read up on Firefox send before commenting on it? :)
I did go to the Firefox Github page yesterday and read the Encryption doc.
It looks to me that Mozilla is indeed the warden of the keys. This in and of itself is not necessarily a bad thing but does require a certain degree of trust.
From the doc: “The encrypted data and signing key are uploaded to the server.”
(Regarding Passwords)
“A new signing key is generated via PBKDF2 from the user entered password and the full share url (including secret key fragment).
The new key is sent to the server, authenticated by the owner token.
The server stores the new key and marks the record as needing a password.”
I think there is nothing inherently wrong or ‘insecure’ with how Mozilla is doing this. It’s just not a service to be used for highly sensitive or confidential files. Pretty much just like Dropbox. As long as a user encrypted the data prior to uploading security and privacy will be assured.
ðŸ‘
“It looks to me that Mozilla is indeed the warden of the keys.”
https://github.com/mozilla/send/blob/master/docs/encryption.md
No, only the signing key is uploaded to the server, the file encryption key is not, so the server can’t decrypt the file.
From what I understand : the signing key is known by you and the server and is necessary to prove that you have the file encryption key so that the server accepts to send to you the encrypted file ; the file encryption key is known only by you and never by the server, and can be used to decrypt the file locally.
(Both keys are derived from the secret key which is the part after the # in the address, this one is never sent to the server either)
This two-passwords privacy approach is similar to that of Firefox Sync.
> Vrai said: “1. There are quite a number of other, established file sharing products – why the need for another one?”
Benevolent Provider’s Reasoning: Why let users feed themselves to small shrimps, when big sharks can monopolize the harvest under seemingly different market differentiation & branding ?
> “3. Firefox Send is touted as a ‘free’ service without ads – how can that remain viable? Will it transition to a paid service sometime later? Or will it just disappear?””
Perhaps Firefox Send’s “privacy-focussed” parent-entity gets benefits (monetary & data-sharing) from the the 3rd-party provider ? The latter is known to harvest user analytics for profit. Same way how Gmail, Google Drive, etc. is free.
It’s like how certain people with a saintly “never-done-any-evil” front use others as proxies to do dirty hatchet jobs on their behalf.
https://send.firefox.com/legal
“We use Google Cloud Platform.”
Refer to the above URL for more info on (some of) the kind of data that is collected from users. The option of non-registration & default auto-encryption do not necessarily imply user privacy/ anonymity.
Firefox rewards you with extra gigs of space and multiple uploads in one session if you sign up for a Firefox account. Every browser has a unique account identifier. Your name tagged to the unique account means that they can tie you easily to all of your surfing habits. They will collect your data and monetize this.
@Cigologic
ðŸ‘
About Vrai’s question number 2 :
The problem with web applications with client-side encryption not giving the key to the service is that you have to trust/verify that the code doesn’t send the key, every time you open the page, as opposed to only once if it’s a locally installed software doing it. This is a fundamental weakness in web cryptography. The police could ask them to serve different javascript to your IP for example.
Encrypting files yourself before sending them eliminates the need to trust the server every time but loses the convenience of needing only a browser installed on the machine (and may require a few more clicks). If it’s your machine and you can install what you want on it, it’s safer to do the encryption with a local software rather than in browser.
Would that apply to an encrypted email service such as Tutanota as well ? They claim the encryption is happening on the client. Is there a way to verify that, or do you need to trust them ? (Their client is open source — not the server, though.)
@Clairvaux said;
“Would that apply to an encrypted email service such as Tutanota as well ?”
-Yes
They claim the encryption is happening on the client. Is there a way to verify that,…
-Yes
… or do you need to trust them ?
-Yes
(Their client is open source — not the server, though.)”
There is an element of ‘trust’ with any software you use. Just as IRL we all make decisions every day regarding who to trust (or not).
“Open source” is no guarantee of trustworthiness but it helps a lot.
“Trust but verify”!
“Would that apply to an encrypted email service such as Tutanota as well ? They claim the encryption is happening on the client. Is there a way to verify that, or do you need to trust them ? (Their client is open source — not the server, though.)”
As far as I know, encrypted email services such as Tutanota and Protonmail provide both a free-software installed client and a web site client.
When using the installed client, you only need to verify once (or trust once) that it does what it claims, the one time you install it.
When using the web site client, you need to verify (or trust) it every time you open the page. This problem (and unrelated others) has been analyzed in this research article in the case of Protonmail and does probably apply to Tutanota too :
https://eprint.iacr.org/2018/1121.pdf
In the conclusion :
“With regards to the ProtonMail web application, features such as Subresource Integrity (SRI) could arguably provide some increased authenticity to the code delivery mechanism. However, these features are deemed insufficient for ProtonMail to meet its security goals, and it is our conclusion that no webmail-style application could. Other messaging services, such as WhatsApp and Signal, provide downloadable web applications which run locally on the user’s device and therefore accomplish the same code integrity as ProtonMail’s smartphone applications.
Failing the removal of ProtonMail’s web application, ProtonMail simply should not claim end-to-end encryption except for use cases where both senders and recipients restrict themselves to ProtonMail’s mobile applications.”
Thank you. Regarding the whole Nadim Kobeissi controversy (the paper you provide the link to), Proton Mail has provided a refutation :
https://protonmail.com/blog/cryptographic-architecture-response
The issue is vastly above my expertise level, however I am convinced by Proton Mail’s answer.
In short : part of the issues raised by Kobeissi are disingenuous, and non-problems. They are equivalent to lambasting a lock maker, because if you leave your keys on the lock outside, burglars may come in.
And part of the issues are equivalent to lambasting all lock makers, because, given enough time, appropriate tools and expertise, any lock could be picked open, or the door could be bust open.
So (Kobeissi’s reasoning implies), better not fit a lock to your door at all, if you cannot afford to hire a bunch of private guards to protect your home 24/24 (if you cannot master the horrendous rigmarole that PGP is, even according to its inventor).
@Clairvaux
The part of Nadim Kobeissi’s article I was talking about here is only the “Claim 1” part in Protonmail’s refutation, because Firefox Send has the same (small) problem, I didn’t look seriously at what I called the “other unrelated problems” recently (Claims 2-4) so I can’t discuss them here. Their reply to Claim 1 is, to summarize :
“This issue is not specific to ProtonMail, of course, but applies to any web app in existence today.”
-> Agreed, this is what I said.
“Where we disagree with the author is that we don’t believe the threat model of web apps is so fundamentally flawed that we need to take the step of not offering a web app at all.”
-> I would say that it depends on one’s threat model, for most of people I would agree with that, because better use encrypted webmail with a small weakness than ordinary mail or webmail. But that’s not necessarily true for everybody, I wouldn’t be surprised if that weakness had already been used against selected users after a police request. Sentences like that sound quite suspect :
“Proton Technologies AG decided to comply with the data request, to the extent that it is possible, given our cryptography.” (repeated multiple times)
https://protonmail.com/blog/transparency-report/
“Sentences like that sound quite suspect.”
Of course not. Of course Proton Mail complies with legally valid requests. It’s a legitimate company. Switzerland is not a country where laws are optional. When you run a company, you don’t have the same leeway an anonymous commenter has on the Web. Proton Mail gives the authorities what it has, and what it has is encrypted. That’s what the sentence means.
There hasn’t been any indication, up to now, that the theoretical weakness exposed here has ever been exploited by the police (or anybody else). If and when that happens, it will be time to advise.
Exactly the way some users have decided recently that app-based 2FA is not enough, because it has been breached recently. Note that the breach was executed by an intelligence agency. It’s highly unlikely anyone reading this blog is the target of state intelligence.
And many privacy-oriented companies, Proton Mail and Tutanota among others, are working to correct this potential weakness.
“Proton Mail gives the authorities what it has, and what it has is encrypted. That’s what the sentence means.”
Their sentence does not make it explicit that they did not deliver decrypted content to the police, this is what makes it sound strange. This is how I would phrase it if I didn’t want to lie, but didn’t want to tell the whole embarrassing truth either. You’re just assuming that either the targeted users never used the webmail, or Protonmail did not *really* want to help the police while they could. I’m not assuming the opposite, just saying the opposite is possible and wouldn’t surprise me.
” It’s highly unlikely anyone reading this blog is the target of state intelligence.”
While I don’t know about the anecdote you’re referring to, your statement above is a common misconception about one of the main functions of state intelligence, surveillance of political dissidents, including in so-called western democracies. Have a look at the tip of the iceberg, that was already happening in a western country before the internet era :
https://www.theguardian.com/uk-news/ng-interactive/2018/oct/15/uk-political-groups-spied-on-undercover-police-list
If police spies can go as far as marrying you just because you’re in some anti-fascist or socialist political organization, it’s not too paranoid to think that they have the resources and motivation to do targeted hacking on your computer for the same reason. But I bet you, Clairvaux, are safe.
Paranoid assumptions. Just don’t use Proton Mail (or any other provider, for that matter) and buckle up in a cave.
“But I bet you, Clairvaux, are safe.”
I don’t know what that sneaky innuendo is supposed to mean. I’m only safe because I take the protective measures that are needed, relative to my threat model. Which you don’t need to know about.
Good questions.
1) Trust may play a role.
2) It is a good idea to protect files before you select them, e.g. by encrypting them yourself, if the data is important and should not fall into the wrong hands.
3) No one knows. Disappearance would not be much of a problem considering that you can’t use it to share files forever.
4) Happens in browser as far as I know.
This is good news for me since I don’t have a cloud nor a social account to transfer files. For added security, I would also encrypt the file with VeraCrypt since Firefox may have a backdoor built in for the authorities.
Mozilla has some interesting notes on the privacy implications of its service. In short : files are indeed encrypted, but anonymity is not guaranteed.
I don’t do this sort of thing too much. When I do, use our mailbox.org’s encrypted drive. Same process as FF Send from what I gather.
“You need an account if you want to increase the allowed number of downloads or change the time the uploaded files are available.”
Why? Seems like an unnecessary complication. I do like Firefox Send, though.
Potential reasons:
1) to make abuse more difficult.
2) to push Firefox Account usage.
To provide users with a non-Goowellian account. That is, assuming Mozilla’s motives are decent, ‘pushing Mozilla accounts’ can be seen as encouraging users to adopt a more ethical (he says, ultra tentatively) digital identity provider, albeit a limited one ATM.
Is this not far better than just throwing up a couple of login with Googlian or 1984book buttons?
https://onionshare.org/ TOR file sharing is an good atlernative too with unlimited size of file (but p2p)
I prefer using my personal Nextcloud instance for file sharing.
I don’t get it. How do you ensure that only the intended recipient can decrypt the files (especially since a password is optional) ? How does he download them ? What is encryption without a password ?
Firefox Send uses the Web Crypto API to encrypt files in the local browser. Simply put: encryption is automated. The files get encrypted locally and the URL that points to the uploaded file archive includes authentication information so that the recipient may access it and download the files.
You find information on that here: https://github.com/mozilla/send/blob/master/docs/encryption.md
Thank you. So, if I understand correctly, the key to decryption is the unique url which is only shown to the uploading party. Then the uploader has to send the url to the recipient by any means available (email, encrypted messaging…), and that’s what will enable him to do the downloading.
Optionally, a password could be sent alongside the url.
Or, if you wanted to make the file available to all and sundry, you could obviously plaster the url on your blog.
Yes that is correct.
Firefox Send file sharing service works nicely.
Online services I use to share files are :
Share files – File.io : https://www.file.io/
Share files – Firefox Send : https://send.firefox.com/
Share files – Mon-Partage : https://mon-partage.fr/
Share files – Uguu.se : https://uguu.se/
Share pics – FunkyIMG : http://funkyimg.com/
Share text – Pastebin : https://pastebin.com/
Share text – TextUp : https://textup.fr/
In practice I’ll use essentially ‘Firefox Send’, ‘Mon-Partage’, FunkyIMG and PasteBin.