- Commendable that you've built a product like this at such a young age.
This comment isn't really addressed to you, but it would be nice if OS vendors had an API integration to allow access to remote drive/dropbox like how MS has OneDrive and Mac has iCloud drive. I know WebDAV is a thing, but both these vendor locked drives have a much better UX.
As for your website, I don't believe the organisations/companies or testimonials are real. Maybe you should just trim it. This is what real testimonials look like: https://www.tarsnap.com/testimonials.html
- I don't understand the Github repo, it shows some sort of drafted/vibe-coded frontend, but the actual program isn't open-source?
- The repo is the frontend — it includes all the client-side encryption, authentication, and UI logic. It’s still a bit rough around the edges design-wise, but the core logic and crypto implementation are solid and fully functional. Some features like settings and user profile are just placeholders for now(in dev.)
- Your "About" links seem not to work. In my case I was interested in where data is hosted, and the only information I see (from your HN post) is that you are from Paris. Does this mean EU hosting (which is good)?
- Yes, sorry — I’ve focused more on the actual logic of the dashboard rather than the landing page, which still lacks polish. Regarding the data, all your files are stored on Backblaze B2 servers (EU-central), with their data centers located in Amsterdam, Netherlands. I hope I’ve answered your question correctly.
- Nice, but please stop with the words "forever" when it's about costs, ie: "free forever". It harms your message.
- Thanks for your advice!
- Your post here says ML-KEM768 but the website says Kyber512.
Also, this SRP implementation seems a bit... sus.
https://github.com/ellipticc/drive-frontend/blob/main/lib/sr...
- Thanks for pointing that out! Could you elaborate on what specifically looks off about the SRP implementation? I tried to follow RFC 5054 with some minor adjustments for the frontend (using hash-wasm and fixed-length encoding to match the server), but I’d really appreciate feedback if something looks wrong or insecure.
- Side-channels. Also, N and G matter a lot to security; not making those hard-coded and transparent is sus. You can't just use a normal DH group.
I would recommend OPAQUE instead.
- Thanks a lot for the feedback — that was really helpful!
I’ve just pushed an update addressing your points: commit d94969a(https://github.com/ellipticc/drive-frontend/commit/d94969a63...) — N and G are now public, hard-coded RFC 5054 constants (3072-bit for new users, keeping 2048-bit compatibility), and I fixed the session key calculation length.
I’ll definitely look into OPAQUE later on — I did some early testing, but ran into a WASM-related crash on the server side, so I’m holding off until I can debug that properly.
Really appreciate you pointing this out — it helped tighten things up!
- "Open Source" is a pretty clear case of lying by omission.
You open sourced the frontend. Without a clear license.
That's not an "open-source cloud drive"
- Thanks for the feedback — to clarify, only the frontend is open-sourced at the moment, sorry for any confusion. I’ve also just added an MIT License to make that explicit. The backend isn’t public yet, but we may open parts of it later.
20 points by iliasabs 2 days ago | 13 comments