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

I've just checked the code. It indeed deletes the file once a download has been completely consumed, so it can't really replace other file-sharing services. BUT I wonder how does it deal with race conditions ? My guess is that if many people start a download at the same time, they'll all be able to complete it before the file goes away. At least that's how I'd see it working with S3 or local storage.

You could abuse it by sending the same file many times in order to create lots of download links; but there's little to gain in bandwidth savings: you might as well run your own server. The only advantage I'd see is hiding your IP address, but then you could also run a tor hidden service. The other would be bandwidth amplification by synchronizing all the clients (for big files).

So, I just tested, and the race-condition method does work. I was able to download a 200M the encrypted file three times, and they match. You could imagine a site operator with hundreds of users uploading a file once every hour or so and lots of synchronized users downloading it for each generated link.

The sender could open a download connection and stall it as far as possible (maybe keep the download rate shaped to some bytes/second, to prevent an inactivity timeout). That would open a large time window for further downloads.

I assume the file would be deleted as soon as any client finishes downloading. (If the files are backed by regular files on a unix-like system, then the existing open handles to the file will keep working, allowing currently-connected clients to finish downloading, but preventing any new clients from starting the download.)

Indeed, I tested this too, but forgot to mention. That's how it works.

Applications are open for YC Summer 2019

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