24
You're saying you don't want users to have to trust the website code that the server offers. So why would the user trust the extension instead?
An extension is probably not needed. JavaScript and local storage allow you to do this kind of stuff. Proton Drive and Mail accomplish this without an extension.
I've answered this question in many other threads at this point, but since you're now the top comment:
Proton Drive and Mail still require you to trust them to serve you Javascript that doesn't snoop on your plaintext content. They don't have any way of proving that their web app isn't taking your plaintext emails (which you can read in your browser and therefore they are visible to Javascript on that page) and sending it back to their server.
Is their JS code open source? If so, I don't see any real differences between an extension and JS code. Unless extensions have less privileges or something. The user will have to either trust the code or inspect it themselves regardless if it's an extension or JS code.
The difference is that JS code served by a web server can change at the server's whim, and there is no standard way to verify that it matches what you expect except by reading it every time you visit the page.
With an extension, assuming you trust the browser itself, you can check that the extension matches its source, and you only need to do that once per install.
One way to not place full trust on the "server" IMO is to make the JS open source and use jsDelivr or unpkg or some other 3p service to serve the JS so that it's not in the website's control. Independent.
That's true. On the other hand, the extension gains a much larger attack surface since it has access to a lot more data (every site you visit vs. only the site that serves the JS code). At the end of the day, people wouldn't use your site if they didn't trust your site, especially if they use it for privacy and integrity reasons, so for most users I think JS is the better option. I suppose there's no reason you can't offer both though.
I think that's the prevailing sentiment in this thread. People would rather trust the site to run the code as advertised and get some added convenience rather than verify the code for themselves.
Interesting perspective, though of course as the MX sending and receiving all the messages in the first place, they probably wouldn’t need to do it at the browser level.
I wouldn't install a browser extension over an app. And I probably wouldn't install a browser extension for a web app.
I've read the thread. Your argument for an extension is to make it open source, why couldn't your front end code be open source instead?
The front end code could be open source, but you'd still have to trust the web server to actually serve you the same code.
What? Lol no. And a site like that probably shouldn't have signatures. Something like Bernstein authenticators would be way preferable.
I think you can get away with using the web crypto apis and storing the private key in indexeddb. If you want users to be able to change devices or recover after blowing away their client storage, allow the user to download their private key and save it to a password manager.
IndexedDB is same-origin storage, readable by any script the origin serves. So the keys would not be safe from the host.
I mean no offense by this at all, but I wouldn’t because it would indicate a poor understanding of cryptography to me as a user. Either that or being intentionally misleading. In either case, probably unsafe for the user. There does not need to be an extension to encrypt content such that the server never has access to it. It can be encrypted and sent to the host with a key the server never possesses.
And how do you propose the web app provides the code to do that encryption without gaining access to the key?
It doesn’t. The code your site provides is downloaded by your client’s browser. It uses a key on their side that is never sent back to your server. Same as if you did it with an extension or application. This is well trodden ground, and used across the internet such that hosts have zero knowledge of their users’ data aside from in its encrypted state.
Actually, let me give a little ground here. There is a subtle but real benefit to an extension or signed application. With just JavaScript, a server could on a new page load deliver an altered code that would introduce a compromise. If that is the threat you want to mitigate for, you’re onto something. If you’re talking high stakes, and you make it clear this is the threat for which you’re protecting users, then I could be convinced.
The point is you can't prove the server won't serve you code that won't take your key and send it somewhere arbitrary.
Maybe check out WAICT.
Oh yeah. I had just edited to identify that. And if this is the threat for which you’re protecting, this does make sense.
You don't need a browser extension or an app for this.
Look at MEGA Upload for example. While it's primarily a cloud storage platform, it does allow for file/content sharing ... though not really in the social media kind of way I think you're getting at. But the technical way they implement it could help you.
When you sign up there, you set a password, and the hash of that password is then your encryption key. All your client (whether an independent app or just a script on a web page) needs is the ability to hash the user's password to be able to reconstruct the key and begin decrypting things.
The main weakness of this is that users must remember their own password. Due to the zero-knowledge encryption, the host cannot know the password and cannot recover it. So if the user forgets their password, then they're just shit out of luck, and all their content is forever inaccessible.
All your client (whether an independent app or just a script on a web page) needs is the ability to hash the user’s password to be able to reconstruct the key and begin decrypting things.
This would work as an independent app. But as a web page, it would be delivered by the web server, requiring you to trust that the server is not snooping on your decrypted content (by sending it back to the server post-decryption).
is this asking too much from users?
Installing a browser extension for one site? From usability point of view, how is that any different than installing an app for each service/company?
I wouldn't, but obviously there seems to be many people who install an app for everything.
If what you're building is worth the hassle of installing the add-on and viewing the content, I suppose. There's not many programs people use PRIMARILY for security. You wouldn't use a note program that has audited security if you can't save notes, for instance.
Can you derive the private key from the password? Like PBKDF2 or something. I guess it's what most E2E sites do. I wouldn't install anything unless it was for work and involved me receiving money.
Something along these lines is a good idea, but be aware you need extra considerations to keep the e2ee intact. If like most websites you would send the password to the server to login, and if you derive the private key from the password, suddenly the server would have your private key.
There's probably something you can do with hashing before sending to the server on login, but I don't have enough confidence to be definitive on that.
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.
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.
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.
Checkout cryptpad, it may inspire you ideas on how to implement an app to hold user-encrypted contents
On Cryptad's security page, they say:
some entities still need to be trusted in order to guarantee security: Your chosen CryptPad instance to run the same code as the one published on GitHub
This is the trust requirement I am trying to avoid by making the browser extension open source and independently verifiable.
Https already encrypts content during transit. Just use login/password/totp/passkey.
this post was submitted on 15 Aug 2026
24 points (100.0% liked)
Ask Lemmy
40928 readers
1724 users here now
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
founded 3 years ago
MODERATORS