[dangtony98]

I wouldn't undermine and characterize it as fig leaf personally. I think this would raise a natural question on my end which is how do you evaluate the security of platforms like 1Password, Bitwarden, Vault, all of which also offer browser-based alternatives?

[danenania]

Well, what’s the point of end-to-end encryption? It’s so that even if the service gets hacked or has an employee go rogue, sensitive data will still be safe, right?

That’s what the average person thinks they are getting when they sign up for a service that advertises end-to-end encryption, but when it’s browser-based, that simply isn’t true. If a browser-based service gets hacked, it’s trivial for an attacker to disable the encryption, steal private keys, or just steal secrets directly, and it can be done in a way that leaves no record and is very difficult for the end-user to detect.

So you have a security measure that is implemented in a way that fully subverts the stated purpose of said security measure. I think fig leaf is a fair characterization.

You’re right that Infisical is far from the only product doing it. Though it’s fairly common knowledge in the security and encryption community, most developers and most users of these products aren’t aware of this issue, so for now, there isn’t a lot of incentive to do it right.

[dangtony98]

First off, I want to point out that browser-based services and applications can be made secure; we should keep this one clear, especially for readers here, because otherwise it would invalidate most if not all services that exist accessible via browser. Take AWS which houses infrastructure for so many organizations; we access it via browser and this is totally fine.

The assumption you highlight is specifically "if a browser-based service gets hacked." Well yes, if any browser-based service, like AWS, got hacked then it'd be all game over. However, given that appropriate security measures are implemented/taken, we can in fact design web applications that are securely accessible via browser; this is the basis for how we access applications on the web securely, those that are not end-to-end encrypted (E2EE).

What I'm trying to say is that your assumption is based on a particular case that is "if a browser-based service gets hacked." I think, however, if this assumption occurred to many other non-E2EE services we use on a daily basis, we'd have a huge problem as well. Now, the reverse assumption that is the browser-based service is not hacked, coupled with an E2EE architecture, I believe it's possible to design a secure system here where even the server cannot read the values of secrets which is a point of E2EE.

[danenania]

Sure, my point wasn't that a browser-based product is automatically insecure, just that end-to-end encryption implemented in a browser has minimal security benefit. The whole point of E2EE is to avoid leaking data even if you do get hacked or have an employee go rogue despite your best efforts.

"even the server cannot read the values of secrets"

I have to disagree there. Your server can easily read the values of secrets--it just needs to include an extra snippet of JS in the response to a single request. You're asking users to trust that your server won't do this, but they have no practical way to verify it. That isn't the case for EnvKey, which is all I wanted to point out.

Please don't take it the wrong way--you have clearly built a product that has good UX and that people like and I congratulate you on that. Many users out there will probably prefer the tradeoffs you've made, while others will prefer EnvKey's. I think it's fair, in the spirt of friendly competition, to highlight where those differences are so that people can make up their own minds with an accurate understanding of the threat model of each approach.