[HN Gopher] Show HN: We built an end-to-end encrypted alternativ...
___________________________________________________________________
Show HN: We built an end-to-end encrypted alternative to Google
Photos
Hello HN, Over the last year we've been building ente[1], a
privacy-friendly, easy-to-use alternative to Google Photos. We've
so far built Android[2][3], iOS[4], web[5] apps that encrypt your
files and back them up in the background. You can access these
across your devices, and share them with other ente users, end-to-
end encrypted. You can also use our electron app[6] to maintain a
local copy of your backed up files. We've built a fault-tolerant
data replication layer that replicates your data to two different
storage providers in the EU. We will be providing additional
replicas as an addon in the future. We're relying on libsodium[7]
for performing all cryptographic operations. Under the hood it uses
XChaCha20 and XSalsa20 for encryption and Argon2 for key
derivation. We have documented our architecture[8] and open-
sourced our clients[9]. We did a soft-launch on r/degoogle[10]
sometime ago, and have since then ironed out issues and polished
the product. But we are far from where we want to be in terms of
features (object and face detection, location clustering, image
filters, ...) and user experience. We are hoping to use this post
as an opportunity to collect feedback from fellow hackers. If
there's anything we can do better, please let us know, we would
like to. Best, - Vishnu, Neeraj, Abhinav [1]: https://ente.io
[2]: https://ente.io/apk [3]:
https://play.google.com/store/apps/details?id=io.ente.photos [4]:
https://apps.apple.com/in/app/ente-photos/id1542026904 [5]:
https://web.ente.io [6]: https://github.com/ente-io/bhari-
frame/releases/latest [7]: https://libsodium.gitbook.io [8]:
https://ente.io/architecture [9]: https://github.com/ente-io
[10]:
https://www.reddit.com/r/degoogle/comments/njatok/we_built_a...
Author : vishnumohandas
Score : 692 points
Date : 2021-08-29 15:23 UTC (7 hours ago)
| explodingcamera wrote:
| This is looks super cool, however not something I'd be interested
| in using myself if I can't selfhost it (at least it looks like
| thats not possible from the website).
| lol1lol wrote:
| self hosting is not worth the time and effort.
| andrewmunsell wrote:
| That is not categorically true.
|
| On the business side, there's plenty of companies that have
| offered and succeeded with self-hosted software. On the
| client side, there's many individuals like myself willing to
| dedicate time, money, and effort to self-host services. I
| spent quite a bit of time setting up my NAS with self-hosted
| services, not only because the number of photos and media I
| store would be prohibitively expensive to host elsewhere (I
| do photography and videography as a hobby, 120 fps 10 bit
| footage adds up), but because I enjoy the hobby.
| lol1lol wrote:
| we have so many consumer facing apps. you'd want to
| maintain all those and actually have a life to use those?
| good luck!
| YPPH wrote:
| Self-hosting a zero knowledge service is probably unnecessary.
|
| If you're hosting the service, there's no need for data to be
| encrypted client-side. Unless, of course, you were intending on
| running the service on a public cloud which you didn't control,
| but that's something I don't think many privacy conscious folk
| would do.
|
| There's plenty of open source, self-hosted alternatives to
| Google Photos.
| cdata wrote:
| To me it is a canary signal that I have the option to self-
| host.
|
| Most likely, QoS would be better from ente's hosting and I
| would be inclined to take advantage of that. An open source
| server can be audited and offer an off-ramp should their
| service no longer suit me.
|
| Then again, the economics of enabling self-hosted
| infrastructure are probably less exciting compared to locking
| users in to marked-up, white-labeled infrastructure.
| user-the-name wrote:
| How do you know it's zero knowledge?
| mynameismon wrote:
| https://ente.io/transparency/
| user-the-name wrote:
| That's just a non-binding promise. If that's enough for
| you, you don't need encryption at all.
| commoner wrote:
| I think the correct link is: https://ente.io/architecture
| user-the-name wrote:
| Again, just a promise.
| YPPH wrote:
| The source code of the client-side apps appears to be
| available on GitHub. So if they're bluffing, it won't be
| too long until someone calls them out on it.
| user-the-name wrote:
| Unless they only send compromised code to you personally
| and nobody else.
| dane-pgp wrote:
| One way to mitigate that is through Binary Transparency,
| which would allow people to detect if a release is made
| for which there is no source code available (assuming the
| project already has reproducible builds). There is
| already a project attempting this for Arch Linux
| packages[0].
|
| Of course it's still possible that an update could be
| sent to everyone which contains some code that only runs
| when a certain username is entered, so users would need
| to avoid updating the app until an audit by a trusted
| third party had approved it.
|
| [0] https://github.com/kpcyrd/pacman-bintrans
| TheRealPomax wrote:
| Without a fully described mechanism to confirm that the
| client you download is not compiled with additional code
| (i.e. without specifying exactly how the client is
| compiled, using which version of which compiler, and
| which compile flags, dependency versions, etc) any kind
| of "the code seems to be on github" is kind of
| meaningless.
| dane-pgp wrote:
| Ideally they should support reproducible builds so that
| anyone can confirm that the hash of the app corresponds
| to a specific tag on the source repository. Unfortunately
| app stores are making it harder to know what the hash of
| the app you are installing is, but for side-loading this
| should still be possible.
|
| For web apps, the situation is even more difficult, but
| there is a technique called Secure Bookmarks which allows
| you to confirm that a specific bundle of JavaScript is
| running (at the expense of some usability):
|
| https://coins.github.io/secure-bookmark/
| ignoramous wrote:
| F-Droid supports reproducible builds. Any serious FOSS
| app, I think, _must_ priortise publishing to F-Droid.
| sam0x17 wrote:
| Yeah, having attempted to operate a service very similar to
| this (only more focused on general encrypted cloud storage) I
| will say there are no good economics in usage-based billing.
| You're much better off selling a license to use the software
| and give users the ability to use common cloud storage
| providers (minimally the s3-compatible ones but also things
| like Google Drive) as the backing for this. Even safer from a
| legal perspective would be not having accounts at all and
| allowing users to purchase a 1-year license based on license
| keys that are cryptographically validated but not stored
| anywhere. Then it's impossible to do anything user specific
| whether you are compelled to or not.
| hackwa wrote:
| I've been using ente for a while now. The user experience has
| potential for improvement but overall I've found it worth the
| tradeoff. The client app itself is super clean and it feels great
| to not be thinking about giving more of my money and data to
| google or amazon or fb. Take my money!
| meibo wrote:
| 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.
| mixmastamyk wrote:
| Curious about the details of how you were duped.
| Brajeshwar wrote:
| Ouch! This is costly. I'm still shopping for a Backup or a
| parallel solution to Apple Photos.
|
| At $14.99 /mo for a 1TB storage or even the discounted Indian
| pricing of [?]999 /mo; I would put it at a high price point for a
| Photo Service/Tool.
|
| Just a thought. I'd priced it similar to Google Photos but sell
| the encrypted/privacy part as a prominent feature.
| [deleted]
| pgrote wrote:
| I noticed on one of the screenshots there are buttons labelled
| "When in Rome" and "Christmas 2019". What do the labels
| reference? Are you using tags added from the photos metadata?
| Thanks!
| vishnumohandas wrote:
| Those are manually created album names. We don't have automatic
| clustering enabled yet. But it is in the pipeline and we hope
| to ship it later this year.
| oyebenny wrote:
| I am not using this. Sketch.
| ridaj wrote:
| What are your plans for when your app is found to host content
| such as terrorist executions, child porn, etc.? (This isn't
| trolling, it's something that eventually happens with every
| product, and I've been wanting a non-Google version myself but
| wondering how that kind of abuse would be dealt with.)
| koheripbal wrote:
| The answer to this question is why the only solution in the
| long run is local storage.
| imhoguy wrote:
| Just imagined a distopian future where storing data locally
| would be illegal, for the society good of course /s
| mynameismon wrote:
| I don't think they would be able to do anything about it, since
| (from what I could infer from reading) it is zero-knowledge, so
| no one from the company can access the pictures. I might be
| wrong, though
| user-the-name wrote:
| Yes, and that is a _problem_.
| mynameismon wrote:
| What is the problem/why is there a problem?
| shuckles wrote:
| When push comes to shove, technology is subservient to
| society: https://en.m.wikipedia.org/wiki/Lavabit
| user-the-name wrote:
| Well, first and foremost, if I ran a service, I would not
| want to help either terrorists or pedophiles. I would be
| very unhappy if I was doing that.
|
| Secondly, if you _do_ provide service to terrorists or
| pedophiles, and take no steps to stop doing so, law
| enforcement and society in general is not going to be
| very happy with you.
| [deleted]
| cf_ wrote:
| Well, depending on legislation, they could be ordered to
| change the code to send the user password to them on next
| login for that account and then decrypt everything...
| [deleted]
| commoner wrote:
| The architecture of Ente (https://ente.io/architecture)
| prevents your unencrypted master key from being exposed to
| the server. The password authentication appears to be
| client-side, which means that the data could not be
| compromised solely by a malicious server-side change.
|
| Now, Ente could still change its web application to somehow
| leak the master key and not disclose the changes in the
| source repo. One solution for this vulnerability is to
| package the entire web client as a browser extension, which
| is what Mega is doing:
|
| https://github.com/meganz/web-extension
| dane-pgp wrote:
| There are a couple of other ways to mitigate the problem
| for web applications. If you're willing to install a
| browser extension, then it might make more sense to use
| the Signed Pages extension[0] which applies PGP signature
| checking to web pages. The other solution is to use
| Secure Bookmarks[1], which combine SRI integrity hashes
| with Data URIs to ensure that a fixed bundle of
| JavaScript is running in the page.
|
| [0] https://github.com/tasn/webext-signed-pages
|
| [1] https://coins.github.io/secure-bookmark/
| lol1lol wrote:
| something that only showed up in mainstream media 10 years
| after smart phones got launched. gawd.
| claudiojulio wrote:
| It is not possible to prove this, because the photos are
| encrypted.
| thesuperbigfrog wrote:
| Encrypted content can be decrypted.
|
| Links and data tranfers can be traced.
|
| Warrants and suponeas can make such traces / actions legal.
| olah_1 wrote:
| the answer is right here https://ente.io/transparency
| sobriquet9 wrote:
| It does not say how often it is updated. Wouldn't it be
| better to say "as of 8/29/2021, we have received no such
| requests and we are updating this page monthly".
| sam0x17 wrote:
| Yes, this is a good first step towards a true warrant canary,
| but you need to date it and provide a cryptographic hash of
| the content.
| cf_ wrote:
| Since it's a paid service with user accounts. You would be able
| to ban users that have been reported to use this service for
| illegal means. The same question can be asked to WhatsApp /
| iMessage / Signal / etc.
| pkursawe wrote:
| No thanks. My interest in cloud based e2e services is at 0%. I
| want a local only, AI based photo (video) solution and I am
| willing to pay good money for it (100/year) if: - its extendable
| via plugin system - integrates well into Windows Explorer,
| Finder, Browser, Media Servers - might be open source to fix bugs
| myself
| llIIllIIllIIl wrote:
| Awesome work. Although the price is 5x of google's, the privacy
| is worth it.
|
| Is there a family plan? We currently have 200gb google photos
| plan with my wife, but to migrate we have to take 1000gb plan
| (which we fill maybe in 8 years at current pace of adding
| content). Maybe something in between 100gb and 1000gb would find
| it's audience.
| abhinavDev wrote:
| Yes, we have both a 100GB and a 1000GB plans, you can check
| them on https://ente.io/#pricing
| llIIllIIllIIl wrote:
| Exactly my point. I'm getting close to 200gb, but it's gonna
| be a while I reach 1000gb. So essentially i'll be paying for
| the space I don't use for years.
| vishnumohandas wrote:
| Sharing my response to a similar question we ran into on
| reddit[1].
|
| > Our pricing is structured such that the 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 close to 30%.
|
| > So if we bring in an intermediary plan (say 500GB), we
| would have increase the pricing of the 1TB plan (since at
| least 50% will now be utilized), and also set the price of
| the 500GB plan to around 2-2.5x of the 100GB plan.
|
| > This seemed like a lose-lose situation for everyone with
| growing storage needs.
|
| > Since Apple and Google don't support per GB billing yet
| (which IMO would have been the fairest way to go), we had
| to pick buckets, and the current ones seemed like the
| fairest possible.
|
| --
|
| I hope this makes sense. Please let me know if we can do
| better.
|
| [1]: https://www.reddit.com/r/enteio/comments/p4m0ee/more_p
| rice_t...
| sharps1 wrote:
| Pricing is expensive comparing it to mega
| (https://mega.io/pro). Mega is end to end encrypted as well
| (Mega is 2tb for $118. Source code is also available
| https://mega.io/sourcecode).
|
| Why would someone pick your service?
| vishnumohandas wrote:
| ente is focused towards solving the sole problem of photo
| storage and organization while Mega serves as a general
| purpose drive. The product is in it's infancy right now.
| Once we have search and indexing, the difference will
| hopefully be clearer.
| surfsvammel wrote:
| I like the look of this, and I'll keep watch on it. But, all the
| negative comments here (even those which are well founded) really
| is discouraging. Must be absolutely horrifying to post your
| product on Show HN
| vishnumohandas wrote:
| Thank you! :)
|
| The point of this post was to be critiqued, and we think
| everyone has their hearts in the right place.
| 12ian34 wrote:
| Love the idea, sounds like a lot of hard work has gone into it
| already. I have been looking for this kind of thing to replace
| Google Photos. I checked out the website and couldn't find enough
| about the app's usability. So, I downloaded the (android) app
| hoping for some kind of demo or further insight into the UX but
| it's asking me to sign up or login. I guess I'll sign up anyway
| because I'm curious, but I'd have preferred a demo of the app
| first, especially since I really love the UX of Google Photos
| which is one of the main reasons prolonging my desire to replace
| it
| vishnumohandas wrote:
| Hey, we know that we should have a demo video of sorts so that
| you don't have to sign up to experience the product. It's due
| to a lack of resources that we don't have one yet. But we will
| prioritize this. Sorry for the trouble, I hope it's worth it.
| perryizgr8 wrote:
| This looks very good and the pricing plans are reasonable.
| However I want something locally hosted. I will pay to buy the
| software and run it on my own equipment. I really don't want to
| keep paying a subscription perpetually in order to store my
| photos.
| vishnumohandas wrote:
| Thanks! ente is currently not directed at an audience that has
| the knowledge to set up and maintain a reliable storage
| infrastructure. We had started off on the self-hosting route
| and then realized the difficulties in scaling such a product in
| the consumer space. So we have for now decided to direct our
| limited bandwidth into making the product accessible. Sorry
| about that.
| perryizgr8 wrote:
| No worries, I understand. Congrats on the launch and good
| luck!
| chmod775 wrote:
| Very reasonable pricing, though you could advertise the free
| 'trial' tier a bit more prominently. I thought the service was
| paid only until I re-checked the pricing page and read the tiny
| gray on black text before writing this comment.
|
| You also didn't set a single tracking cookie. Nice.
| vishnumohandas wrote:
| I'll increase the opacity of that line, thanks for the
| feedback!
| yasuocidal wrote:
| Can it be linked to a personal server? I have been doing backup (
| over SFTP ) to a rasberry pi with an external HDD for storage. So
| far its great but i can not view the photos, i have to download
| them to view them.
| cf_ wrote:
| Looks great - congratulations! Could you please add if / how you
| store a hash of the user password of authentication - it's not
| discussed on the architecture page. Thank you.
| vishnumohandas wrote:
| We don't store your password's hash. Since we use authenticated
| encryption, clients can identify when the decryption of your
| masterKey fails because you used a key generated from a wrong
| password.
| cf_ wrote:
| Ok, that's cool! But the client get's to download the
| encrypted master key without authentication, right? Doesn't
| that enable easy offline attacks or is the decryption too
| time-consuming?
| vishnumohandas wrote:
| No, the client has to first verify their email address and
| 2FA (if configured) to receive the encrypted keys. In
| addition to this the decryption is time-consuming.
| DenisM wrote:
| 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.
| vishnumohandas wrote:
| 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...
| abidomar wrote:
| Congrats! Love the product. I can see myself switching to ente
| very soon.
| Jnr wrote:
| If you still want to use the algorithms but keep the data private
| (self hosted and open source), I can suggest Librephotos. It has
| face detection, object detection, place markers, etc. It is not
| perfect but from what I have seen, it's currently still the best
| self hosted open source solution.
| sabujp wrote:
| what are currently the best open source projects that allow you
| to fully automate and manage deployment of your own personal (or
| multi-user) cloud photos/drive storage service? I found:
| [1]: https://github.com/nextcloud [2]:
| https://github.com/Piwigo with S3 extension:
| https://piwigo.org/ext/extension_view.php?eid=691 [3]:
| others https://arstechnica.com/gadgets/2021/06/the-big-
| alternatives-to-google-photos-showdown/ which mentions the most
| feature packed to be https://photoprism.app/
| summm wrote:
| Or, just syncthing, if you don't need a specializes photo web
| interface. They apparently added support for client-side
| support recently, so you can put it on some random vserver as
| well.
| benbristow wrote:
| 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 where the real value of Google Photos comes
| into play.
|
| > But we are far from where we want to be in terms of features
| (object and face detection, location clustering, image filters,
| ...) and user experience. We are hoping to use this post as an
| opportunity to collect feedback from fellow hackers.
|
| So you're going to implement algorithms then?
| bshoemaker wrote:
| I want none of those features.
|
| I want automatic backup, easy sharing, and accessibility from
| all devices.
| bsanr2 wrote:
| >lets me search my library using text search for anything
|
| This is untrue, and actually one of the reasons I hope a strong
| competitor to Google Photos comes along soon. The search
| function is, for whatever reason, heavily censored and perhaps
| even biased in some circumstances. Worse, it is completely
| useless. For example, the query "fat" returns nothing, despite
| the fact that my gallery is filled with drawing reference
| photos that includes plus-sized people. "Black people" returns
| photos of non-black people, and (infamously, and perhaps for
| related reasons re: the shortcomings of Google's image
| recognition and tagging algorithm) "gorilla" returns 0 results.
| "Red shirt" returns an image of a blue decorative screen;
| "comic" returns anime and webpage screenshots; "woman" returns
| multiple photos consisting entirely of groups of men.
|
| The situation is dire.
| benbristow wrote:
| Think of it from Google's POV. Imagine if the tabloids found
| out about a situation of someone searching for 'fat' in the
| search bar and then it coming back with pictures of
| themselves or their friends - that could cause some serious
| controversy.
| barbazoo wrote:
| > If I wanted to just store my photos I'd throw them in a S3
| bucket or Dropbox or something.
|
| Neither of those give you any privacy unless you do the
| encryption yourself in which case you have to build something
| to access them unencrypted. Have you checked out what the
| service actually does?
| ipaddr wrote:
| Wouldn't a mega encripted folder make sense for the average
| person?
| barbazoo wrote:
| Let's say you store your photos in Dropbox but inside an
| encrypted folder. What would you have to do to view the
| photos? Unless there client you encrypt your files with has
| a photo viewer, you'd have to download the pictures and
| decrypt them to look at them. The whole thing becomes very
| inconvenient very quickly.
| tomxor wrote:
| We need to make this stuff local again, that will be the real
| competitor to big corp Foo... no servers, no end-to-end, no
| service cost, no ads, no privacy issues, no random revokation
| of accounts without recourse, just one end - the users. We can
| have face detection etc locally if people want it... cycles,
| it's going to happen eventually.
| alisonkisk wrote:
| we had that, but almost everyone decided they like the cloud
| better.
| mfer wrote:
| To think that someone can just throw their photos in s3 assumes
| people are ops, devils, or devs. That's a small slice of the
| population. What about everyone else?
| joelbondurant wrote:
| You're right, a few hours of work on top of S3 are needed to
| obviate Google Photos.
| benbristow wrote:
| I also mention Dropbox. I haven't used it for a while though
| peakaboo wrote:
| I don't want Google at all in my life, so I think this product
| seems very attractive. But of course it depends on the user,
| what they value.
| LightG wrote:
| You're willing to pay the price of those algorithms and the
| Google ecosystem. Others are not.
|
| I'm excited to review this project. Thanks to the creators.
|
| This has come at a perfect moment ... as, this weekend, I'm
| literally downloading my entire Google photos archive (one year
| at a time) to my local harddrive and figuring out a way
| forward.
|
| I'm done with Google after a 'straw breaking the camels back'
| moment with their payment system.
| alisonkisk wrote:
| Why not use Takeout to download all at once?
| vishnumohandas wrote:
| > 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.
| natch wrote:
| You can run algorithms locally and still violate privacy by
| uploading private facts derived from the data with
| algorithms. Saying you won't hold "indexes" doesn't begin to
| cover it.
| Moodles wrote:
| Well, it does _begin_ to cover it. Do you have to be so
| strident?
| godelski wrote:
| Actually I'm really curious how you do this. If the photos
| aren't stored client side, then how do you search? Do you
| have a thumbnail of every photo client side? Is that enough?
| I mean ImageNet scores are still pretty low for small/fast
| neural nets. And ImageNet isn't even representative of real
| world photos. So obviously to be successful you're going to
| have to continue training. So how do you do this in a privacy
| preserving way? Even federated learning can have some issues
| because images can be reconstructed from gradients.
| vishnumohandas wrote:
| > 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 off
| between user experience and privacy here, and we are
| hopeful that ente will be a viable option for an audience
| who is willing to sacrifice a bit of one for a lot of the
| other.
| godelski wrote:
| So I guess there is more to the question that I'm asking.
|
| > Our accuracy will not match that offered by services
| who index your data on their servers. But there's a trade
| off between user experience and privacy here,
|
| I think most people here understand that[0]. We are on
| Hacker News after all and not Reddit or a more general
| public place. The concern isn't that you are worse. The
| concern is that your product has to advance and get
| better over time. That mechanism is unclear and
| potentially concerning. The answer to this is the answer
| to how you ensure continued privacy.
|
| You talk about the "push files/thumbnails for indexing"
| and this is what is most concerning to me and at the
| heart of my original question. How are you collecting
| those photos for _your_ training set? Obviously this
| isn't just ImageNet (dear god I hope not). Are you
| creating your own JFT-300M? Where are those photos being
| sourced from? What's the bias in that dataset? Obviously
| there are questions about the model too (CNNs and
| Transformers have different types of biases and see
| images differently). But that's a bigger question of
| training methods and that gets complicated and nuanced
| fast. Obviously we know there is going to be some
| distillation going on.
|
| There's a lot of concerns here and questions that won't
| really get asked of people that aren't pushing privacy
| based apps. But the biggest question is how you get
| feedback into your model and improve it. Non-privacy
| preserving apps are easier in this respect because you
| know what (real world) examples you're failing on. But
| privacy preserving methods don't have this feedback
| mechanism. We know homomorphic encryption isn't there yet
| and we know there are concerns with federated learning
| (images can be recreated from gradients). So the question
| is: how are you going to improve your model in a privacy
| preserving method?
|
| [0] I think people also understand that on device NNs are
| going to be worse than server side NNs since there's a
| huge difference in the number of parameters and
| throughput between these and phone hardware can only do
| so much.
| vishnumohandas wrote:
| > how are you going to improve your model in a privacy
| preserving method
|
| We will not improve our models with the help of user-data
| and will resort to only pre-trained models that are
| available in the public domain.
| rock_hard wrote:
| 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!
| vishnumohandas wrote:
| 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 accuracy in search
| results, and we think that for some of us the reduced
| accuracy might not be a deal breaker.
|
| [1]: https://developer.apple.com/documentation/coreml
| creato wrote:
| 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.
| divbzero wrote:
| Up until recently I've used Apple Photos happily since it
| provided a good combination of convenience plus the
| privacy of on-device recognition. You have a compelling
| product if you can convince customers you are as reliable
| and more trustworthy than Apple. You do face the
| disadvantage of not being the default option for
| iOS/macOS but that should be balanced by being available
| cross-platform in Android, Linux, Windows.
| [deleted]
| godelski wrote:
| To be honest, that wasn't a concern with my question. I
| think most people on HN understand this aspect. My
| question was more about how you improve your models when
| you don't have the same feedback mechanisms as non-
| privacy preserving apps. Google can look at your photos
| and see what photos fail and collect the biased
| statistics. In a privacy preserving version you won't be
| able to do this. Sure, you can on an internal dataset,
| but then there are lots of questions about that dataset's
| bias and if it is representative of the real world. I
| mean how many people think ImageNet is representative of
| real world images? A surprising number.
| Nalta wrote:
| 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.
| finnh wrote:
| 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?
| leppr wrote:
| For me the features that make Google photo, Google photo are:
|
| * it's free and comes by default with an Android phone.
|
| * it just works.
|
| If you can make an effortless way to get online backups of my
| photos at a reasonable price while regaining privacy, then I'll
| switch in a heartbeat without a single thought about any of
| those ML-based moat features Google has crammed in their
| service.
| OneEyedRobot wrote:
| >So you're going to implement algorithms then?
|
| Jeesh, that's easy.
|
| You encrypt the algorithms too.
| gizdan wrote:
| On top of this, good algorithms should be run if it is possible
| to do it in a privacy friendly way.
| tssva wrote:
| Besides search another feature of Google Photos that I would
| need is automatically inclusion of photos in shared albums
| based upon who is in them. Some examples:
|
| I have an album shared with my parents which photos of my
| daughter are automatically added to.
|
| I have an album shared with my daughter which photos of our dog
| is automatically added to.
|
| I also like the collages, slideshows, movies and this day x
| years ago photos which Google Photos automatically creates and
| notifies me of.
| Aspos wrote:
| Those "algorithms" can run locally, on a NAS or a desktop,
| generate the metadata and make it available to you only on your
| mobile.
|
| I can see myself paying for such software if it was mature
| enough.
| izacus wrote:
| Synology Photos is one such solution already for example.
| Aspos wrote:
| I have Synology, actually. Is Synology Photos trustable?
| chias wrote:
| The software with these features is called Synology
| Moments. I use it and I mostly love it, at the very least
| as a backup for my Google Photos.
|
| My experience is that it works great, provided that
| you're on your local network. When away from home or
| traveling, less so. Maybe I could configure things better
| to alleviate that, I don't know, but I haven't managed to
| yet.
|
| Sharing is less convenient. Trying to share a photo on-
| platform is a terrible experience for the receiver with
| multiple slow redirects, so much so that generally if
| you're on mobile it's easier/better to just download the
| photo to your device and share the photo directly. The
| Moments android app has a flow for doing this, which is
| nice. It also makes a certain amount of sense: the
| alternative would be others connecting to your NAS
| online, which is always going to be less nice than just
| connecting to Google photos.
|
| The search capabilities are pretty decent. It can
| recognize people and tag them appropriately. It can
| recognize some things. In some ways, I prefer searching
| it over searching Google Photos. But again, only if
| you're on your local network with your NAS.
|
| --
|
| Edit: see aborsy's response to me below. Looks like I'm a
| version behind. Maybe on-platform photo sharing is better
| now, I'll update the software and check it out
| aborsy wrote:
| In DSM 7, it's called Synology Photos!
| chias wrote:
| Thanks for the heads up! Looks like I have an update to
| install :)
| pininja wrote:
| For at-home NAS, is Synology the best for recreating
| Google services?
| fma wrote:
| I've had Synology for years and I have used their Photos
| and Momemts app.
|
| It's pretty dang hard to recreate a Google service.It's
| great for backup and have control over the photos - but
| dang it's slow....if I need something real quick, I
| usually go to google photos...even when I'm home. Maybe I
| need to upgrade to a NAS w/ faster processor, I don't
| know.
|
| I've turned off the Google Photos facial recognition
| stuff because of privacy, but dang I miss the
| convenience. Moments has their own but it's not a good.
|
| Google photos I can easily search for a city or text or
| an object and it pops up quickly.
| xur17 wrote:
| It's the best I've found so far. They have a number of
| apps (docs, drive, moments, etc), and I wouldn't say they
| are as good as Google right now, but they are quite
| workable.
| TedDoesntTalk wrote:
| In Love my synology. The differentiator between NAS
| devices is not the hardware but the software.
| mackrevinack wrote:
| i have one myself and i would say its the best out of all
| the alternative nas's out there. you pay a bit extra but
| its worth it considering how easy it is to setup. i also
| paid a bit more extra for the plus model so i could run
| docker which in turns gives you a huge selection of other
| apps over the built in apps or the synocommunity apps
|
| https://github.com/awesome-selfhosted/awesome-selfhosted
| chrisseaton wrote:
| > Those "algorithms" can run locally
|
| But I don't want my GPU burning away running them when they
| could run much more efficiently and out of mind in the cloud.
| gpm wrote:
| Then you aren't the target audience?
| sillysaurusx wrote:
| 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 an established
| product. New ideas tend to win by transcending the competition.
|
| I propose that if this Show HN turns into a product, it will be
| because it does something people didn't realize they wanted.
| Maybe that's privacy. I don't know.
| smolyeet wrote:
| There's more you can do honestly. Search and and assign
| people so you can find picture with just them. This also
| works for pets. People, pets , objects, place, etc. Hell, I
| searched the car I use to drift and it showed up. It's really
| neat.
| mynameisash wrote:
| 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.
| hawaiianbrah wrote:
| The search is really quite fun to play with, and very useful!
| I also like searching on the map and seeing where I've taken
| photos. Especially if I'm looking for one particular photo,
| it's fun to zoom in from the world map
| sillysaurusx wrote:
| Thanks for pointing that out. I actually had the
| opportunity to sync my iPhone photos to Google Photos, but
| opted to decline. This made me reconsider; cheers.
| Jcowell wrote:
| Why would this feature , that is also apart of Photos,
| make you reconsider ?
| sillysaurusx wrote:
| As much as I like apple / iCloud / my iPhone, I do like
| the idea of seeing all the places on a map that I've
| traveled with my lovely wife Emily. We're hoping to go to
| the Seychelles if the next three months work out at my
| contract gig.
|
| I like the idea of being able to type "water" and see a
| bunch of water bottles mixed in with all the water-y
| places we've visited.
|
| What sealed the deal was to see it on a map. I typed
| "water" into Photos just now, and it did a pretty good
| job. But there's something peculiar about being able to
| look at a pin and say "I've been at that pin."
|
| Just a silly thing. But it costs me nothing to get it, so
| I want it.
| smallerfish wrote:
| I use it all the time - it's the killer feature of google
| photos. The premise is that if you come back from vacation
| with 300 photos, it's unlikely that you (the average non
| photography-nerd user) are going to sit there and tag them
| all. If in a few years you want to find "that photo of me you
| took on the beach in north carolina", with a quick search you
| can.
|
| There are annoying limitations though, probably because the
| original team moved on and it's in maintenance stage. Using
| my example above, google photos has no idea what the "outer
| banks" are (which is where the beach photos were taken in
| north carolina) and returns no results. It also has trouble
| parsing out entities from search terms, so "north carolina
| beach maggie" isn't going to find pictures of Maggie on the
| beach in North Carolina (which you'd think they could really
| fix given that, well, they're google). Finally, there's no
| way (that I know of) to jump from search results to your full
| timeline; let's say that "north carolina beach" gets me a
| bunch of beach pictures from January 2015 (yeah, it was
| cold), but doesn't have _the_ picture from the trip that I
| know I want - there's no direct way to click to January 2015
| from the results, which really sucks. (Instead you have to go
| back out of results and use their fiddly scroll to get
| there.)
| joelbondurant wrote:
| Nah, a couple gigs of free storage is Google's killer
| feature. Photo organization is braindead simple and barely
| requires more than S3.
| jokethrowaway wrote:
| I try to use it often but it works pretty poorly and I
| always have to scroll through years of photos to look for
| what I need.
|
| For me the killer feature of Google photos are: - Free
| storage of photos (hence why I'll move after I run out of
| free space) - Tagging faces - Sharing albums
| ipaddr wrote:
| It's a great idea that works in a limited way. Getting that
| next 30% is going to take awhile nevermind natural language
| queries.
| tsycho wrote:
| Yeah, it's a killer feature, but I really wish they had
| some sort of a documented "search API".
|
| Instead of natural language search, where I have no idea
| whether it understood me, I wish I could do (modifying your
| example):
|
| "North Carolina" "Maggie Thomson" "Tom Morgan" -beach 2018
|
| for all photos in NC, with Maggie and Tom, not in a beach
| from 2018
|
| and even better, if it could tell me the number of results
| that would show up if we removed each keyword above.
|
| I guess it's a tough problem, even for Google :(
| roothog wrote:
| > there's no direct way to click to January 2015 from the
| results, which really sucks. (Instead you have to go back
| out of results and use their fiddly scroll to get there.)
|
| It's amusing how people's insights can turn myopic. Search
| in photos is the killer feature, and it even solves the
| problem that you have.
|
| If you realize that you need to see photos from January
| 2015, don't try to scroll back in your photos feed. Just do
| a second search for "January 2015".
| smallerfish wrote:
| That's worse than click-to-this-photo-in-context though.
| Maybe I have 4000 photos from January 2015, so it doesn't
| help to search for the month.
| scandox wrote:
| Personally I'd find the pure storage and basic categories
| suitable. I dislike almost all the algorithms. Especially
| "memories" and shit like that.
|
| Simple and reliable backup and reasonably speedy browsing is
| what I need.
| barbazoo wrote:
| I've been craving a service like this for a long time!!! I'll
| check it out asap.
| usrme wrote:
| Looks great, but based on my limited time with it:
|
| - when registering via the Android application I got no 1Password
| prompt to fill in the fields; this is usually the case with other
| applications - there doesn't seem to be an option to back-up
| single photos, only whole directories; why is this?
| vishnumohandas wrote:
| Hey, sorry that the 1Password prompt did now pop up. We'll look
| into this.
|
| Regarding the lack of option for backing up individual files,
| currently that option exists only on iOS since the OS provides
| users with an option to grant permission to a few files instead
| of their entire gallery.
|
| There are two ways to work around this on Android right now:
|
| 1. Share a file from outside the app to ente.
|
| 2. Skip the folder selection, choose the file you want to
| backup from your device folder, and add it to an album (you
| will be prompted to create an album if none exist).
| sturza wrote:
| Is there a way to "one click" move from google photos?
| vishnumohandas wrote:
| Currently no. You have to manually export your data from
| takeout.google.com.
|
| We are optimistic that with the Data Transfer Project[1],
| Google will eventually expose APIs for us to perform this
| migration programmatically.
|
| [1]: https://datatransferproject.dev
| Shank wrote:
| I'll bite. I think you've got a really really promising product
| here. The one thing I'd add is that at least from initial
| testing, the iOS app doesn't detect and offer to backup nested
| albums. Specifically, I have an album with another album nested
| inside, and then another three albums nested inside that. The
| first album and second album contain no photos, but the 3rd level
| down does, and the app doesn't see them.
|
| Other than that, I think you've got a really seriously good
| product here. libsodium + XChaCha20 is really really good in
| terms of encryption technology. You've picked all of the right
| things! Well done :)
| Gargyle wrote:
| But forgotten to sign commits and establish a trust chain.
| vishnumohandas wrote:
| We hadn't tested out nested albums scenario you pointed out
| yet, will get this fixed.
|
| Thank you for the feedback! :)
| ant6n wrote:
| Very interested in this. She questions:
|
| How does one migrate to this from Google photos?
|
| How does one share across the family?
|
| Is it possible to have a local backup (e.g. on my desktop) in
| case something goes wrong?
|
| What are plans for features beyond just storing photos
| (categorizing, tagging, labelling, albums, comments/notes,
| geotags, stories, etc.)?
|
| What's the pricing?
| vishnumohandas wrote:
| > How does one migrate to this from Google photos?
|
| You can export your data from takeout.google.com, and drag and
| drop the output folder into web.ente.io.
|
| > How does one share across the family?
|
| Currently we don't have family plans yet. Existing customers
| are sharing the same account with their partners. This is on
| our roadmap and we will ship it soon.
|
| > Is it possible to have a local backup?
|
| Our desktop app[1] has an option to sync your uploaded data to
| a local disk drive.
|
| > categorizing, tagging, labelling, albums, comments/notes,
| geotags, stories.
|
| We already have albums and stories. All the other features you
| mentioned apart from "comments/notes" were already on our
| roadmap. I've just added "comments/notes" too to it[2].
|
| > What's the pricing?
|
| https://ente.io/#pricing
|
| [1]: https://github.com/ente-io/bhari-frame/releases/latest
|
| [2]: https://roadmap.ente.io/ability-to-add-commentsnotes-to-a-
| ph...
| ant6n wrote:
| Thanks for the detailed responses! Some more questions:
|
| a) I note the pricing is somewhat higher than Google/Dropbox,
| which is fair. But is there a way to compress the media (esp.
| videos) before uploading it to conserve some storage? (I wish
| when Google still had unlimited 'high quality', it was
| possible to store photos in original and video in hi
| quality).
|
| b) is there a way to detect duplicate photos, including of
| lesser quality, and only store the higher quality version?
| (E.g. photo comes from original device but also in a WhatsApp
| image folder because it was shared).
|
| c) assuming search is on the roadmap based on feature
| detection, are there ways to find photos based on
| date/uploading device/camera/geolocation?
| vishnumohandas wrote:
| All the features you requested for are already on our
| roadmap. :)
|
| a) https://roadmap.ente.io/option-to-compress-photos-to-
| use-les...
|
| b) https://roadmap.ente.io/deduplicate-files-p-1165/
|
| c) https://roadmap.ente.io/search-by-metadata-and-
| exif-p-2487/
|
| We will be shipping all of them.
| Rume wrote:
| I really love your product
| alex_hirner wrote:
| > two different storage providers in the EU
|
| Which ones did you choose and why?
| vishnumohandas wrote:
| BackBlaze because of their reputation.
|
| Scaleway because of their cold storage offering in a fallout
| shelter underground that reduces the risk of natural disasters.
| barbazoo wrote:
| Please please support custom storage back ends, I'd love to use
| my Dropbox or S3 or whatever to still fully own my pictures. And
| I'd love to pay extra to opt out of and analysis, tagging, etc of
| my photos. Basically I'd like the interface to be similar to
| Google Photos but with a privacy focused storage engine and
| clients.
| DenisM wrote:
| 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 everyone getting a free copy. Those people who are able to
| do it are likely to be asked for advice by their less techy
| friend, so this is basically free software to key
| influencers.... Ok, so this does not sound as exciting as it
| did before I started typing, but maybe this will lead to
| something...
| fy20 wrote:
| The problem with that is that some kind fellow on GitHub will
| clone the project, uncomment the code to enable the premium
| features for free, and change its name. If it's released
| under a FOSS license, the original authors have little
| recourse.
|
| This is what happened with Emby (a media server like Plex).
| The backend was open source and there was a license to
| activate premium features. Somebody cloned it, and then
| released the premium features to everyone for free.
| vishnumohandas wrote:
| 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 right now.
| Hopefully sometime in the future we will be able to afford
| the necessary engineering bandwidth.
| barbazoo wrote:
| I like how Joplin does it for notes. You authorize them as
| an application in Dropbox or give them credentials to a S3
| bucket. Don't get me wrong. I _want_ to pay for your
| service. I just have to be able to access and decrypt my
| files if you had to shut down your service all of a sudden.
| vishnumohandas wrote:
| Our pricing model is such that the product can self
| sustain itself. Also, we have a desktop app[1] that syncs
| your uploaded data to a local drive, so you don't have to
| worry about a lock-in.
|
| But even if we do have to sunset the service due to
| unforeseeable reasons, our cold storage is relatively
| inexpensive and we will give our customers ample time to
| migrate out.
|
| Also, in such a scenario we would want to publish our
| entire system in an easily deployable way so that all our
| efforts would not be in vain.
|
| [1]: https://github.com/ente-io/bhari-
| frame/releases/latest
| barbazoo wrote:
| I see where you're coming from and I really appreciate
| that you're taking the time to respond. I know it's
| unlikely for a service like this to shut down from one
| day to the next but it's not impossible, plus the whole
| thing about a service having the ability to shut me out
| of my own data, that's just scary. And many of us are
| already paying for storage on Dropbox and have secondary
| backups set up for instance. I'm just saying that this
| would probably convince more people to switch, leveraging
| a service they're already paying for plus whatever you're
| charging to facilitate - less than the full service with
| storage would cost but enough to make you some money as
| well. Again, offering privacy in a field that was
| previously devoid of it is a great step in the right
| direction.
| papito wrote:
| Heh. Yeah. Been building something like this, where you can
| have your choice of metadata storage and file storage. Out of
| the box, it would be Sqlite and the local FS, and then you can
| become adventurous. Postgres and S3? Elastic and S3? Sure.
|
| Needless to say, years later, I am still building it. For one
| guy doing this on my own time, it's a lift. Maybe after I quit
| my job soon :)
| barbazoo wrote:
| Is there something to share and possibly collaborate with
| others? Just now on the drive home I contemplated doing a POC
| with S3 storage but I acknowledge hoe much work that probably
| would be.
| slater wrote:
| Sidenote: are you aware that "Ente" is German for "duck"? :)
| kaycebasques wrote:
| If I recall correctly "ente" has a pleasant meaning in
| Portuguese. Google Translate says it means "loved" but I feel
| like my paperback dictionary said something else...
|
| Edit: I think it's similar to "being"
| athulca wrote:
| Since OP seems to be from Kerala it might be in
| Malayalam."ente" in Malayalam(Language of Kerala) means
| "mine".
| vishnumohandas wrote:
| This!
|
| Also, I've a thing for rubber ducks.
|
| Also, the domain was available. :)
| murukesh_s wrote:
| hey, fellow keralite here.. good domain and good luck!
| vishnumohandas wrote:
| Yes, hence the icon for "simple" @ ente.io :)
| caffeine wrote:
| What's your story for exporting from Google photos? I would
| happily use this service if it could automatically backup my
| Google Photos to protect me against the possibility of Google
| killing my accounts.
| vishnumohandas wrote:
| You can take out your Photos data from takeout.google.com, and
| drag and drop the output folder into https://web.ente.io.
|
| We understand and parse the metadata files Google generates and
| support resumable uploads.
| iknowstuff wrote:
| I tried it, but unfortunately the complete lack of auto-
| categorization in all of those e2ee photo storage apps renders
| them unusable for anyone with a large library. Ente is not the
| first one to do this, there are many others with similarly
| lacking UX, like MEGA.
|
| Both Apple Photos and Google Photos:
|
| 1. have easy search by location on a map of the world.
|
| 2. allow browsing to any date in an instant.
|
| 3. index photos by objects/faces and allow for instant searching
| - Apple even does it on-device.
|
| Also, frankly, I don't trust you to stay around for long, so I
| would appreciate the option to store encrypted photos on a cloud
| of my choosing that I already pay for, with a separate
| subscription for using your app. Not sure what the Venn diagram
| of <cares about privacy>, <willing to pay for your storage>,
| <needs excellent browsing experience> looks like.
|
| Looking forward to an app which works for people with large
| libraries. :)
| vages wrote:
| All the features you mention are already addressed in the
| original post as planned future developments. Knowing that they
| are planned makes me put my trust more in Ente than in Mega
| (which I use as an alternative to Dropbox and am very satisfied
| with). Not that there's anything wrong with confirming interest
| in their planned features; I'm just pointing Ente's plans out
| for anyone who scrolls right to the comments.
|
| As for possible bankruptcy, you can never be too certain, but
| it's easier to stay in business with Indian costs of living
| than US. (The company is located in India.)
| jijosunny wrote:
| Gotta love the progress y'all made in the last few months!
| Congrats on the launch!
| subpixel wrote:
| I like the fresh thinking, but I don't see a market for this.
|
| What I see is a market for an Instagram replacement that is:
|
| - not about filters or effects
|
| - has flexible sharing settings (e.g. you can opt-in to looser
| privacy on a per-photo basis) that default to 'private'
|
| - solves the storage and encryption of my photo library without
| me even having to understand it
|
| That last item is a feature, not a product (but could provide an
| amazing moat around the product).
| 71a54xd wrote:
| Very excited to see the source!
| mrobins wrote:
| I've been watching this project for a long time and personally am
| very excited. The fact that it's #1 on HN today (congrats!) makes
| me think I'm not the only one.
|
| There are also a lot of valid concerns in these comments about
| privacy and use of algorithms. A lot of it depends on what you're
| looking to gain by adopting a new service/switching away from
| something else and individual concern.
|
| Personally, I'm looking for a place to store personal photos:
| friends, family, travel etc. Critical needs - easy sharing
| ideally not locked into Apple's ecosystem - not to have my photos
| mined for advertising and social graph data (most important) -
| ideally around for the long haul but in my mind this is for
| sharing, not backup
|
| I'm not particularly concerned about warrants, government
| surveillance etc. Again for me this is about sharing so the
| expectation of true privacy is low. Any photos I considered
| sensitive I would store elsewhere.
|
| For me, the biggest point of confidence I have in this project is
| that they charge money from day 1 and don't have a forever free
| plan. I'm excited about projects that offer the benefits of
| "social" but where the software, not my data, is the product.
| Roritharr wrote:
| 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.
| Chilko wrote:
| Looking at their pricing for EUR0.99 / month you can get 10gb
| storage, so go at it!
| pilingual wrote:
| Re: Shared Albums
|
| >the receiver just needs a free ente account.
|
| I feel like there should be an even more frictionless option to
| make it easy for family to access photos. For example, if there
| were a way to just trigger a mailing list when an album is added
| to, that would be perfect. "Here is an update on our trip:
| [link]" I love that you mention you are security and privacy
| focused, and I see how this could conflict with that mission.
| Perhaps a tradeoff here could be allowing one viewing via link
| and future viewings require account?
| sam0x17 wrote:
| It's funny, I see this being the first feature they kill off
| unfortunately when it becomes the new super easy way of sharing
| CSAM on shady forums.
| vishnumohandas wrote:
| > if there were a way to just trigger a mailing list when an
| album is added to, that would be perfect
|
| We can do this if all of the participants are already on ente.
|
| > allowing one viewing via link and future viewings require
| account
|
| We are hoping to come up with an implementation similar to this
| where in a link to an album can be shared with N devices. We
| will persist an accessToken on the viewer's localstorage so
| that they can re-view the album multiple times without having
| to sign up.
| ignoramous wrote:
| 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.
| vishnumohandas wrote:
| 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
| players. Also none of the existing solutions provide a user
| experience that we are happy with, so we would like to keep
| building until we have something that works for us (at least).
| Also it helps that we are not very motivated by money. As long
| as we get to build useful things while being able to sustain
| our lifestyles, we will be content.
|
| --
|
| App:
|
| 1. We have been advised by our lawyers to provide no such
| guarantees. All I can say is that we follow the best
| engineering practices to make sure that possibility of a data
| loss/corruption is minimal. And in the unfortunate case that it
| does happen, we have strategies in place to minimize the damage
| by applying rollbacks and triggering re-syncs from clients. We
| will be transparent about any such event.
|
| 2. Our infrastructure is agnostic to the data type. Once we
| have reasonably polished the photos product, we would like to
| venture into other spaces where E2EE storage + sync is useful.
|
| 3. We use BackBlaze as our hot-storage and Scaleway as our cold
| storage.
|
| 4. All files are versioned. File names are not a primary key.
|
| 5. Due to the nature of our encryption protocols, we cannot
| actively look out for illegal content, but we will take down
| content that violates our ToS[1] when it is brought to our
| attention.
|
| ---
|
| Cryptography
|
| 1. The key recovery flow was hand rolled and peer reviewed,
| since we could not find existing implementations that solved
| for our use cases. We wanted the recoveryKey to be something
| that can be shared and rotated if necessary. We have reasoned
| from first principles and have relied on libsodium for
| executing the actual cryptographic operations. If you have
| specific concerns with this, please write to security@ente.io,
| we would love to engage in a conversation.
|
| Wrapped keys are sent to clients only after verifying a user's
| email address and 2FA (if configured). This is similar to what
| most other encrypted storage providers do.
|
| 2. The extra layer of authentication was added to serve as an
| implicit second factor. This ensures that even if your email is
| compromised, an attacker cannot gain access to an auth-token
| and trigger API calls that could corrupt your data. Both your
| email and password have to be compromised for them to
| authenticate against our servers.
|
| 3. If by your password being compromised you mean that all of
| your encryption keys have been compromised, you will have to
| re-encrypt and re-upload all of your data. It is difficult to
| rotate a file key without actually re-encrypting the file.
|
| 4. These are seasoned engineers who understand and have used
| high level crypto libraries to build secure infrastructure at a
| few unicorns.
|
| ---
|
| ToS:
|
| 1. We keep it around just to help users recover their data in
| case they were attacked.
|
| 2. I believe that we should be able to offer a takeout for the
| data that was not in violation of our ToS, but I would like to
| speak to our lawyers before confirming this. :)
| ignoramous wrote:
| Thanks so much for taking time to answer these.
|
| As a fellow founder/eng in the digital consumer privacy
| space, I can tell you that it remains fringe. And it isn't
| clear if it will take off in an exponential way anytime soon
| as, from what I have noticed, VC-backed startups in this
| space trying to pry out growth have indeed struggled
| (SilentCircle, as one example). Competing with free [0], as
| it turns out, may make for a decent-sized lifestyle business,
| but may not bring in VC-warranted returns (Netflix vs
| BitTorrent / Spotify vs LimeWire notwithstanding).
|
| Enterprise security and privacy remains very lucrative
| however, if you are considering pivots :)
|
| Please consider getting ente.io's cryptography reviewed by
| cryptographers. It does not inspire confidence so much so
| that I feel ente.io frontends are better used with a
| _tarsnap_ backend.
|
| Thanks again.
|
| [0] https://kk.org/thetechnium/better-than-fre/
| vishnumohandas wrote:
| Thanks for sharing your insights, I have bookmarked the
| essay.
|
| We do intend to get our architecture reviewed by
| cryptographers. It's an expensive process but we should be
| able to be able to afford it soon.
| Gargyle wrote:
| Last time I looked at your servixe it was web only and did in-
| browser crypto. This is essentially useless for 2 reasons: -
| There is no effetive Versioning. - Application and Storage-Vendor
| are the same entity. Therefore if you are hacked or coerced you
| can push code to me. The only defense is proper version pinning
| and compiling myself / taking it from FDroid.
|
| Photos are among the highest value phone data. I dont take
| chances here. You do not post the apk signing key prominently on
| your front page. Your commits are not signed. You host on
| Microsoft owned Github.
|
| Why would I trust you? This seems like yolo-development.
| arendtio wrote:
| From what I have seen, I like Photoprism [1] better. Yes, they
| are a different kind of product, but feature wise they should be
| considered a competitor.
|
| Yes, ente.io is easier to setup, but there are many things
| lacking or unpolished (e.g. the image sizes that are being loaded
| while going through the fotos fullscreen in the browser).
|
| [1] https://photoprism.app
| domh wrote:
| I just set up PhotoPrism myself this week! With it being
| completely self-hosted, this isn't something I'd be comfortable
| asking someone non-technical to do.
|
| I like that it is self hosted, it also uses TensorFlow to
| classify images so you can perform keyword searches e.g
| "museum". It doesnt appear to be as good as Google Photos
| though, e.g in GP you can search "vaccination card" and it does
| what you expect which is very impressive.
|
| Face detection is currently under heavy development also, which
| is very exciting:
| https://github.com/photoprism/photoprism/issues/22
|
| There are certainly things that are missing, but I'm okay with
| the tradeoffs for now in the hope that it will eventually
| improve.
| TingPing wrote:
| That service doesn't look like it's encrypted and not really
| equal then.
| arendtio wrote:
| So far, there isn't even a service. It is only software,
| which you can use to self-host your pictures, which can serve
| the same purpose. Both are certainly GP alternatives.
|
| Equal: no. Comparable: sure.
| judge2020 wrote:
| Off-topic, but why is the color for regular text on HN text posts
| so light? For comments, it indicates a downvoted comment, but
| seemingly all text posts are this grey color.
| detaro wrote:
| AFAIK to discourage people from using them, it's preferred that
| you submit links. (I think they also get ranked worse)
| diebeforei485 wrote:
| I'm curious what challenges you've faced on iOS -- for example,
| has Apple made it difficult to implement background sync?
| vishnumohandas wrote:
| We are still facing challenges with the reliability of
| background syncs on iOS. There is a threat of the OS blocking
| our background tasks altogether and we end up having to be very
| conservative when it comes to uploading data in the background.
| Which a lot of times results in 0 files getting synced until
| the app is in the foreground. These constraints don't seem to
| apply to Apple Photos though.
| satyamkapoor wrote:
| Super excited for this one.
| sneak wrote:
| Why does this app need to link my identifiers and contact info to
| my identity?
|
| I would feel a lot more comfortable with this if it didn't
| collect any data of mine, and you were just storing ciphertext.
|
| I don't want an account, and I don't want to give you my name or
| email.
| vishnumohandas wrote:
| Hey, we do need some information to get the product to work
| well. You can see the bits of information we collect, along
| with the reasoning here: https://ente.io/privacy/#account-data
| dane-pgp wrote:
| > Browser type and operating system of the devices from which
| you have logged in to ente to ensure account security.
|
| I can't imagine how that information could be used to stop an
| attack that otherwise would succeed. Is this just so that you
| can say "Your last login was from Safari on an iPhone" to the
| user to reassure them their password hasn't been stolen (or
| the attacker has correctly guessed the most popular browser
| on the most popular platform)?
|
| If so, this seems like a string that could be generated
| client-side, and stored encrypted on your server, so that you
| never have to log this data in plaintext.
| vishnumohandas wrote:
| In addition to ensuring account security, we were
| collecting the user-agent to transform API responses
| depending on the client.
|
| But your point is valid. Just the operating system and app
| version is enough to derive this information. We will make
| this change and update our privacy policy.
|
| Thanks for bringing this up!
| sneak wrote:
| Collecting my data is a nonstarter for me. The point of e2e
| is so that the provider doesn't have useful information.
|
| If I have to trust you with my information, you didn't need
| to bother with the crypto stuff.
| ramesh31 wrote:
| "We built a defacto repository of CSAM"
|
| Cloud services have entire departments of people constantly
| combatting this stuff for a reason. It's the single hardest part
| about providing an image service.
| stiltzkin wrote:
| I would suggest make your APK compatible with Android TV, there
| is no Google Photos for Android TV and Google answer is use your
| phone to cast your photos to TV.
| olah_1 wrote:
| is there a way to automatically migrate from google photos?
| vishnumohandas wrote:
| Yes! You can go to takeout.google.com, export your photos and
| drag them into https://web.ente.io. We will preserve all of the
| metadata Google generated.
|
| If at all the upload flow breaks in between, just drag and drop
| the exported folder again, we will skip already uploaded files
| and resume from where we left off.
| [deleted]
| d1lanka wrote:
| Neat.
|
| Some UVP / Headlines to split test:
|
| 1. Keep your memories yours.
|
| 2. Safeguard your memories from prying eyes.
|
| 3. Don't let big tech creep on your memories.
|
| 4. Keep your memories private.
|
| 5. Block creepy algorithms from spying on your life.
|
| I like the dynamic sub headline - perhaps test the following
| variation on that:
|
| protect your {memories} from creepy algorithms
| upofadown wrote:
| What is happening here is more properly called client side
| encryption[1]. End to end encryption is the case where two
| clients are communicating directly with one another where the
| identities are established directly between those clients.
|
| [1] https://en.wikipedia.org/wiki/Client-side_encryption
| Youden wrote:
| The monthly storage costs are too high. For the price of 1TB from
| you (15EUR), I can buy more than 2 TB just about anywhere else.
|
| Commercially, Apple and Google are both 2TB for 10 CHF and Amazon
| gives you unlimited as part of a Prime membership. Storage
| providers like Backblaze and Wasabi both charge around $5/TB and
| that's really the table-stakes price. For the more DIY-inclined,
| Hetzner sells a 2TB OwnCloud instance for 9.90EUR/month.
|
| I'd prefer to buy software from you than storage. It's out of the
| question for me to pay you per TB but I'd consider paying a flat
| rate for software I then host myself.
| sam0x17 wrote:
| Yeah, if you are client-side encrypted, where you choose to
| host doesn't really matter because even with a warrant there is
| nothing you could do to recover data, so why not go for
| something like Wasabi?
| woofie11 wrote:
| I can pay for a terabyte of Amazon Glacier for $50/year. Amazon
| Deep Glacier is $12 per month.
|
| $300/year for 2TB isn't happening. I can buy a 12TB HDD for
| less, if I shop around.
|
| I'd like a service like this to keep small, well-compressed
| 1080p or 4k photos available for instant access, and original
| files in archival storage of some kind.
|
| I'm totally glad to pay the $10/year for the baseline service,
| and another $12 for deep glacier costs. I'm not glad to pay
| thousands of dollars for a service like this over the lifetime
| of my photos. I'm not quite sure where the line between that
| is.
|
| I'll also mention: open-source, data export, and the option of
| self-hosting is helpful. I don't want to spin up an EC2
| instance for this when I can buy $12, but if you go out-of-
| business, I'd like to have the option. Could also be an option
| you only guarantee if the service is discontinued or has
| substantially different costs/terms.
| imagine99 wrote:
| 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 having feature parity with the big
| cloud-only solutions.
|
| I for one am convinced that there is plenty of money to be made
| that way. Perhaps not as much on autopilot as with the quasi-
| scam that is cloud computing, but people willingly paid
| hundreds or thousands for software before clouds and
| subscriptions. People will do so again, if you bring a
| convincing, unique or competitive product to market.
|
| That being said, I like, appreciate and support this project
| for its impetus, even though I think its distribution strategy
| is misguided and fad-driven (re-selling cloud space instead of
| selling software). It's not too late to change that...
| missedthecue wrote:
| What about Google photos is evil? I don't get it.
| the_biot wrote:
| The other day I sent out a link made with Google Photos'
| "create link" function. That's not a share to another user,
| just a link that anyone can open, no Google account
| required. But one person showed me that hitting that link
| on her phone, Google wanted to authenticate her before
| showing the picture.
|
| That is _utterly_ unacceptable.
| Z_I_F_F wrote:
| Genuinely curious - could you elaborate on why that is so
| unacceptable? What does requiring authentication imply,
| or lead to in the future?
| SXX wrote:
| Okay it's easy to downvote, but I'll elaborate instead.
| First of all Google is trainihg AI models on your data and
| also able to create shadow profiles for people including
| those who decide against using Google services.
|
| They also used dark pattern on Android for years by
| enabling cloud sync by default for everything. So a lot of
| people got all their photos uploaded while they had no idea
| about feature.
|
| So it's not any different from Facebook that constantly
| tried to collect as much data on you as possible. Do you
| know what is evil about facebook?
| vishnumohandas wrote:
| 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 felt that it
| was more important to make privacy accessible to people like
| my mom and dad. Hence this direction.
| Youden wrote:
| 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 advertising?
|
| Normally, I'd suspect it's the tech-savvy younger folks
| who'd tell them to buy something like this but with your
| pricing and lack of self-hosted options, I suspect you've
| alienated a large portion of the tech-savvy audience you
| need to advocate for your product.
| robertlagrant wrote:
| I think that's a bit apocalyptic. Plenty of time to
| observe and adjust.
| pininja wrote:
| If their service works well and is convenient to use,
| I'll be recommending it by word of mouth. In the case of
| my parents, if I can finally consolidate and de-duplicate
| the photos from our 3+ Apple Photos collections by
| pointing the service at "library" folders from a few
| computers and devices, I'll be a big fan.
| vishnumohandas wrote:
| > 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 self-hosted
| variant. Just that due to our limited bandwidth we had to
| choose one direction over another. Having advocates is
| important and I suppose with time we will have clarity on
| how to best do this without stretching ourselves too
| thin.
| Z_I_F_F wrote:
| I really hope the self-hosted option becomes a thing, but
| unfortunately "we are not averse to the idea" means
| especially little in the tech world these days.
|
| That being said, really really hoping for your success!
| It finally fills a MUCH needed gap in 2021 consumer image
| viewing software.
|
| There are many many gaps in it right now. Synology is
| basically the only self-hosted photo solution that
| grandma could use. Honestly surprised that more people
| aren't taking advantage of the opportunity.
| Radim wrote:
| > 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/
| edude03 wrote:
| I'd pay for this if it could run locally. Not sure what
| it would take to be sustainable but solving this problem
| is worth at least $20/month to me.
| pratnala wrote:
| I think too many technical people have too much of a
| distrust of the cloud. I, for one, am happy to offload as
| much as possible to the cloud (except latency-sensitive
| things like games) and not carry around drives and drives
| at home.
| pkursawe wrote:
| Just put a price on it, ffs! Make it extensible with
| plugins. To gain 100% trust make it open source. I am
| happy to pay good money of a local, non-leaking AI based
| tagging software for video and photos.
| Z_I_F_F wrote:
| Very surprised no one has mentioned Synology yet. This
| has been done. And it's awesome!
|
| I currently have a self-hosted google photos clone and I
| only paid for the hardware. Highly recommend.
| nicoburns wrote:
| Can I suggest adding pricing tier(s) between 100GB and
| 1000GB? I have between 100gb and 200gb of photos, and
| PS14.99/month seems like a lot considering I only pay
| PS2.49/month for google storage. I'd definitely consider
| paying a premium for this service, but not 6x.
| vishnumohandas wrote:
| 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 intermediary plan (say
| 500GB), we would have to increase the pricing of the 1TB
| plan (since at least 50% will now be utilized), and also
| set the price of the 500GB plan to at least 2x of the
| 100GB plan. Both plans now appear unattractive.
|
| - Since Apple and Google don't support per GB billing yet
| (which IMO would have been the fairest way to go), we had
| to pick buckets, and the current ones seemed like the
| fairest possible.
|
| I hope this makes sense.
| mrobins wrote:
| With Amazon and Google you're paying half in monthly fees and
| half with your mineable data. This service seems geared towards
| people who don't want that.
|
| Rolling your own on top of a cloud storage provider is great
| too but for an incremental $100-$200/year some people would pay
| for something that "just works".
| philshem wrote:
| Clickable links!
|
| [1]: https://ente.io
|
| [2]: https://ente.io/apk
|
| [3]: https://play.google.com/store
| /apps/details?id=io.ente.photos
|
| [4]: https://apps.apple.com/in/app/ente-photos/id1542026904
|
| [5]: https://web.ente.io
|
| [6]: https://github.com/ente-io/bhari-frame/releases/latest
|
| [7]: https://libsodium.gitbook.io
|
| [8]: https://ente.io/architecture
|
| [9]: https://github.com/ente-io
|
| [10]:
| https://www.reddit.com/r/degoogle/comments/njatok/we_built_a...
| sillysaurusx wrote:
| (Since the original links are now clickable, I propose that it
| would be nice if HN made all links in self-text posts clickable
| by default. It seems like it might foster a healthier
| community, since it will feel less like it's a special
| privilege to have clickable links.)
| sysadm1n wrote:
| What happens if I buy the yearly plan, fill my account with
| photos, then don't renew my subscription? Can I still access my
| photos even when downgraded to a free account?
| vishnumohandas wrote:
| No, storage and bandwidth are quite expensive. We will purge
| your data from our systems 2 months after your subscription
| expires.
|
| You will have an easy way to download all of your data, and we
| will notify you multiple times to do so before the deletion
| actually happens.
| olah_1 wrote:
| you have a warning during sign up that says "you will lose
| everything if you forget your password".
|
| naturally this is off-putting to most normal people. any plans to
| implement a social-recovery system like we see in the ethereum
| world?
|
| if i can share photos with friends, i should be able to use those
| friends to recover my account too.
| vishnumohandas wrote:
| Sorry for the off-putting text. We do offer a recoveryKey that
| can be shared with your friends and rotated if necessary. As
| long as you have access to either your password or your
| recoveryKey, you will be able to decrypt your data.
| ukverwwrttyv wrote:
| Is there a 20GB plan please?
| mynameismon wrote:
| Kudos on your launch! I just had a question: the pricing plans
| seem _slightly_ pricey, is it to break even before bringing
| prices down, or is it due to expensive storage? If the latter, is
| there a self-hosted option?
|
| Also, the website looks absolutely great!
| bogidon wrote:
| Have been hoping for something like this for probably a decade
| - and your product looks great.
|
| Also have a question about the pricing. I'm happy to pay at the
| current tiers, especially to help getting y'all bootstrapped.
| But I'm curious if reducing the pricing will be an objective
| for you as you scale? I'm not sure I see myself maintaining the
| current expense indefinitely or it making it easy to recommend
| to less technical friends/family.
| vishnumohandas wrote:
| The idea behind the project is to make privacy accessible. We
| are hopeful that we'll be able to lower the price points as
| we scale up and still remain profitable.
| raobit wrote:
| ELI5 what does self hosting option mean here in this context?
| ignoramous wrote:
| I reckon, BYO object store.
| lol1lol wrote:
| yes! googol is cheaper and the bottom line matters to lot of
| people. perhaps this is a good way to ask people whether they'd
| pay additional 5-10$ for privacy.
| vishnumohandas wrote:
| Thanks! We're currently focusing on breaking even and becoming
| self sustaining. With scale we're hopeful that we'll be able to
| reduce the prices.
| gauthamzz wrote:
| I have been using ente.io for few months now. It does what i
| want, to back up my photos. AI and all is something i personally
| don't care much about. But i would love to have location
| clustering.
|
| Pretty happy with it.
| tills13 wrote:
| 9 times out of 10 people will choose convenience over privacy.
| Google Photos is just too good to care about the supposed
| "privacy issues."
| yawaworht1978 wrote:
| Is this encrypted at rest as well?
|
| Can you recover the data in case of a loss without seeing the
| data?
|
| Good project, really well done, browsing the GitHub a bit.
| vishnumohandas wrote:
| Thanks!
|
| The data is encrypted once it leaves your device.
|
| Not sure what you mean by a data "loss" here. If it's about the
| customer losing access to their password, as long as they have
| access to their recoveryKey, they will be able to sign in and
| change their password. If it's about something else, please let
| me know.
| tagilux wrote:
| Is there a way to self host? Backend included?
| tagilux wrote:
| Is there a way to self host the backend?
| mattrighetti wrote:
| In my opinion, people who don't trust google (like myself) would
| not trust every other company too. The perfect solution for me
| would be something that I can self host on my LAN with a clean
| and intuitive app like the google photos one, that would be a
| service that I would pay for.
| criddell wrote:
| With an Electron client, you also have to trust all the
| JavaScript libraries that NPM brings in (and this can be a huge
| number).
|
| Electron is pretty cool, but it doesn't seem compatible with
| anything related to security or encryption.
| lol1lol wrote:
| congrats! wishing you good luck
| headmelted wrote:
| I'd love for something like this to exist (a fast, clean, well-
| designed mobile and desktop app for backing up my photos with
| E2E), but I'd only switch from one of the big providers if it
| were FOSS and I can bring my own backend target (e.g. S3, SMB,
| FTP).
|
| In a perfect scenario I could generate my own private key to plug
| into my client devices and just have everything push to private
| S3 (and then from there archive to the cheapest, coldest glacier
| tier after it's been synced to my home storage).
|
| This to me would not be that complicated to build, but would
| essentially provide E2E Photostream _and_ a backup of last resort
| in the cloud.
|
| Obviously (as is the problem with all FOSS) you have the dilemma
| of how do the developers get paid, which I'm sure is why you went
| down this yet-another-paid-cloud-provider route instead of what
| I've suggested above.
|
| All that said - I like what you're trying to build, I could see
| it being useful to some, but providing E2E photo storage as a
| direct-to-consumer service is IMHO just asking to be held liable
| later for what your users store there should you gain any
| considerable traction.
| hiimshort wrote:
| I'm sure this isn't a popular opinion due to the technical
| know-how involved, but these days I much prefer to selfhost my
| own services. Far too many times businesses have gone under,
| changed their practices, had pricing wildly fluctuate, or
| remove features I wanted. Having setup a handful of useful
| services on a cluster, I have much more peace of mind involving
| my data, feature access, etc.
|
| I would love to see a FOSS version of ente available for me to
| host. My family is currently split amongst multiple photo
| library services and it'd be nice to say "Here's ours."
| siscia wrote:
| Well you can, I wrote how here:
|
| https://redbeardlab.com/2021/08/03/my-syncthing-setup-cheap-...
|
| The nice thing is that S3QL allows setting a secret key, so
| your files just get encrypted before to be pushed on the cloud.
| barbazoo wrote:
| +1 for custom storage target
| [deleted]
| joshmn wrote:
| Super cool. Did you roll your own storage solution or are you
| using one of the many cloud providers? If the latter, which one?
| I ask because I've done a ton of work in optimizing costs in this
| area (at large scales), and as the top comment mentioned, $15 is
| kind of steep for 1TB.
| vishnumohandas wrote:
| Hey, we're currently using two S3 compliant storage providers
| (Backblaze and Scaleway). I would love to talk more about how
| we could reduce our pricing. Please let me know if I can reach
| out to you over the email mentioned on your HN profile. Thanks!
| joshmn wrote:
| More than welcome to!
| hzay wrote:
| V cool service! What metadata do you store btw? Can I use it to
| store nice dslr pics and later sort by ISO?
| vishnumohandas wrote:
| On mobile we already include EXIF information in the encrypted-
| metadata. We will be doing the same on web soon, and will then
| enable client-side search over that data.
| me551ah wrote:
| One of the biggest reasons why I like Google Photos is all the
| processing that it does on photos, especially some of the
| features that you have mentioned (object and face detection,
| location clustering, image filters, ...). Now to process these
| photos, you would need to read them and since you are end-to-end
| encrypted it's up to the clients to do this processing. Would
| some of these features even run on mobile devices(or for that
| matter javascript on the web)?, since google uses AI heavily for
| these tasks. You upload a picture on google, and instantly you
| get all the processing done on your pictures and they are
| available for you to browse and search. Google uses custom built
| AI processors and massive GPUs to get that computation done
| quickly. To replicate that in javascript on the web and mobile
| devices is going to be hard since there are few libraries which
| support it and the mobile devices really cannot compete with the
| computing power available in the cloud.
|
| I really love the privacy oriented aspect of this service though
| and I would really like to share one less thing with google. I've
| always been concerned about being blocked out of my google
| accounts and losing my photos.
| robertoandred wrote:
| Sure. All of Apple's photo analysis is done on device.
| vishnumohandas wrote:
| You're right, we don't think that the accuracy of the indexes
| generated on the client will match the ones generated by
| Google's servers. There is a trade off here between user
| experience and privacy, and we are hopeful that the outcome
| with ente will hit a spot that will make it a viable
| alternative for a certain set of users.
| samstave wrote:
| How ripe is this space?
|
| Recall Origami which stated to do same and then they got a qui-
| killed before they could even launch?
|
| I haven't used any online photo storage place for years because I
| dont trust them, but that's also a lame excuse because I have yet
| to be able to extricate Google from my life, which is a
| smoldering desire in the back of my head..
|
| But I feel like any of these photo upstarts are going to be short
| lived.
|
| I'd be happy to pay $60 for the app, and then pay some fee/month
| for storage space, dedupe etc...
|
| What might be cool for an organization option would be a shared
| library of assets such that dev's and artists can manage a
| library of digital assets across teams and projects and integrate
| with ssomethingnlike slack..
___________________________________________________________________
(page generated 2021-08-29 23:00 UTC)