Hacker News new | past | comments | ask | show | jobs | submit login

I've used Firefox Send for several months while it was still a test pilot program. It's been very useful for quickly sending files to family. The fact that the link expires as soon as the other party downloads it means I don't have to worry about clean up.



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.


To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it automatically expires!"), and checked again a few hours later to find it gone.


> To my knowledge, the link is only invalidated if the person actually downloads the file.

I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.


Which is why you put a trivial password on the file, which isn't included as part of the link.

Then, any automated system which sees the link cannot accidentally cause the file to be "downloaded" which would cause the link to be invalidated. They can see the link itself, but they don't have the password, therefore they can't download the content to scan it.

I have used onetimesecret.com a number of times in this way.


The easy solution is for the link to lead to an interstitial that shows "do you want to view the content? It will be the only time you can do so.", and make the underlying HTTP resource unpredictable (e.g. different ID to the link) so that it cannot be directly addressed.

It's a very common and easy to anticipate issue, I'm surprised that there are any one-time-link services left that suffer from it.


What if the download was interrupted because, e.g. the other person had a temporary issue in their internet connection? Does the server at least detect that the entire file has been sent over the socket? Does the server at least check that, on a TCP level, receive all the ACK packets it is meant to receive? Of course this still isn't foolproof but it's a good way towards detecting interrupted downloads.


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


No one I've tried it with has ever had it fail on them.

But to answer your question, I uploaded a 100mb+ file to FireFox Send, copied the link, RDPd into another computer, kicked off the download, and then cancelled it midway through download. The link did expire after that.

So I guess they don't have an easy way of telling whether the download is successful or not. Maybe Mozilla's engineers can figure something out if the issue is raised.


If they did, you could abuse it by just trasfering every byte except the last, add that in a custom link to complete the file transfer and have unlimited distribution ;) I think it's best the way they did it.


I appreciate you took the time to run a test to answer my question. Thank you.

Firefox might consider keying off the initial IP seen upon retrieval and extending the TTL of the object until the final byte has been retrieved.


I can see benefits to keying off the IP, but also to keying off some cookie that can expire shortly. One of the reasons I imagine a download might fail could be because of a spotty of problematic VPN or proxy, or attempting to get it from a location that can't handle it well if somewhat large (some random coffee shop wifi that's overused).

There's probably enough complexity and possibility for abuse in allowing automated requests for files again (i.e. a button on the view page) or special logic for second attempts that the safest option is just to have the receiving party ask for the file again through whatever medium originally kicked off the request (an email, an IM, etc).

Firefox could do any number of things to make it easier on the user, but I expect them to take my security and privacy very seriously and to error on the side of those ideas rather than usability, so hopefully if they come out with something it's not at odds with those goals.


Did you test to see if the download could be resumed?

In an ideal world, partially-downloading the file would expire the link, but the server would still allow the file download to be resumed (but not restarted).


If you are worried about it you can specify the number of downloads before expiration




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: