Live data from Hacker News

Show HN: We built an end-to-end encrypted alternative to Google Photos

news.ycombinator.com

361–370 of 421 posts

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#361
post #350

I feel like I'm missing something with these E2E encrypted products. I would _never_ recommend one of these to my family. What happens if they lose their password? Suddenly all of their photos are physically impossible to recover? What if the primary account holder dies? I would never trust a physical storage locker that said "if you lose your key we're going to set your stuff on fire". I _do_ place some amount of tr…

In addition to your password, you have a recoveryKey that can be shared with your family members. As long as you've access to either your password or your recoveryKey, you will be able to decrypt your data. A shared recoveryKey can be revoked and a new one generated if necessary. (We don't have a hook for this on the UI yet, but our system is designed to support a key rotation).

Nice! I appreciate that this is something that you've looked into. I'm still wary of the core tech here, because it's just too powerful. I'm personally ok with my photos being discovered by family many generations into the future. Or by random archivists. So much of the history we have access to is the result of discoveries of people's miscellany. Moving into an age where people's photos/messages/letters will auto-self-destruct by default -- the opposite of their physical counter-parts -- is scary to me.

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#362
post #81

I don't think I'm ready to invest in a photo hosting solution again, be it with my time, my money, or my data, without it being open source/self-hostable or at least open core with a community behind it. Been duped too many times.

Similar sentiment here. I wish this project well, but photo storage is a long-term thing, and I've been bitten too many times (most recently by Apple shutting down Aperture, which left me with big libraries which are very difficult to migrate).

I considered writing my own software and making it open source, but then realized that photo hosting/sharing software with password-protected sharing features will be used by criminals to store/share CSAM. So, if I end up writing my own solution, it will sadly not be shared with anyone.

Incidentally, I think this service will run into a similar problem: end-to-end encryption is great, but if it gets to a certain size, governments will intervene.

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#363

To me, the main selling point of Google Photos is their excellent AI search (yes, I understand the implications). Otherwise, Syncthing covers all of my requirements. Is there any alternative that has this kind of indexing/search?

Yes: https://photoprism.app/

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#364

Earlier quoted context omitted.

Drawing a direct parallel with Google will make this difficult, since they own their storage and network infrastructure and have ways to monetize your data. But here's an explanation on why there are large gaps between plans: - Our 1TB plan costs only 3x the 100GB plan. This model works under the assumption that the average utilization of a 1TB plan (across all customers) will be ~30%. - If we were to bring in an int…

I definitely empathise with the difficult in competing with the big cloud providers on price. Your service is inevitably going to end up more expensive. Having said that, I'd be interested to know how you're hosting the content. When I was looking at setting up a similar service, it seemed like you Backblaze B2+Cloudflare might well be the best combination. B2 will sell you storage at $5/TB, and you can get free band…

Pre-signed URLs generated with B2's S3 APIs are incompatible with Cloudflare at the moment. We are working around this by using a Cloudflare Worker to proxy data from B2 to the client. This is currently free if you're on the Bundled plan and Cloudflare's support has promised that when they decide to start charging, they will alert us in advance.

Interestingly, Workers Unbound charges 0.045/GB which is more than B2's 0.01/GB.

A viable long term alternative could be Wasabi that offers free egress in return for a $6/TB plan. But we're waiting to see how things pan out before executing an expensive migration.

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#365
post #361

Earlier quoted context omitted.

In addition to your password, you have a recoveryKey that can be shared with your family members. As long as you've access to either your password or your recoveryKey, you will be able to decrypt your data. A shared recoveryKey can be revoked and a new one generated if necessary. (We don't have a hook for this on the UI yet, but our system is designed to support a key rotation).

Nice! I appreciate that this is something that you've looked into. I'm still wary of the core tech here, because it's just too powerful. I'm personally ok with my photos being discovered by family many generations into the future. Or by random archivists. So much of the history we have access to is the result of discoveries of people's miscellany. Moving into an age where people's photos/messages/letters will auto-se…

The risk you're talking about applies to all cloud storage providers that depend on monthly/annual subscription renewals I suppose. Which makes me wonder if there is a market for a 100 year plan with pro-rated refunds. :)

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#366
post #352
post #350

I feel like I'm missing something with these E2E encrypted products. I would _never_ recommend one of these to my family. What happens if they lose their password? Suddenly all of their photos are physically impossible to recover? What if the primary account holder dies? I would never trust a physical storage locker that said "if you lose your key we're going to set your stuff on fire". I _do_ place some amount of tr…

I leave the handling of those situations to Lastpass. My wife and kids may request access to my password locker, and if I don't reject within 30 days the locker is opened to them.

Thanks for sharing this, I had no idea Lastpass had such a feature.

I guess this means that your family already has access to your decryption keys and the Lastpass servers are merely restricting access to the encrypted data for the 30 day time period.

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#368
post #145

Earlier quoted context omitted.

I concur. However storage is how they plan to make money, so there will need to be a different monetization strategy for BYO storage. As yet I can't imagine any. EDIT: I think have an idea! Add the S3/OneDrive/Etc support but comment it out. To make use of it one would have to download the source, XCode, compile it, and deploy it. This puts a cap on the number of people who can do that, so you won't end up with every…

So it's a little more complicated than that. Our API server runs the following - authentication - replication - differential sync - and a few more errands that are necessary for the apps to function The solution to this would be to offer a self-hosted variant where you can plug in your S3 credentials. But like I mentioned else where in this thread, maintaining such a project comes with an overhead we cannot afford ri…

I would pay for a self hosted solution, or for a solution where I can plug into a backend you support.

I would also pay upfront, e.g. kickstarter

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#369
post #152

Question: Why XChaCha20? If you used aes256 I wouldn't even give it a thought and simply move on to the next question, but now I have stop and ask what's going on and wonder if you did it right. Just seems like unnecessary friction in my decision process.

We had started off with AES, and the performance was abysmal on low-end mobie devices and certain web browsers. XChaCha20 in comparison added negligible latency and seemed less prone to human errors. These weren't the sole reason however. There's a lot of literature on the security aspects of XChaCha20, some of which I'll link below: - https://soatok.blog/2020/07/12/comparison-of-symmetric-encry... (in our case your…

Have you correctly evaluated your threat scenarios?

ChaCha is streaming cipher, which is meant to be used on transmission phase, not on data-on-rest(DARE). That is significant difference. In this case, you are implementing Photo storage service, where data is laying mostly on your servers, and not disappearing after the transmission. What is the threat model?

In general, streaming ciphers are considered as weaker alternatives for DARE ciphers. The main risk lies on nonce. In service like this, you are using long-term key. xChaCha provides 192-bit nonce. How likely you are generating identical nonces?

Well. In this case, it might be that this streaming cipher is safe. 192-bit nonce is quite big number.

For example AES-GCM with 96-bit nonce has max message amount of 2^32 when used deterministically [1]

In theory, the AES alternative is much weaker than your current implementation.

[1]: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=51288...

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#370
post #367

Is there an example gallery we can check (without the need to log in, or upload own photos)? Is there a local backup? (Say, in the pessimistic case of Ente going down for any reason.)

Sorry, we don't have a sample gallery yet. :(

We do have a local backup tool that will sync your uploaded files to a local folder: https://github.com/ente-io/bhari-frame/releases/latest

Post reply on HN