Extend download beyond 24hrs or 1st download?

[klint]

I understand there must be limit for security or resource management reasons, but 24 hours and one download only seems really too short to me.
In my own experience, even the current limit of wetransfer is almost too short actually! I may use my smartphone whole day long, but some files will be downloaded on a specific computer only, which I may not visit often enough: I maybe using a my work computer whole day long as well, but the policy there prohibits to download anything :)
Because of the current limit, and for that reason only, I won't be able to use Send, I'm sorry. I don't want to reload the file because the recipient misses the window.

[LuFlo]

You can actually change the time on your own, see server configuration file:
send/server/config.js
I think "expire_seconds" is the parameter you are searching for :-)

[Lxxyx]

Same problem. How to download file multiple times.

[ehuggett]

Increasing both would make Send more susceptible to the issues https://mega.nz/takedown "have to deal with", they can cover their legal costs with the fee's they charge.

I am not a lawyer, but I think the short expiry may be important in avoiding the need to process take-down notices and the single download limit makes it redundant anyway, How can you claim in good faith (encrypted) data the service is storing infringes upon your copyright(etc) without actually downloading it to confirm this (thus destroying the data Send stores, taking it down anyway)

(personal opinion) To try and make a very fine distinction, if you want both a longer (or no) expiry and multiple downloads, I would suggest your use case may require a file hosting service such as MEGA rather than a file transfer service such as Send

There is already an open issue for multiple downloads #98

[klint]

I agree that the legal aspect is one of the reasons. But as you say, both restrictions taken together are redundant in a way.
In my opinion, having a greater time slot to proceed to download is more important than allowing multiple downloads, in order to have a 'send' feature that is really usable but that is not a 'store and make it available for everybody for a while' feature.

[ehuggett]

I also call the combination very effective in the linked issue, it is only redundant if everyone sees the futility of demanding content be taken down that will be deleted within 24 hours anyway (which they could delete themselves, by downloading it) as they do have a legal right to make such a demand.

I also think we both know there will be some copyright holders don't have the same standard for "good faith" as the rest of us there are many circumstances where they might have at least reasonable suspicion from the context they find the link in (even if i would never submit anything myself under penalty of perjury/etc that i had not reviewed carefully).

Part of my point was that even if any takedown notice is received (not just copyright infringement), the file being deleted within 24 hours (most likely much shorter by the time any such notice is received) might be enough to fulfil the legal responsibilities without even needing anybody on-call capable of determining their validity.

Its also relevant to bring up the design goal of the server and its operator not be able to access the stored data is going to make it quite difficult to prevent service abuse in the future. Many of the "options" available to (plaintext) filehosts to combat abuse are simply not available to us here and much of what is left risks incorrectly classifying (and blocking) legitimate usage (i.e a single IP address may represent 1 person or theoretically millions of households, welcome to the internat btw) or impacts the user experience in ways that makes it very difficult to ensure Send is as accessible as possible (captcha's are very problematic or even impossible for some people, even with audio options)

Even if Mozilla is not put a legal risk from it Send being associated with the actions of such abusers could do significant harm to its reputation and Mozilla's (/the Firefox brand).

A personal concern of mine is the service becoming "suitable" or "ideal" for distributing malware via spam
messages

• Send is an attractive service to abuse, due to the potential for bypassing some layers of an organisations security model. For example a mail servers (AV Scanning, URI DNSBL's) and inspection by https proxies (it could be done, but i suspect they would just block Send if we became a problem which is also undesirable for us)
• Hopefully most spam messages are not opened within 24 hours
• Most recipients of a spam message are not tricked by them
• This means a sender of such messages is strongly motivated to include the malicious content in such a way that will at least "probably work" for at least a couple of days (sending the same link to multiple recipients will "probably work" as most of them will be spam-filtered or deleted manually by a user)
• The point is, If half of the recipients they manage to 'trick' don't click the link for >24 hours then they won't consider send "suitable" as they are only getting half of what is hopefully a very low return rate anyway

I can't think how to make Send suitable for sending a file to someone who is not expecting it, if not actually waiting for it, without opening the service to this kind of abuse (but i can think of ways of potentially getting a new link without uploading it again)
An obvious difference between Mega and Send is we don't require an account, which makes abuse even harder to control.

edit: An obvious difference between Mega and Send is we don't require an account, and i think that's desirable, which makes abuse even harder to control.

[johngruen]

We've added this to our prioritization, and it seems important. Will have a spec for this feature soon.

[youwenliang]

@johngruen Implementation-wise are we going to change the shared url if a user changes the expiration or the download times? And do we need a confirmation once a user sets the expiration?

[crocodanser]

Some news ?

[johngruen]

@youwenliang dusting this off since we are about to land the password thing:

• No the URL would not change AFAIK
• Some kind of passive confirmation notice would be good. I don't think the user would need to submit anything here.

@crocodanser sorry our lead engineer has been on a much needed holiday! we're on it :)

[youwenliang]

@johngruen
Here's a quick idea Peko created, only one dropdown for download times and users can pick from 1 to 10 or unlimited times:

Any thoughts? We should probably also show the number of download times left for receivers when they open the link.

[dannycoates]

I like how this looks, but I'm dreading implementing it...

Putting number variables in sentences makes localization more difficult (nevermind having controls in the strings). Fluent has selectors but I'm not sure pontoon supports them. Does it @flodolo?

If there was a way we could do it that didn't mix the strings with controls it would be easier to implement.

[flodolo]

Yes, Pontoon supports plural forms (Screenshots is already using them).

[johngruen]

@dannycoates @youwenliang i dig the UI,

let's ditch unlimited tho and do the following:
1-10, 25 and 50.

[johngruen]

@youwenliang also WRT timing, i think the same style control could work maybe?

[youwenliang]

@johngruen yes the same style should work. What would be the options by the way? Did we get requests for shorter expiration time or longer?

[DRN88]

May I ask what's the up to date status of the multidownload "feature"? Thanks.

[dannycoates]

@DRN88 multidownload is in development right now and should be released before the new year.

[dannycoates]

multiple downloads is now live on https://send.firefox.com v2.2.2