|
|
|
|
|
by dangtony98
1124 days ago
|
|
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. |
|
"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.