Saw this?

[gautamkrishnar]

Mozilla is testing a new and convenient file sharing service for users of any modern browser, including rivals Chrome, Internet Explorer, Edge, Opera and Safari. “Send,” as the service is called, promises to allow users to securely swap files, rendering the download link invalid after the first download is completed.

With a seemingly dim 7% market share, Firefox is one of the most widely-used web browsers, trailing only Chrome and Internet Explorer, and occupying a comfortable 3rd spot in the desktop segment, ahead of Opera, Edge, and other browsers. That keeps Mozilla busy building exciting new features for its user base, including one recent file-sharing service called “Send.”

A test pilot program, Send hopes to become a one-stop-shop for swapping files no larger than 1GB, conveniently and, more importantly, securely between users of “any modern web browser.”

Send promises to:

encrypt the uploaded file
generate a unique URL that expires after the recipient completes the download
render the link invalid if 24 hours have passed without anyone downloading the file
“Send lets you upload and encrypt large files (up to 1GB) to share online,” Mozilla says in a recent Test Pilot post. “When you upload a file, Send creates a link to pass along to whoever you want. Each link created by Send will expire after 1 download or 24 hours, and all sent files will be automatically deleted from the Send server.”

While convenient, Send throws in the decryption key with the download, which means the service is not immune to man-in-the-middle (MITM) attacks.

“You should not provide the link to anyone you do not want to have access to your encrypted file,” Mozilla warns.

A quick in-house test conducted at the time of writing suggests that the one-download rule can be broken if two different users access the link at the same time. Our test indicates it takes more than a few seconds for the servers to be notified that the first download has completed, especially in the case of a large file. This would allow a third party to download the same file, provided they had access to the link at around the same time.

Mozilla labels Send a “web experiment,” and users should take those words to heart. Send offers an admittedly seamless experience with its authentication-free, drag-and drop functionality. However, for the time being, the service should only be used to share non-sensitive information with trusty recipients using trusty communication services. Send does not seem suited for business use, sharing corporate data, or for communicating sensitive information of any kind. Not yet, anyway.

Link: https://hotforsecurity.bitdefender.com/blog/be-careful-using-mozillas-new-file-sharing-service-send-18630.html

[gautamkrishnar]

I think we must add some user agent/IP based security to prevent multiple users from downloading the same file.

[ehuggett]

Its not clear if this would work for send...

Can we unlink (delete) the file once the download starts (instead of after it has finished), the process reading the file might not be affected at all depending upon the backend used for storage, this would help avoid any unnecessary retention of metadata (IP addresses etc, even for short periods of time).

This "trick" is used by flash player (etc) to make it harder to keep copies of videos it is buffering to a temp folder, it unlinks the tmp file before writing any data to it (but you can of course still find a reference to the deleted file in /proc/flash-pid/fd/ ) but it might not be possible with a remote storage backend (perhaps we could delete the reference from the fileid to where the data is stored instead? etc)

[dannycoates]

The problem with sharing the link over an insecure channel is that we (the service) can't tell the difference between the intended recipient and any unintended ones, so it becomes a race. I wrote up a quick gist as I was reasoning through this, here

TLDR; We are working on designing a UX for setting a password/PIN in #381.

[gautamkrishnar]

@dannycoates really happy to know that 😄

[ehuggett]

Hmm, my previous suggestion would cause the file to be lost if the download is interrupted, which i didn't consider, and i can see people having an issue with for it being "too paranoid", but at the same time, how often will this actually happen? (especially for smaller files).

I would like to convince you otherwise about option Y from your Gist.

• If John does not click download before someone else does most of the time, as small files are nearly instant, its going to be outcome 3 anyway.
• If the link is stolen i think Send MUST alert John to this somehow (so he can tell you) without also telling "Others" that the file ever existed, and we can't tell John and "others" apart.
• Update the "This link has expired or never existed in the first place!" error page to something like "This link has expired, never existed in the first place or has already been used" (unless someone has a better idea on how to give a warning with plausible deniability?)
• You can always upload the file again to send it to John if this hopefully very rare event occurs
• Files are only downloadable once by design, if they can be downloaded twice then: Its not a feature its a bug (as opposed to the uploader being able to specify the max no. of downloads, which would be a feature)
• Finally, The user is responsible for the security of the link (id,key) and potentially the password, if all of them are compromised there is nothing we can do (because as you say, we don't/can't know) but we do know something is wrong when we receive the second request (as we've previously told them it can only be downloaded once) so we MUST do something so i don't think this allows outcome 3 to be avoided.

I quite like the analogy of the file being "stolen" being reinforced by John not being able to download the file, as i hope it would cause you and john to worry about who now has that photo as if you were right the media will go wild over it and cause more of the doubters to denounce bigfoot 😄 when they discover it was a another hoax.

I prefer option Y to option X because we can't easily "lock" the download to the same person, a single IP can "represent" a lot of people (NAT on business/home networks and especially with carrier grade NAT, ie Mobile phone networks) and trying to do anything more specific (ie IP + HTTP User Agent, 'download session' tokens in LocalStorage/cookies/etc) requires logging (or at least storing) more data server-side than we need to (if the inconvenience of failed downloads can be accepted, any statistics on this?).

That said, option X if used with token in a cookie with a short expiry time (perhaps set it based on the filesize assuming a slow download) would at least only be short lived identifier and it would even allow John time to reboot his computer and try again (but he must use the same browser)

edit: (in future) should i comment on the gist instead to avoid clutter in the issue for this kind of comment?

[dannycoates]

should i comment on the gist instead to avoid clutter in the issue?

issue comments are fine (and appreciated) @ehuggett 😄

[ghost]

The password mentioned above should help address this.