Show HN: CryptSend.io – Share encrypted files with randomly generated links

I&#x27;ve recently analysed pricing of various storage providers when thinking of building a side project, and I was surprised at how costly the services were.<p>S3, Drive, Dropbox, Spaces, B2, Box, several Object Storage solutions. Some cases storage was cheap, but the transfer was costly. Everything seemed costly for the simple use case of providing an end user 10GB monthly upload + ~50GB bandwidth at low cost.<p>A vps with additional storage seemed to be the ~better~ most feasible solution to me.<p>This sounds like a terrific thing to host on a vps.

Is there any advantage to this over <a href="https:&#x2F;&#x2F;send.firefox.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;send.firefox.com&#x2F;</a> ?

Tempted to make a version of this myself because it&#x27;s simple. Single file executable, with statically linked Tor, that starts a v3 onion service (with or without client auth), hosts web server with file at URL, gives onion address URL (and client auth if any, could include the as part of URL or URL fragment or whatever depending upon approach desired). Client can use exe or Tor Browser to download it. Could add any features you want such as killing the server after first download, deadlines, etc.<p>Pro: doesn&#x27;t upload to server and preserves anonymity. Con: slower than non-anonymous.<p>Here&#x27;s a simple code example of a v2 onion file server using external Tor process w&#x2F; no auth: <a href="https:&#x2F;&#x2F;github.com&#x2F;cretz&#x2F;bine#example" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cretz&#x2F;bine#example</a>. This is essentially what onionshare does: <a href="https:&#x2F;&#x2F;github.com&#x2F;micahflee&#x2F;onionshare" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;micahflee&#x2F;onionshare</a>.

Seems like a bit of an oversight that they are including third party tracking scripts like googletagmanager.com in the same context as the javascript doing encryption. If you need user tracking, at least put the tracking scripts in an iframe sandbox or something that can&#x27;t accidentally grab the keys from the URL fragment and send them off to google.<p>Also they do call out that URL fragments get stored in browser history which is a big risk, but they should also mention that many browsers automatically &quot;sync&quot; history across devices (so keys will get sent to a cloud if you aren&#x27;t using incognito&#x2F;private browsing).

Amusing to see something that looks almost the same as a project I worked on with a couple friends 5 years ago. <a href="https:&#x2F;&#x2F;securesha.re&#x2F;" rel="nofollow">https:&#x2F;&#x2F;securesha.re&#x2F;</a><p>It&#x27;s open source too.

Hello HN!<p>Cryptsend was created as a result of my company having to share large amounts of medical data with our clients. We couldn&#x27;t find an easy and secure solution, so we sat down and created cryptsend. Our codebase is currently in alpha stages so any audits&#x2F;improvements&#x2F;security vulns you find would be really appreciated!

If the key is attached in link it also should be passed secure way, which is not usually.

The first thing I thought of when I saw the url is that it&#x27;s some kind of cryptocurrency transfer service. It&#x27;s pretty crazy how much cryptocurrency has hijacked the word &quot;crypto&quot;.

So one thing, it mentions that it is JS dependence free. How are you encrypting the files client side then?<p>If you are encrypting the files server side, then that is NOT E2E encryption.

Hi. Thank you for your work, this will be useful.<p>However, the `Get folder link` does not work. Is it deactivated for now ?

Why are all the &quot;m&quot; gray?

I made something like this a while ago. I think the name has a better ring to it though..<p><a href="https:&#x2F;&#x2F;sendsh.it&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sendsh.it&#x2F;</a>