4 ms·

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

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 https://sliksafe.com/whitepaper.pdf

hedora 5y ago
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.)
- spiderice 5y ago
  How is this problem specific to web apps? How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
  - edoceo 5y ago
    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)
    - hedora 5y ago
      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.)
    - deleted 5y ago
      [deleted]
  - hedora 5y ago
    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).
    - sroussey 5y ago
      So the distribution is the one that alters the code and same issue.
      - progval 5y ago
        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.
  - Strom 5y ago
    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.

hedora 5y ago

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.)

spiderice 5y ago
How is this problem specific to web apps? How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
- edoceo 5y ago
  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)
  - hedora 5y ago
    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.)
  - deleted 5y ago
    [deleted]
- hedora 5y ago
  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).
  - sroussey 5y ago
    So the distribution is the one that alters the code and same issue.
    - progval 5y ago
      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.
- Strom 5y ago
  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.