[Closi]

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

[imgopaal]

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

[Closi]

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.

[usefulposter]

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.