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

Ah man, I literally came up with (and prototyped) this exact thing in 2013. Minus the end to end encryption. I dropped it mostly because I wasn't sure how to prevent illegal use and didn't want to be liable.

Edit: mine was actually (partially) better because it assigned a short PIN instead of a full link, which meant you could just look at it and remember it for typing-in, instead of requiring a separate channel to "send" the link.

You came up with a web service that lets anyone upload something and then download it via /uploads/123?

That's basically a hello world project. As you found out, the hard part is everything else, like funding it.

Funding it wasn't a problem. It took a weekend to build and was dirt-cheap to host. If people started using it enough to increase the server costs I would've stuck an ad at the bottom.

Honestly half of why I took it down is nobody was really using it. I didn't work terribly hard to market it, as I had no aspirations of getting rich and it would've been tenuous to monetize at all. I just told friends about it, etc.

I didn't imply there was a "hard part" to it. Just a neat idea. No need to dump on it.

I have a few sites like this, but very few people use them. These days, box and related sites have absorbed all the file uploads.

About 15 years ago, my sites were pushing 400-600mb/s non stop. Nowadays, I barely hit 1% of my network cap at each VPS location.

The end to end encryption necessitates a hard to remember uri anyway, so I don't think you can have both "secure" and "memorable".

Yeah; ID length was definitely another challenge. Time-expiration helped, but. I was going with 6 digits as a middle ground but it wasn't super secure, even if an upload expired after a few minutes. And of course there was no way for the user to know for sure that I couldn't keep around a copy without the E2E.

Theoretically, yes. But they could also derive keys from a shorter password value -- like password managers.

Encrypting it with a random key that doesn't get sent to the server, but is in the URI that the user sends to the receiver means that only the sender and receiver know what the file actually contains. Means neither you nor law enforcement can know what you are storing unless the URI is captured.

Hah, found a record of the project (we did it at HackTX): http://techzette.com/2013-hacktx-winners-and-finalists/

It was called "Catch"

If you're still interested in this type of tool, I'm sure Mozilla would welcome your contribution: https://github.com/mozilla/send

A short PIN seems nice for personal use (maybe on a self-hosted service) but wouldn't a short PIN allow people to potentially guess random PINs and download files that they shouldn't have access to?

The hope was for the time limit to help improve those odds, but, yes. It was also not really intended for anything truly sensitive.

The motivating case was when you're in physical proximity to the destination device, but don't have any account linkage between the two (not even messaging/email/social accounts that are connected). The original idea came from university computer labs: transferring homework between the lab computer and a personal one was a pain. I had to sign into dropbox in the browser (and 2FA), or attach it to an email, or carry around a flash drive (which wouldn't work on phones), or whatnot. Just to move the file three feet. A glanceable code with no sign-in bridged that gap.

Other use-cases include people you don't know very well (and therefore don't have an email, phone number, etc.). We demonstrated the prototype to a crowd by uploading a file with the code visible on the projector, and suddenly everyone in the crowd had the file. That was pretty cool.

Applications are open for YC Summer 2019

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