Thank you to everyone who took the time to review QuickClip and give honest feedback.
I spent the day going through everything and fixing the issues that were pointed out, especially around security.
You were right. The concerns were valid, and they’re now addressed.
1. Shared encryption key (Retr0id's main issue):
Problem: All users shared one encryption key, so any user could decrypt any other user's data.
Fix: Each user now has a unique encryption key derived via PBKDF2 from master key + user ID (10,000 iterations). Old items encrypted with the shared key are detected during decryption and automatically re-encrypted in the background with the new per-user key. Backward compatibility is maintained during the migration.
2. Public image access (Retr0id's second issue):
Problem: Images were publicly accessible without authentication.
Fix: Images now use signed URLs that expire after 1 year. The app automatically converts any public URLs to signed URLs. Storage bucket policies restrict access to user-specific folders.
3. Storage enumeration (foltik's issue):
Problem: Could enumerate all user uploads with a sign-up token.
Fix: Storage policies now restrict folder access by user ID. Still reviewing listing permissions to prevent enumeration.
4. E2EE misrepresentation:
Problem: Marketing claimed "end-to-end encrypted" but it wasn't true E2EE.
Fix: Added a /data-security page that explains:
It's server-side encryption with per-user keys, not true E2EE
Why server-side encryption was chosen (seamless cross-device sync)
5. Transparency issues:
Problem: No information about how data is handled before signup.
Fix: Added /data-security page with details. Link added to footer. Removed the footer joke that hurt trust.
6. Other fixes:
Rate limits adjusted for encryption/decryption operations
Background re-encryption for old items
Proactive signed URL conversion for images
What's still being worked on:
Storage bucket listing permissions (enumeration prevention)
Adding screenshots to landing page
FAQ section
Considering open source (evaluating)
I appreciate the security review. The app is more secure now, and I'm committed to transparency about what it does and doesn't do. Check /data-security for the full explanation.
I think the challenge is that you are potentially storing some of the most secret things for users here - passwords copied from password managers, bank details copied and pasted into forms, private photos, corporate secrets and designs, medical records... And even your revised model shows a completely careless approach to security and is entirely insufficient considering the data stored.
Encrypting images is too slow too? Poor excuse - it probably takes milliseconds. If you are asking people to trust them with their nudes and photos of bank documents, you need to store them in a way that you can’t see them.
You having access to all user data stored with a tiny privacy policy that basically boils down to “we can use your data as long as it’s not illegal for us to use it” is not sufficient!
I wouldn’t be this harsh on the security of another startup or app just because most startups don’t start asking users to store their secrets with them - because you will be storing secrets, that puts you into a category of people who need to be careful and not careless - at the moment you are demonstrating the latter.
It’s entirely possible to do everything end to end by the way (imo this is the only way this should be done considering you will be storing passwords) - see how 1password does it and copy them if nothing else: https://1password.com/files/1password-white-paper.pdf
Hi, I'm a solo developer trying to build and learn new things along the way, and I appreciate your responses, about the QuickClip, I've been making some improvments along the way also I've updated my landing page about how we manage data and how users should not add their senstive data and it should be just used for moving your usual stuff, I've removed all the writings where I was mentioning that we're using "e2ee", its mentioned much more clearly that how we handle your data in the FAQs. Kindly have a look at the quickclip.space again. Let me know what you think
I've posted elsewhere, but I still have lots of issues personally:
* Your deletion policy says you delete images instantly and via the UI in settings, but I've checked and they are retained in the object store. You need to update these policies to be honest and say that the images aren't deleted, and that you currently retain them and just delete the reference to them.
* Your privacy policy says you can't see user content, but you clearly can (as you have both the data and the encryption keys). You might not have developed the functionality to read it yet - but it is trivial to do. Just be honest and say 'your data can technically be accessed by us, but we promise not to look at it'.
* Your privacy policy only limits your access to 'what is allowed by law' - which is clearly the absolute minimum!
I think your policies currently say how you would like it to be, rather than how it is. You need to be honest with users about how their data is actually processed.
Respect to you and David for trying to help, but eventually you're going to experience Brandolini's law here.
OP is frantically pasting your findings into an LLM and letting it excrete another blob of untested, unverified shit. "It WILL be secure this time!", the LLM says, hopelessly.
OP does not care about whether the tool is built on solid appsec foundations. OP cares about the 0.00001% chance of getting interest in his tool from $VC_FIRM.
You've indicated that this tool already has a bright glowing all caps DO NOT USE verdict and no reassurance from a coding-agent-in-a-loop will make it better.
But, why use a key stretching algorithm for this particular scheme to begin with? What is it protecting against here? The master key is presumably high entropy. If someone gains access to the master key and breaks into your server a key stretching algorithm isn't going to help you.
Lots of secrets get sent through the clipboard. Anything handling it either needs to be strictly local or E2EE. Otherwise everything is vulnerable if someone breaks into the server. It's also accessible by you at will regardless of any promises you might make to the contrary.
Seamless cross device sync isn't an excuse. E2EE itself doesn't impede that whatsoever, only certain protocol choices that aren't (or at least don't need to be) relevant here.
100% agree - If this app gets any traction at all, it's only a matter of time before someone's crypto wallet gets leaked and emptied.
If you want to be handling peoples secrets, you have to make sure you know what you are doing and build something bombproof (bombproof from a mathematical perspective, rather than relying on your server being secure)
Added https://quickclip.space/data-security with encryption details. FAQ coming soon. Thanks for the feedback—explaining encryption clearly is important.
> So while the image URLs aren't encrypted, they're still secure. Only you can access your images.
This isn't true though - and presumably you know it isn't true?
You would be able to access and download all the images if you wanted to.
> But we can't read the actual content of your encrypted items without your encryption key, and we don't have a reason to try.
This is also misleading - because you do have the encryption key, so you can read the content if you want to. "We won't read the content even though we could, because we don't currently have a reason" is the actual state of affairs.
Clarified: it's server-side encryption with per-user keys, not true E2EE. Added https://quickclip.space/data-security explaining the approach. Open source is under consideration. Thanks for pushing for transparency.
still working on it. Storage bucket policies now restrict folder access, but listing permissions need tightening. Will update bucket policies to prevent enumeration. Thanks for the detailed curl examples—they helped identify the exact issue.
Also Fixed. Images now use signed URLs with 1-year expiration. Public URLs are automatically converted to signed URLs. Storage bucket policies restrict access to user-specific folders. Appreciate you flagging this.
Fixed. Each user now has a unique encryption key derived via PBKDF2 from master key + user ID. Old items are being re-encrypted in the background. See /data-security for details.
> Your encryption key is derived from a master key plus your user ID using PBKDF2 (a secure key derivation function). This means even if someone got access to the database, they couldn't decrypt your data without your specific key.
> Your text gets encrypted on our server using your unique key. The encrypted data gets stored in our database
> When you need it on another device, we decrypt it and send it to you
Please stop advertising this as E2EE.
If you encrypt/decrypt the data on the server, you must have the keys. If someone gets access to the server, they can just decrypt everything since the master key is right there. You might as well base64 encode everything and call that encryption.
E2EE is where only the clients have the keys. Data is encrypted before sending to the server, and decrypted after receiving from the server. That's why it's called end-to-end: the server only ever handles encrypted data that it doesn't have the keys to decrypt.
Yeah fair point. QuickClip does store data in database, otherwise syncing between devices not possible. But here is how it works:
- Data is encrypted when sending and also when sitting in database.
- Stored only so your devices can fetch it, not for me or anyone else.
- When you delete, it’s gone. I don’t keep logs of clipboard stuff.
- I don’t look at your data, only your devices can see it.
I know trust is big thing for clipboard app. I’ll write small “how it works” page so it’s more clear. Appreciate you asking this, makes sense.
Where are the keys stored? If you encrypt the data but just have the keys in another database table, I don’t really see the point of having it encrypted at all.
I agree with others. I wouldn’t use this unless I trust how you’re handling my data security. All sorts of highly sensitive passwords and security keys hit my clipboard.
Keys are derived server-side using PBKDF2 (master key + user ID). Each user gets a unique key. Keys never leave the server. Details at https://quickclip.space/data-security. Thanks for asking—this is exactly the kind of question that matters for security.
- It’s not E2ee. It’s not even client side encrypted.
- You encrypt at rest. But using a key that you control anyway. The master key presumably is never stored in the database, which is a nice touch in case the database gets stolen.
- Images aren’t encrypted at all for some reason. (I think you’d find encrypting images with aes to be pretty fast. If you’re using tls, the image data is already being encrypted and decrypted over the wire, but too fast for you to notice).
How long is data stored for? Are images ever deleted? Is text?
And are you using TLS? At the protocol level everything is sent in the clear. So your transport security is quite important.
Why are you even encrypting? What's the threat model it's protecting against? Clearly it's not "prevent me from reading your data" since you have access to the keys anyway.
You were right. The concerns were valid, and they’re now addressed.
1. Shared encryption key (Retr0id's main issue): Problem: All users shared one encryption key, so any user could decrypt any other user's data. Fix: Each user now has a unique encryption key derived via PBKDF2 from master key + user ID (10,000 iterations). Old items encrypted with the shared key are detected during decryption and automatically re-encrypted in the background with the new per-user key. Backward compatibility is maintained during the migration.
2. Public image access (Retr0id's second issue): Problem: Images were publicly accessible without authentication. Fix: Images now use signed URLs that expire after 1 year. The app automatically converts any public URLs to signed URLs. Storage bucket policies restrict access to user-specific folders.
3. Storage enumeration (foltik's issue): Problem: Could enumerate all user uploads with a sign-up token. Fix: Storage policies now restrict folder access by user ID. Still reviewing listing permissions to prevent enumeration.
4. E2EE misrepresentation: Problem: Marketing claimed "end-to-end encrypted" but it wasn't true E2EE. Fix: Added a /data-security page that explains: It's server-side encryption with per-user keys, not true E2EE Why server-side encryption was chosen (seamless cross-device sync)
5. Transparency issues: Problem: No information about how data is handled before signup. Fix: Added /data-security page with details. Link added to footer. Removed the footer joke that hurt trust.
6. Other fixes: Rate limits adjusted for encryption/decryption operations Background re-encryption for old items Proactive signed URL conversion for images What's still being worked on: Storage bucket listing permissions (enumeration prevention) Adding screenshots to landing page FAQ section Considering open source (evaluating) I appreciate the security review. The app is more secure now, and I'm committed to transparency about what it does and doesn't do. Check /data-security for the full explanation.