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.
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.
tbh, mostly just for fun. but also a bit issue from when I type API key in Claude and it's always remind me to delete or regen API keys. i think this might solve that.
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!
Thank you so much for constructive feedback!
You caught me. The design is AI-generated, I built the whole app with AI tools.
Really apprecaite the pointers; I agree with what u said, and will try re-read it again tomorrow (it 1.30 am here haha) and adjust the design.
Again. Thanks a lot for your support and kind words!
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?
tbh, mostly just for fun. but also a bit issue from when I type API key in Claude and it's always remind me to delete or regen API keys. i think this might solve that.