Comment by ignoramous
5 years ago
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.
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. :)
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/
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.
I've been thinking of a similar system with e2e sharing of content and I'd love to pick your brain on this if you don't mind :)
- What made you go with libsodium over using the browsers Web Crypto API?
- If you stop sharing an album with someone, do you somehow re-encrypt the collection key or is the recipient still in possession of all the necessary keys to decrypt the data if they get their hands on it?
- Mature libsodium clients were available across the platforms we were targeting. The APIs seemed well documented and turned out to be a delight to consume.
- There are access control checks in place to revoke access to files from removed album participants. But from a cryptographic standpoint, once your keys have been shared (/compromised), the respective files should be re-encrypted.
4 replies →