Hacker News Reader

Comment by arpitagarwal | Hacker News Reader

Great question - we just keep the encrypting keys on the user's device and in-memory. The keys are encrypted using the user's seed phrase that is only known to the user, and not to Slik.

Feel free to read more implementation details in our WhitePaper - https://sliksafe.com/whitepaper.pdf

View on HN

How do you prevent yourselves from serving a version of the web app that sends the user’s seed phrase to yourself?

(A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)

How is this problem specific to web apps?

How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.

Isn't this a promise of open source? User doesn't have to get a binary from someone, they could, build from source (given experience+time)

Even for closed source apps, reverse engineering efforts (for sufficiently popular binaries) often find backdoors. This sort of auditing only works because each end user gets the same binary blob. (And if not, there’s a reasonably high likelihood of detection.)

Well, for traditional Linux desktop apps, the distribution audits the code + ships the binaries.

For app store based distribution, the developers can set up a deterministic build, and end users can verify the checksum of the package matches the developer’s published source code (signal supports this).

So the distribution is the one that alters the code and same issue.

The distribution can alter your browser/kernel/...'s code anyway. So you are not adding a compromise vector by using one more package provided by the distribution, as opposed to getting the package from a third-party.

The problem with web apps is that the user doesn't really have any control over updates. With a regular app you can verify a version and stick to it. The web version can change at any point with no notice.

Additionally, a regular app can be signed by a key from the developers that you can verify. With a web app you don't even know if it comes from the developers or if you're being MITM-ed because someone managed to get a SSL certificate for your domain. The certificate isn't the only angle of attack either, your CDN or hosting provider might be hacked. Yes the CDN that hosts the regular app can also be hacked, but that will only work against brand new users, because existing users can already know the signing key and the hacked binary won't have the correct signature.

Reply on news.ycombinator.com