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?
This is a recipe for blindly hosting CSAM.
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.
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.
Oh yeah. I had just edited to identify that. And if this is the threat for which you’re protecting, this does make sense.
Maybe check out WAICT.
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.
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.
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.
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.
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.
Extensions can have more access.
They can snoop / manipulate across tabs or even scan the local drive and execute system commands… when given the access.
I had to make one for work once to let a web app run a legacy command prompt system. The web app’s search was better, but the users wanted to edit with the old tool.
It was kind of interesting the way it worked. Not remembering the full details, I created an extension and a batch script and had to register the batch script with a group policy and declare the extension’s permission to run that batch script
Then the users could search a client in the web app and press a button to bring up their profile in the prompt app.
Not a recommended approach for public facing apps.
*Edit: No! It wasn’t a batch script… exactly… it was a C# app compiled to .dll that accepted client id as an argument
When was the last time you wrote an extension? Long gone are the days when they could run system commands, and permissions must be declared in the manifest or they cannot be used, so if they aren’t in there, they’re not being used.
… 3 years ago ish?
I tried to clarify with the edit, you’re sorta right, it wasn’t a system command. It was “native messaging”
But you’re sort of full of it too, as you can use this native messaging to execute arbitrary logic. Nobody said you don’t need a manifest, and someone did say you needed a group policy entry too
I know what native messaging is, and I’m not “full of it” because native messaging does exactly nothing at all unless the user explicitly installs software at the system level to receive those messages and act upon them. If the user doesn’t know the difference between installing an extension in a browser and downloading & executing local programs, that’s an education problem, but having to do some separate installation step is a useful security obstacle. It’s much safer compared to old school extensions.
Also, Firefox Quantum came out in 2017, which used the manifest permissions system (wasn’t Chrome ahead of them?), so the tech you were originally talking about is older than 9 years, not 3.
💩 semantic distinctions, extensions can run whatever when you register the logic in advance, as suggested in my first comment
Just FYI: I think since manifest 3 or so you do need explicit permissions to access a sites HTML. And the end user can see which sites the extension has access to. Doesn’t make me install more extension than I really have to though.
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.
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 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.
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…
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.
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
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.
Yes. (But only if the extension is not shit (i.e. has advertisements, or is not limited to the respective website).) After all it means your service has a security model that doesn’t require the user to trust the website, which makes the service much more trustworthy.
I’m generally confused why such things aren’t used in the web more often (I guess you could count one time password generators, and the gnu taler extension). Probably no interest from website providers.
(Did you edit your post, or why do most of the other comments read like they didn’t even read your post?)
If it’s a solid extension which could be used by other websites, and it’s explained clearly like in your post by the website which needs it, then probably yes.
