Encryption appears to be in the openssl "Salted__" format (and base64 encoded). I can't infer the actual encryption algorithm configured, but it's an unauthenticated block cipher with 128-bit blocks, presumably in CBC mode, padded with PKCS7.
Additionally, the same encryption key (whatever it is, I can't see it since it's stored on the server) is shared across all users (I tested this by decrypting a ciphertext from one account on a second account).
.>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.
Why should users trust you?
This is definitely not 1/2 of a smishing toolkit pretending to be a convenience utility.
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.
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.
If I do want to move some info i'll message it to myself thank you.
Will definitely repost on social media!
Would you mind sharing the source code?
> Copy API keys
...yeah, I think that'd be a hard requirement. I don't think there is value in a cliboard-as-a-SaaS that is not self-hostable or even auditable.
I think you are putting the cart before the horse and putting your users at risk by integrating credit card payments before sorting out the basics.
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.
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!
... works with Pushbullet apps.
In cases where iOS/macOS misbehave, I use (IMAP) email without sending anything:
- create new mail message
- paste text or add attachments
- save as draft
- open draft on other device
- copy out the data
- delete draft
Works reliably for not-too-large items