Live data from Hacker News

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

news.ycombinator.com

351–360 of 421 posts

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

#351

Earlier quoted context omitted.

Venture: 1. We did apply to YC a few months ago, but was rejected in the interviews because they felt that the total addressable market was low. We don't know if other VCs will feel differently and we haven't applied anywhere else since. Perhaps paid subscriptions is in a way public funding? :) 2. The rate at which photos are being taken (a trillion a year), we believe that the market is large enough for multiple pla…

I've been thinking of a similar system with e2e sharing of content and I'd love to pick your brain on this if you don't mind :) - What made you go with libsodium over using the browsers Web Crypto API? - If you stop sharing an album with someone, do you somehow re-encrypt the collection key or is the recipient still in possession of all the necessary keys to decrypt the data if they get their hands on it?

- Mature libsodium clients were available across the platforms we were targeting. The APIs seemed well documented and turned out to be a delight to consume.

- There are access control checks in place to revoke access to files from removed album participants. But from a cryptographic standpoint, once your keys have been shared (/compromised), the respective files should be re-encrypted.

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

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

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

#353

Earlier quoted context omitted.

I've been thinking of a similar system with e2e sharing of content and I'd love to pick your brain on this if you don't mind :) - What made you go with libsodium over using the browsers Web Crypto API? - If you stop sharing an album with someone, do you somehow re-encrypt the collection key or is the recipient still in possession of all the necessary keys to decrypt the data if they get their hands on it?

- Mature libsodium clients were available across the platforms we were targeting. The APIs seemed well documented and turned out to be a delight to consume. - There are access control checks in place to revoke access to files from removed album participants. But from a cryptographic standpoint, once your keys have been shared (/compromised), the respective files should be re-encrypted.

Thanks for answering! Regarding the second point, does the application do this automatically or is the user expected to re-encrypt data manually?

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

#354

Earlier quoted context omitted.

- Mature libsodium clients were available across the platforms we were targeting. The APIs seemed well documented and turned out to be a delight to consume. - There are access control checks in place to revoke access to files from removed album participants. But from a cryptographic standpoint, once your keys have been shared (/compromised), the respective files should be re-encrypted.

Thanks for answering! Regarding the second point, does the application do this automatically or is the user expected to re-encrypt data manually?

We don't handle this case right now, have added this to our roadmap[1].

I feel that for our use case of storing and sharing personal photos, this might be an over kill. But I'll let the customers decide. There might be usecases I might not have thought of.

[1]: https://roadmap.ente.io/option-to-download-re-encrypt-and-re...

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

#355

Earlier quoted context omitted.

Thanks for answering! Regarding the second point, does the application do this automatically or is the user expected to re-encrypt data manually?

We don't handle this case right now, have added this to our roadmap[1]. I feel that for our use case of storing and sharing personal photos, this might be an over kill. But I'll let the customers decide. There might be usecases I might not have thought of. [1]: https://roadmap.ente.io/option-to-download-re-encrypt-and-re...

That's exactly the problem I'm facing. Especially if there are multiple shares to the same data it gets tricky. Love to see public roadmaps in products btw.!

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

#356

Earlier quoted context omitted.

We don't handle this case right now, have added this to our roadmap[1]. I feel that for our use case of storing and sharing personal photos, this might be an over kill. But I'll let the customers decide. There might be usecases I might not have thought of. [1]: https://roadmap.ente.io/option-to-download-re-encrypt-and-re...

That's exactly the problem I'm facing. Especially if there are multiple shares to the same data it gets tricky. Love to see public roadmaps in products btw.!

You could perhaps take a look at Skiff's white paper[1] and see how they solve for this.

[1]: https://www.skiff.org/security

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

#357

Earlier quoted context omitted.

Can I suggest adding pricing tier(s) between 100GB and 1000GB? I have between 100gb and 200gb of photos, and £14.99/month seems like a lot considering I only pay £2.49/month for google storage. I'd definitely consider paying a premium for this service, but not 6x.

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 bandwidth out to Cloudflare's network. It's against Cloudflare's terms to use free plan for image hosting that isn't just images as part of webpages. However, one of their staff members commented on a thread that they'd likely to be willing to set up a custom plan for a business who wanted to do this. And I'd bet that Cloudflare's bandwidth would be a lot cheaper than B2's.

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

#358
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).

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

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

That's an ingenious system.

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

#360
post #106

Earlier quoted context omitted.

I get the decision but I think it misses part of the problem: how do you convince people like your mum and dad to start paying for backups and how do you convince them to pay extra for privacy? I suspect the way it usually happens is that somebody your parents trust (like you) tells them to sign up for a privacy-preserving backup service. But who's going to tell them to do that? Do you have the money to pay for adver…

> how do you convince them to pay extra for privacy? We are hopeful that we will be able to reduce the pricing as we scale up and hit a critical mass. > who's going to tell them to do that? We plan to implement a referral program, similar to what Dropbox did, to incentivize existing customers to spread the word. That said, you do bring up interesting points. To repeat, we aren't averse to the idea of maintaining a se…

For our (nascent) product went the other way and prioritised self-hosting at the expense of stretching ourselves too thin, as that's always been #1 ask from folks looking for "consumer-first" alternatives.

Time will tell if it was the right way forward, but I just went with "you can't fight gravity" and built it the way folks expect it to be (ex: supabase / posthog / gitlab).

Post reply on HN