Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 421 posts

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

#161

Post by [deleted] »

vishnumohandas wrote: post #149
rock_hard wrote: post #124

Earlier quoted context omitted.

As someone who has worked on systems like these let me translate: “You stuff will be private but in return accuracy will be so bad that the UX is gonna suck!” That’s the key piece people miss when they wanna do anything with ML…that’s it’s a different problem compared to writing code because it’s not about the code anymore, it’s about having great training data!

Apple Photos seems to be using just Core ML[1] for on-device recognition and it does a pretty good job. As for Android, we plan to use tflite, but the accuracy is yet to be measured. And if customers do install our desktop app, we will be able to improve the indexes by re-indexing data with the extra bit of compute available. We don't feel that the entire UX of a photo storage app will "suck" because of a reduced acc…

[deleted]

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

#162

Post by Nalta »

rock_hard wrote: post #124
vishnumohandas wrote: post #107

Earlier quoted context omitted.

> Do you have a thumbnail of every photo client side In the happy path the files/thumbnails are indexed before they are uploaded. But we are designing a framework that will pull files/thumbnails for indexing if they are unindexed or indexed by older models. > how do you do this in a privacy preserving way Our accuracy will not match that offered by services who index your data on their servers. But there's a trade of…

As someone who has worked on systems like these let me translate: “You stuff will be private but in return accuracy will be so bad that the UX is gonna suck!” That’s the key piece people miss when they wanna do anything with ML…that’s it’s a different problem compared to writing code because it’s not about the code anymore, it’s about having great training data!

As someone else who works on systems like these, I agree training data is the whole problem. However you can use some techniques like homomorphic encryption and gradient pooling to collect training data from client code while remaining end-to-end encryption. It's hard, but it's not impossible.

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

#165

Post by vishnumohandas »

DenisM wrote: 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 masterKey is used to sign all your fileKeys)

- https://crypto.stackexchange.com/a/34458

- https://nordpass.com/features/xchacha20-encryption/#why%20No...

- https://blog.cloudflare.com/do-the-chacha-better-mobile-perf...

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

#166

Post by Radim »

vishnumohandas wrote: post #89
imagine99 wrote: post #77

Earlier quoted context omitted.

I fully agree. It's a hard sell getting people to switch from an evil but known cloud provider to an unknown cloud provider that claims to not be evil. What we do not need is more cloud offerings that can change, vanish or lock us out at the blink of an algorithm's eye. What we need, rather, are reliable and easy-to-use solutions that allow us to retain full control of our data (i.e. self-hosted and offline) while ha…

Hey, so the project had initially started off as a self-hostable software (with an option to buy a pre-configured device). We realized soon that it's hard to monetize such a product in the consumer space to the point where it can become self-sustaining. We don't have a problem with offering a self-hosted variant. But given our limited engineering bandwidth we had to take a call on who our target market should be, and…

> We realized soon that it's hard to monetize such [self-hosted product]

Spot on. We iterated on a similar product in this space: "privacy preserving", "self-hosted", "open source" etc. But focused on local AI indexing & search of personal videos and photos [0], rather than backups.

We ultimately shelved VideoNinja because we weren't able to find a sustainable business angle:

* Non-technical people simply don't care (happy locked into Apple / Google).

* Technical people understood the proposition, but are super stingy. Case in point, see the responses in this very thread: "$10 per year max; I can buy a HDD for less!". That's one (cheap) restaurant meal per year.

So I fully understand your decision to go "cloud". Although that immediately takes your product off the table for me personally. I want nothing of mine (of value) in the cloud.

I feel there must be a way to square that circle, the market exists.

[0] https://video-ninja.com/

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

#167

Post by finnh »

Nalta wrote: post #162
rock_hard wrote: post #124

Earlier quoted context omitted.

As someone who has worked on systems like these let me translate: “You stuff will be private but in return accuracy will be so bad that the UX is gonna suck!” That’s the key piece people miss when they wanna do anything with ML…that’s it’s a different problem compared to writing code because it’s not about the code anymore, it’s about having great training data!

As someone else who works on systems like these, I agree training data is the whole problem. However you can use some techniques like homomorphic encryption and gradient pooling to collect training data from client code while remaining end-to-end encryption. It's hard, but it's not impossible.

Really? Have we had a revolution in homomorphic encryption such that it can be used for anything other than 1-million-times-slower proofs-of-concept?

I know IBM has released something lately, but given the source..

Does anyone use HE for the type of ML application you are describing?

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

#168

Post by mynameisash »

sillysaurusx wrote: post #103
benbristow wrote: post #23

Your homepage says "protect your photos/faces etc. from algorithms" The algorithms are what makes Google Photos; Google Photos. If I wanted to just store my photos I'd throw them in a S3 bucket or Dropbox or something. Google Photos lets me automatically categorise my photos by person, lets me search my library using text search for anything (e.g. I can search 'museum' and see pictures I've taken in museums). That is…

Am I the only one who never realized you can search "museum" and see your museum photos? Now that you've mentioned it, yes, I'd like to try that. But as a counterpoint to your argument, I've never needed it, and I suspect that a lot of people may not actually be getting the same value propositions that you're getting. On the other hand, Google Photos is Google Photos. But it's often a mistake to compete directly with…

I use this feature occasionally, but it also seems to be pretty bad for the searches I try. For example, if I search for 'dog', I do indeed get pictures back that contain my dog. However, there are a ton of false negatives -- that is to say, the 'dog' search doesn't show me all of the photos that most definitely and very clearly have my dog in them.

And it's not just dogs. Specific people, locations (before I turned of geotagging on my photos), scenery (mountains, outdoors), etc.

Sometimes this search is nice, but it's not good enough that I can really rely on it.

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

#170

Post by ignoramous »

Congratulations, this looks neat. A couple questions around this venture:

1. Does ente.io intend to remain bootstrapped or seek funding (tiny-vc, crowd, crypto, public)?

2. Is the founding team in it for long term; serious about sustaining this business in face of capable incumbents (some upcoming ones https://news.ycombinator.com/item?id=27338008, some established ones like nextcloud.com, getkeepsafe.com) and competent competition (EteSync)?

---

A couple around the app:

1. What are the guarantees around backups / data loss across updates, device changes, account turnovers due to password-loss etc

2. If the founding team is thinking ahead, do they plan to build other such alt-apps too?

3. What's the server-side object store, if okay revealing that: StackPath? Scaleway? Wasabi?

4. How does ente.io handle file versioning, race conditions (file created and deleted with same names across different devices, as one example)?

5. How does ente.io handle abuse? Using ente.io for nefarious purposes such as CSAM, as one example.

---

A couple around cryptography (since you emphasize e2ee I took a glance at the architecture doc):

1. To my untrained eye, a lot of crypto cited in the architecture document reads like it was hand-rolled. There exists RFCs that cover recovery for usecases involving public-key crypto (PGP is hard for a reason), but yours is "cross-encrypt master-key with recovery-key and vice versa..." which does not inspire any sort of confidence in me. Besides, the wrapped keys stored on servers are sent to clients without any checks and hence subject to brute-force attacks. Are you sure of what you have designed isn't weak? ente.io sets out to be tarsnap but looks far from it.

2. Another thing that sticks out is the custom "encrypted authentication flow"...

3. How do I rotate the master key, collection keys, file keys etc in case my password is compromised? Sounds like a lot of work given the current architecture?

I see that the doc has been "peer reviewed" by 5+ engs, but any cryptographers in there?

---

A couple around ToS:

1. ToS states that ente.io may store documents even post-deletion by the customer. Why not delete it right away? That's a security risk?

2. If you suspend access to an account (since ente.io retains the right to do so), what policies govern data-takeout?

Thanks. All the best.

Post reply on HN