Show HN: I built a universal clipboard that syncs realtime on multiple devices (quickclip.space)
I’m Gopal, the guy behind QuickClip.
I built this out of pure frustration. Copying items between my phone and laptop was very painful. Sending notes and links on WhatsApp. Saving random drafts I’d forget about. It was total waste of time.
So I made QuickClip for myself first. A dead simple way to move text, links and images between devices instantly. No setup drama. No thinking. Fully encrypted
I use it every day. Shipping it publicly now to see if anyone else has the same problem.
Would honestly love to hear, how you move stuff between devices today, what’s broken or slow and what would make this actually useful for you
Happy to answer anything and take suggestions. Thanks for checking it out.
25 comments
[ 4.6 ms ] story [ 45.2 ms ] threadDoes 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.
https://github.com/bjesus/clapboard
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
.>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.
If I do want to move some info i'll message it to myself thank you.
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.
Why should users trust you?
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!
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).
This is definitely not 1/2 of a smishing toolkit pretending to be a convenience utility.
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)
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
... works with Pushbullet apps.