Key Features
Does it use some client, what do I need to install on my devices (if supported) and what permissions does it need etc? Instead I'm greeted by a login page.
It's not transparent enough for me how the product is used before signing up and that's a huge turn off.
VC funding surveillance capitalism startups : "Here, take my money!"
/$
.>client apps are not open source
.>data-deletion page seems to imply servers are storing images/files copied to the clipboard
.>"end-to-end encrypted" in the marketing materials.
I would add examples how data encryption works. This is so sensitive topic. But if you explain it nicely, people could use the service.
I would add FAQ. Boxes seem like I can read more but I can’t.
This isn't true though - and you know it isn't true?
e.g. you can access them?
If I do want to move some info i'll message it to myself thank you.
They decided to do it Gnome style and give the user no options.
Why should users trust you?
- 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.
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.
- 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.
Which is not to say there's not a big use case for this, but speaking only for myself, it's not a pain point. But it looks cool!
Will definitely repost on social media!
List all folders in the clipboard-images bucket (there's 5, guessing for each user):
curl -X POST \
"https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/list/clipboard-images" \
-H "authorization: Bearer eyJXXXXXXXX" \
-H "content-type: application/json" \
-d '{"prefix": ""}' \
| jq
curl -X POST \
"https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/list/clipboard-images" \
-H "authorization: Bearer eyJXXXXXXXX" \
-H "content-type: application/json" \
-d '{"prefix": "7b407af2-f30c-4e37-adc7-b7bf48f2661b"}' \
| jq
{
"name": "1766836115975-Gopal_Resume.pdf",
"id": "7ba4b09f-a0ab-4ce1-ae04-dc664be25b0f",
"updated_at": "2025-12-27T11:48:36.761Z",
"created_at": "2025-12-27T11:48:36.761Z",
"last_accessed_at": "2025-12-27T11:48:36.761Z",
"metadata": {
"eTag": "\"eb528546d014c8756fc1d0fedc252cff\"",
"size": 75023,
"mimetype": "application/pdf",
"cacheControl": "max-age=3600",
"lastModified": "2025-12-27T11:48:37.000Z",
"contentLength": 75023,
"httpStatusCode": 200
}
}
Deletion policy says:
> 2. How to Delete Your Account and Data You have several options to delete your account and all associated data: Through the App: If you are signed in, you can delete your account directly from the Settings page. This will permanently delete all your data including [...] All uploaded images and files
... Although I've confirmed that the reality is that it only pretends it has deleted the items, and I can still see the actual files as I saved the image URL before 'deleting'.
This thing is an absolute security and privacy nightmare - I would not rely on any information on the website about how they handle your data, considering they said it was e2e and that was not truthful, and they have said they delete the images and that isn't true. How can this be trusted?
curl -X POST \
"https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/list/clipboard-images" \
-H "authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6IndqeW5tamx1YWJxd3FodGR4YnRsIiwicm9sZSI6ImFub24iLCJpYXQiOjE3NDIzODU1MDQsImV4cCI6MjA1Nzk2MTUwNH0.R6pSgPFgHe3ZU9DfKykE98MC1ObYihWdZuhy9v9Y_p0" \
-H "content-type: application/json" \
-d '{"prefix": "7b407af2-f30c-4e37-adc7-b7bf48f2661b"}' \
| jqExample: https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/s...
Thanks for catching this critical issue.
Also, your site still says "E2EE" on the homepage, you should remove that.
> 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.
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.
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.
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)
Storing all these things need thinking through properly and expertly, not just fixed within 10 hours (presumably with a load of vibe code to achieve that speed?)
* Your deletion policy says you delete images instantly, 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.
* Your privacy policy says you can't see user content, but you clearly can. 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!
OP is frantically pasting your findings into an LLM and letting it hopelessly excrete another blob of untested, unverified shit. "It WILL be secure this time!", the LLM says.
OP does not care about whether the tool is built on solid appsec foundations. OP cares about the 1% chance of getting interest from $VC_FIRM.
This tool already has a bright glowing all caps DO NOT USE verdict and no follow-up response from an LLM-in-a-loop will change that.
This is definitely not 1/2 of a smishing toolkit pretending to be a convenience utility.
Would you mind sharing the source code?
... works with Pushbullet apps.
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.