3 ms·

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 dep

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.

kvdveer 4y ago
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_Colonel 4y ago
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.
xdfgh1112 4y ago
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.

kvdveer 4y ago

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_Colonel 4y ago

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.

xdfgh1112 4y ago

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.