Ask Lemmy
A Fediverse community for open-ended, thought provoking questions
Rules: (interactive)
1) Be nice and; have fun
Doxxing, trolling, sealioning, racism, toxicity and dog-whistling are not welcomed in AskLemmy. Remember what your mother said: if you can't say something nice, don't say anything at all. In addition, the site-wide Lemmy.world terms of service also apply here. Please familiarize yourself with them
2) All posts must end with a '?'
This is sort of like Jeopardy. Please phrase all post titles in the form of a proper question ending with ?
3) No spam
Please do not flood the community with nonsense. Actual suspected spammers will be banned on site. No astroturfing.
4) NSFW is okay, within reason
Just remember to tag posts with either a content warning or a [NSFW] tag. Overtly sexual posts are not allowed, please direct them to either !asklemmyafterdark@lemmy.world or !asklemmynsfw@lemmynsfw.com.
NSFW comments should be restricted to posts tagged [NSFW].
5) This is not a support community.
It is not a place for 'how do I?', type questions.
If you have any questions regarding the site itself or would like to report a community, please direct them to Lemmy.world Support or email info@lemmy.world. For other questions check our partnered communities list, or use the search function.
6) No US Politics.
Please don't post about current US Politics. If you need to do this, try !politicaldiscussion@lemmy.world or !uspolitics@lemmy.world
7) No Hit-and-Run questions.
Please don't delete your post for no apparent reason. If you plan on deleting a question later, say so in the post, or if you feel that you have a good reason to remove it, message a mod beforehand. It's not fair to the ones who took their time to answer, and it's not in the spirit of the community.
8) No Bots.
Posts or comments from bots, LLM's, AIs, Neural Networks, Transformers, or Marvin the Paranoid Android are not welcome in AskLemmy. Real humans only please.
Reminder: The terms of service apply here too.
Partnered Communities:
Logo design credit goes to: tubbadu
view the rest of the comments
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.
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.
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.
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.
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.
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.
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.
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.