59
No, as there's no use case for me.
Not all data that I share is sensitive. Server stored stuff, unencrypted is fine for me.
As for other sorts of sensitive stuff, Signal works perfectly fine for me.
Hell no. I don't install any extensions for any reason other than uBlock and a pw manager. Just because you say "trust me, bro" doesn't make your extension secure or privacy - focused.
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.
It seems that ignorance abounds in this post's comments. People are apparently unaware that one can write an extension that has no more privileges than a normal web page, and unlike a page, the code cannot change on every load. Your idea is good. I'd recommend not using any minification or obfuscation in the extension, and keep it as brief as is possible, for maximum transparency.
In a parallel situation, I've always been wary of hosted password managers' web interfaces like those of Lastpass, 1Password, and even Bitwarden, because one has to accept the code served at every access is clean. Ultimately, one enters their master password/secret keys, as plain text, into a web page that's difficult to audit & unlikely to be, on every view. Whereas offline/client-side encryption outside the transmission medium is far more trustworthy (e.g. KeePass).
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.
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.
Perhaps it makes more sense to have an extension that checks that the served javascript is correct? That should be a very simple, basic extension that doesn't increase the attack surface much. Users who care to verify the code can use that and everyone else can live with the convenience.
Not sure if it makes much sense, it's probably more work than it's worth and maybe leads to doing the same thing twice.
Another commenter just told me about WAICT and there is also an experimental extension called WEBCAT by the freedom of the press foundation. Going to look into these more.
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.
load more comments
(22 replies)
load more comments
(1 replies)
Well I heard that safety is always a compromise between convenience and security. I think this would only make sense if you have a provider that you can trust now to provide a clean extension, but you can't trust to not do a rugpull or be forced by agents to suddenly implement a vulnerability. But that is basically specifically targeting you or your group. So this is already incredibly niche.
For most people, you either trust or you don't, and preferably you only trust a server in a neutral country like Switzerland. If you make it too complicated you diminish the usefulness of the service.
I believe it would be far more secure to have a native linux app written in e.g. rust to do all this. For an encrypted messenger for example.
Just as an anecdote, I wrote professional medical software that people purchased. At one point there was a browser API change that would negatively affect customers in a critical workflow, I forget the specifics. I think it had something to do with file uploads. Anyway, I worked around this by creating a small browser extension that people could install that would restore previous functionality.
Less than 0.01% of customers installed it. Maybe 10 people. Not even the loudest complainers installed it. It was a massive waste of time.
In the post mortum, we discovered that it's a complicated and strange process for average people to install an extension at all. They have no experience with it, and they don't know how to do it, and they didn't want to do it. It's not like installing an app, which is a more familiar process.
The only analogue I can think of in a similar situation is something like Steam Inventory Helper which is widely used with over a million users. But the demographic is vastly different, these people are PC gamers and used to modding files and such.
So really it depends on your demographic, and whether you truly need it. Just realise it will be a great filter.
In part that sounds like what zeronet did, but that was static p2p websites. User content was signed and distributed by the user. But the code of the website could block and filter the user content. Everything was handled by client-side javascript basically
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.
load more comments
(3 replies)
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?
Maybe because you can't make sure the server uses the code it advertises without modification (The source code could be open and safe, but how can you make sure the website is actually using that?), while the extension is open source and could be downloaded directly from Github by the user. And if enough websites start using this system, it could gradually stop being an extra extension for that one website.
Maybe because you can’t make sure the server uses the code it advertises without modification
You'd have the server provide the code to your browser, and do the encryption/decryption client-side.
while the extension is open source and could be downloaded directly from Github by the user.
I would not install an arbitrary browser extension from Github. That's just bad security hygiene. Extensions have way too many privileges, there's not enough mechanisms to ensure that an extension is used only on the site that it's intended for, and there's no safe way to maintain updates. Heck, even extensions distributed on browser's official marketplaces have been shown to be ridden with malware.
If you're going to distribute code to run client-side for encryption/decryption, you may as well consider WASM. At least that's sandboxed...
You'd have the server provide the code to your browser, and do the encryption/decryption client-side.
Yes, OP has a problem with this part. You'd have to trust the website to serve you the clean client side JS each time you use it. The proposal requires you to check the source code (which is plain un-minified JS) of the extension to make sure it's doing what's advertised when you download it the first time and with each update, instead of having to check the client side (obfuscated / minified) JS of every website each time you use it.
I would not install an arbitrary browser extension from Github. That's just bad security hygiene. Extensions have way too many privileges, there's not enough mechanisms to ensure that an extension is used only on the site that it's intended for, and there's no safe way to maintain updates.
That's true, but auditing that one extension (even on every update), which may be used by other websites in the future, giving it more attention and audits, is a lot easier than checking the client side JS of every website.
This is a recipe for blindly hosting CSAM.
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.
True, but that is also true of the browser extension. You would have to trust the server that you download the extension from.
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.
load more comments
(13 replies)
view more: next ›
this post was submitted on 15 Aug 2026
59 points (100.0% liked)
Ask Lemmy
40967 readers
1061 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