Comment by The_Colonel | Hacker News Reader

Comment by The_Colonel | Hacker News Reader

I've worked on 2 "zero-knowledge" apps (basically meaning all data is encrypted/decrypted on the client) and I would advise against it:

* most consumers have no idea what you're talking about / don't care

* those who know what "zero trust" is, also know that it's not really trustless. You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continuous basis is essentially impossible, a rogue update can be pushed anytime. The amount of trust you need to put into the company is not dramatically different from a normal setup. I think psychologically it's also a bit self-defeating - promoting zero-trust aspect somehow suggests that customers shouldn't trust you.

* the design is a major pain, since you never know what surprises await you in the customer's data (data tends to rot). Data migration to a newer version is a pain since you can migrate only when the user logs in, which can be years later (in effect you need to keep backwards compatibility forever). Debugging such customer migration problems blindly is hell.

* there will be useful features which you won't be able to implement without violating the zero knowledge principle. Chances are that many users would place a higher value on those features rather than on the zero knowledge aspect.

If you really want to decrypt/encrypt on the client, then try to minimize them - no encrypted structures, just encrypted text / images / whatever payload. Metadata, keys etc. can remain plaintext and thus accessible for your maintenance needs.

While this is very well put, isn't this like saying "people could jump over the safety rail. So there is no point having it".

Your logic that the app could deploy a "rogue update" so it has little merit would essentially say there is no point in mitigating anything because insert unlikely failure case.

When saying it causes people to trust you less by raising the spectre I disagree. I would assume that a company focused on zero knowledge would also pay attention to other mitigations and related best practices.

Agree with the downsides.

In a zero-knowledge setup, the client needs to trust that the setup is actually zero knowledge, and that future updates will not change that. Essentially the client needs to trust in the absence of incompetence or malice.

In a classic setup, the client needs to trust that the service provider is not malicious or incompetent either.

The level of trust thats required for a zero-knowledge setup is not fundamentally different from that of a classic setup. Most importantly, the amount of trust required is substantially greater than zero.

The problem is in setting wrong expectations. The app is "sold" as trustless - you're told that there's no need to trust the provider, but that's simply not true.

I would agree that it's "safer", though, since client-side encryption indeed eliminates several ways how the confidentiality of your data could be compromised.

You still need to trust them not to read your data via a client side update, which is similar to trusting them not to read it server side. Client side leaks are easier to verify (as you can trace network traffic) but it's too late at that point.

Essentially it's not really zero trust at all. When I think of zero trust I think of running code locally that is either firewalled or I wrote it myself.

I appreciate that if you _do_ trust them, then this setup is much better as it eliminates the risk of a data leak via compromise, which is all too common these days.

Two of your arguments (1 and 4) are only narrowly applicable (i.e. you should rephrase to "I would advise against it if your sole goal is a large mainstream growth"), but even in that context, priorities of mainstream consumers have shifted over the decades as a direct result of people developing/failing/retrying building such niche projects, & those projects slowly making their way into mainstream consciousness over time. So I'd never recommend against doing something because the audience is small today.

As to your other two points:

- your third bullet amounts to "don't do X because it is difficult"

- your second bullet isn't really true. Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal. It's entirely conceivable for "effective trustlessness" to be achievable for a decent range of threat models. Sending plainttext/passwords back to the server could be mitigated by a broad selection of approaches: moving the "reproducible / verifiable / signed builds" efforts of native apps into the browser. Components of this are already conceivable with service workers, and with enough demand browsers could easily improve support for related measures.

TL;DR what's easy to do today security-/privacy-wise is easy purely because people continued to work on it when it seemed impossible / not worthwhile. Discouraging these efforts is really poor form.

---

Additionally, worth mentioning that all of the above applies to SaaS, and for open-source self-hostable projects (not applicable here), the reasons to continue working on it are even stronger.

Yes, most of the points are sort of product-growth related. But given this is a SaaS project, I assume the author has commercial intentions, and thus I hope my 2 cent advice is useful (as mentioned before, I went through two such products already [one was commercial]).

> Zero trust can be trustless in theory, and every effort to make it so moves the dial closer to that ideal.

I agree it can be done in theory, but I don't have a reason to believe the product as of today is truly trustless as it claims on the website.

I also believe that making something truly trustless is impractical for the vast majority of use cases. Reproducible/signed builds are indeed a step in the right direction, but not enough on its own. Each signed build would additionally have to be independently audited by a trusted 3rd party. It doesn't help that the build is signed, if the company itself inserted the password logger. And not having to trust the provider is the point of trustless, isn't it?

> You do have to trust the company that it will never send the password or plaintext data back to the server. Checking this on a continuous basis is essentially impossible

This is why I like decentralized apps where you can use a content-addressed frontend that is just pinned to a specific version. I can choose to update to the next major version if I want to.

I agree with the pain points you've highlighted -- but I think certain applications do benefit from zero-knowledge. Password managers for example. In the case of journaling, I think one reason people resist is fear of exposure. I agree though, the challenge is communicating the added security to non-technical users.

True users must trust the developers to not make a rogue update, but in practice I think it works fine. We also trust library dependencies to not push a rogue minor update that will crash our site or do something malicious.

We've seen how well the library dependencies thing works... alas. Now imagine an actor, who makes malware, where the crash isn't visible. :/

Your points are all sound, but I want to expand on this one:

> a rogue update can be pushed anytime

This is not an intrinsic property of a zero-trust system, but a consequence of a culture in which software is never finished.

Agreed, but also more or less inherent property of SaaS. (not in theory, but in practice there's no usable solution to "pin" versions of client code)

These are great points. “Zero trust” is only really possible on FOSS self-hosted systems.

And only for developers who have both the time and inclination to vet each update for themselves, updates which (for big systems) may have contributions from hundreds of people and may be in a language that you only know vaguely.

Open source and self hosting is a good start for the paranoid, but definitely not sufficient. As always it comes down to threat models and who/what you are trying to defend against.

Reply on news.ycombinator.com