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

341–350 of 421 posts

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

#341

Post by diebeforei485 »

bigiain wrote: post #314
Roritharr wrote: post #229

Earlier quoted context omitted.

I'm in the same boat, have been watching, love that they have a businessmodel and am waiting for the time when they are covering my needs (face recognition, object / scene detection...). I'd even pay a 2$/month "lurker" subscription which has like 100mb of storage so I can check the features from time to time and support the team.

So this is a project specifically marketed as E2E encrypted, and you are "waiting for the time when they are covering my needs (face recognition, object / scene detection...)" You will be waiting a long long time for that. The only way they can do that is client side, and if they go there we are back to the last few weeks discussion of Apple's new client side image scanning shit. You do not want this service, it seem…

I don't think this is fair.

What iCloud Photos is doing for their client-side scanning is: (1) Not to your benefit. There is no positive outcome for you from your photos being scanned. (2) Mandatory if you want to use iCloud Photos.

In contrast, I presume this would be- (1) Only to your benefit, because all of this derived metadata around scenes and faces would also be encrypted end-to-end as part of the photo library. (2) Entirely optional.

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

#342

Post by vishnumohandas »

marwis wrote: post #338
vishnumohandas wrote: post #317

Earlier quoted context omitted.

FWIW, ente processes all of the location metadata generated by Takeout during an import via web.ente.io.

That's probably the best once can do other than reverse engineering the protocol used by Google Photos Android app - as that app seems to be able to download files with full exif, unlike official API. Unfortunately, as mentioned, multiple users report that Takeout does not work once you get past certain size (I have 350GB and it fails every time). It's been failing for years, probably always. Of course Google doesn't…

I sincerely hope that someone sues.

Google has blocked access to their APIs for migration[1] which IMO contradicts with their stance on data portability[2]. It is hard to assume good intent here.

[1]: https://developers.google.com/photos/library/guides/acceptab...

[2]: https://datatransferproject.dev

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

#344

Post by fomine3 »

istingray wrote: post #276
missedthecue wrote: post #270

Earlier quoted context omitted.

I don't really get what's evil about AI models and cloud sync. And I don't think anything is wrong about Facebook's business model. I think most people are uninformed about it and believe that they sell personal data, but if you understand the way they make money, it's very difficult to say that there is any particular issue with it.

Ah, what you really meant was "what's evil about selling my data?" which is a much larger question. And it sounds like you already have your answer.

They actually don't "sell".

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

#345

Post by marwis »

vishnumohandas wrote: post #342
marwis wrote: post #338

Earlier quoted context omitted.

That's probably the best once can do other than reverse engineering the protocol used by Google Photos Android app - as that app seems to be able to download files with full exif, unlike official API. Unfortunately, as mentioned, multiple users report that Takeout does not work once you get past certain size (I have 350GB and it fails every time). It's been failing for years, probably always. Of course Google doesn't…

I sincerely hope that someone sues. Google has blocked access to their APIs for migration[1] which IMO contradicts with their stance on data portability[2]. It is hard to assume good intent here. [1]: https://developers.google.com/photos/library/guides/acceptab... [2]: https://datatransferproject.dev

As the famous saying goes, never ascribe to malice that which can be explained by incompetence. This is Google we are talking about, they are infamous for their lack of strategic focus and disorganization.

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

#346

Post by cientifico »

vishnumohandas wrote: post #69
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…

> So you're going to implement algorithms then? Yes, we will implement the algorithms, purely on the client side, such that we don't hold indexes to your personal data. But I understand how that piece of text could have thrown you off, I'll think of ways to rephrase it. Thanks for pointing it out.

But that will mean that for every version of the algorithms, it have to read all the photos since 15 years ago... my phone battery will die soon.

And if I need to have other kind of client... like a nas to do that... Why I need the cloud?

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

#347

Post by vishnumohandas »

creato wrote: post #198
vishnumohandas wrote: post #149

Earlier quoted context omitted.

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…

Core ML and TFlite are just tools for running ML models. Generating the models is the hard part, and that is what encryption will make more difficult.

We will resort to models that are available in the public domain.

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

#348

Post by vishnumohandas »

cientifico wrote: post #346
vishnumohandas wrote: post #69

Earlier quoted context omitted.

> So you're going to implement algorithms then? Yes, we will implement the algorithms, purely on the client side, such that we don't hold indexes to your personal data. But I understand how that piece of text could have thrown you off, I'll think of ways to rephrase it. Thanks for pointing it out.

But that will mean that for every version of the algorithms, it have to read all the photos since 15 years ago... my phone battery will die soon. And if I need to have other kind of client... like a nas to do that... Why I need the cloud?

> phone battery will die soon

Indexing will be opt-in. You will be able to run the indexing only on your desktop client for instance.

> Why I need the cloud?

So that you don't have to manage your own storage infrastructure? But if you would like to do that, then there are self-hosted alternatives that will better serve your use case.

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

#349

Post by beingflo »

vishnumohandas wrote: post #196
ignoramous wrote: post #170

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 compe…

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?

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

#350

Post by cdrini »

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 trust in the owners to potentially get access to the contents of my storage in extreme situations. Making that physically impossible is terrifying.
Post reply on HN