I’m trying to create a web app that involves sharing of user-generated content, but one of the goals is that the service host operator should be blind to the content. Only authorized users should be able to see the content shared with them. This implies the content must be encrypted at rest, and users must hold custody of their private signing key.

I figure the situation requires an open source browser extension to hold onto a user’s keys and decrypt content for them. The web app would still be able to browse all of the site’s metadata, but any plaintext content must be siloed in the extension. The reason for using an extension is that the source code would be open source and independently verifiable, while building the same functionality into the web app would require trusting the host to serve the code you expect.

Do you think that’s a reasonable tradeoff or is this asking too much from users?

The other option would be just requiring users to download an open source app for content viewing.

EDIT: Perhaps an important followup: are you OK placing trust in the host to never access your confidential data if it means you don’t have to install additional client software or worry about verifying that client software’s authenticity?

  • tatterdemalion@programming.devOP
    1·
    4 days ago

    PBKDF2 is exactly what I’m using right now. The other reason for the extension is to prevent the host from ever having access to the key or the plaintext content. Sure, if you trust the host, the web code could be written to never send plaintext content back to the server. But I’m trying to eliminate that kind of trust requirement.

    • paks@feddit.uk
      2·
      4 days ago

      The user’s going to have to trust your code one way or another. Making it a separately downloaded extension/application, rather than some js in the browser page, doesn’t change that.

      • tatterdemalion@programming.devOP
        2·
        4 days ago

        Making the client open source means its auditable by the public. Making a server open source doesn’t mean anything because you don’t know if the host you’re talking to is actually running that code.

        • paks@feddit.uk
          1·
          3 days ago

          It’s not the server code which is the question though, it’s the client side, which either way is downloaded from somewhere you control (whether in minified js to run in the browser, or binary blob of a desktop app). A malicious developer can quite easily insert different code rather than the published source in either situation.

          I guess if you have a traceable build pipeline which is entirely under control of a trusted cloud provider, that might do it.

          But if so then there’s no reason you can’t make the web client “binary” available in the same way, as say a webroot zip or a container image. People can run it themselves against your backend api, or audit the frontend code your server is serving against the trusted version.

          • paks@feddit.uk
            1·
            3 days ago

            Or for the hell of it, write your web client with its encryption code in plain js rather than minifying it or using a framework. Then someone can view source on the web page and literally see the client source which is running.

            Not the most maintainable solution of course, but highly transparent.

          • tatterdemalion@programming.devOP
            1·
            3 days ago

            or audit the frontend code your server is serving against the trusted version.

            OK but that requires everyone to be a vigilant user. It’s much easier for users to just install the software themselves and verify the checksum matches.

        • OwOarchist@pawb.socialEnglish
          1·
          4 days ago

          So make sure everything is encrypted before it’s ever sent to the host, which is verifiable through the open source code running on your own PC.

          If your local software doesn’t send anything in plaintext and doesn’t ever send the encryption key, then it doesn’t matter what software the host is running – they won’t be able to decrypt the content. Even if they’re actively trying to breach the encryption, they’re not really any better off than just some random man-in-the-middle sniffing network packets.

          • tatterdemalion@programming.devOP
            1·
            4 days ago

            That’s exactly what I’m proposing. The code that runs on the client needs to be open source and verifiable. That is not currently possible for code delivered by a web server using today’s web standards AFAIK, which is why I’m reaching for the browser extension.