Show HN: Flashpaper – Self-destructing secret sharing with no database

See the problem with generating apps like this is that you have no idea what secret sharing even is and it's pretty clear you didn't even bother to research anything. This has so many holes, and secret sharing schemes NEVER send the secret over the network. The secret is the encryption key, not the payload itself, you're conflating the two. You have to send the payload, but you negotiate a secret, not send one in plaintext. And yes, you're sending the password in plaintext, as far as snoopability goes. Don't roll your own crypto. So if you ever use this to send an api key, you should still invalidate the key and change it afterwards. If you don't want to.... well it's your own money on the line.

edit: That's also not what zero knowledge means

This is very cool. I can't comment on the encryption, but I did want to mention that your page design is pretty bad, which is a shame for something so useful.

It looks AI generated, you can probably paste this into your LLM of choice to improve it.

It has pretty subtle information hierarchy. All the text sizes except for the main heading are withing 15% size of each other. More differentiation here would be the lowest hanging fruit, I think. I'd also say all the text needs to increase in size in general. It's pretty low contrast as well, made worse by the small font size. And some things, like button highlights, are too high-contrast. They pull too strongly away from the rest of the text and flow. You also have a lot of buttons, some of them are even just to pre-fill demo text. I'd cut it way down.

I think the goal should be that the critical path to making a 'burn link' is at the very top of the information hierarchy. Big heading "Your Secret", with very well signposted text box. Big heading "Link Expiration" with a big range slider (with number input.)

(Sliders have the advantage of structurally communicating what you're doing. You fill up the available slider to add more time, you shrink it to have less time.)

The overall idea is that the eye naturally snaps to the next step when the previous one is done with zero effort. Really blast the information and steps into people's brains.

I hope Flashpaper takes off!

Neat! I made one of these also: https://flashpaper.me

How does this compare with other pastebins like privatebin? https://privatebin.info/

It’s worth thinking through threat assessment and security posture carefully at the design and production phase. First, I’ll say that it’s cool you’re working on security stuff! It’s a hard discipline, but interesting. Next I’ll say that this needs work.

Here’s what you have right now:

1. Data is encrypted in browser and sent to the server. (I didn’t check who makes this key, let’s assume it is a fair and safely created browser generated key by the user, though. That said, you should read up on randomness in javascript environments.)

2. A single reference link is sent to someone over some message transport, with the private key carried after an anchor reference (#).

3. The server sees the reference link, serves up the file, the browser uses the URL anchor to decrypt

4. The javascript in the browser rewrites the anchor link so that we have lost the key.

5. The server starts a countdown after which it will not serve the file.

This is not very secure. It’s vulnerable to bad actors on the server side, bad actors in javascript libraries you include, browser extensions that read the anchor tag, and any send over a messaging transport might leak everything you need to steal the file / start the counter.

A good concept in the cryptography world is ‘security theater’ — a lot of this is, unfortunately, security theater, it relies on good actors or clear code paths for safety.

Now to talk server and business risks — what is your Denial of Service security model? Have you tested being spammed millions of uploads, gigabytes of data, super slow connections keeping ports open, etc? What is your IP logging strategy? Will you be able to respond to subpoenas or not, and if not, are you comfortable dealing with the downsides of designing and publishing a system that cannot respond to subpoenas?

A couple quick recommendations here — I’d suggest you figure out how to redesign this so it’s point to point for agents; they’re pretty industrious these days —- if you could get rid of hosting you’d have a much easier deployment model. I’d pester claude HARD on security theater, and then I’d ask chat 5.6 sol for a thorough security review. 5.6 sol is better for pen testing in my general experience.

Also, I have published a (relatively) securing messaging tool for agents: `pip install qntm` or github.com/corpollc/qntm should get it to your agents. They’ll still need a setup phase where they get access to the same messaging channel, but once onboarded I believe the messaging itself makes pretty strong guarantees.

Like I said, keep building! This is a very difficult space to build something useful and secure in, though, so don’t be discouraged if you need to keep poking at it and getting input.

some great tech, what problem do you encounter that led you to develop it?