4 ms·
The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.
by chrismeller 7y ago
The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.
- y96V89C668e7Q74 7y agoThat doesn't make it any less secure, there are plenty of open source cryptography libraries and apps like Signal. Closed source doesn't equate to secure.
- chrismeller 7y agoI don’t think I said any of those things? Crypto happening in the browser (or any browser-based “app”) is not ever going to be ok from a dozen different security perspectives. That makes Node the only possible platform where it makes sense, and that’s what I said.
- y96V89C668e7Q74 7y ago> is not ever going to be ok from a dozen different security perspectives. What dozen perspectives? > Any of the other examples can easily be decompiled or reversed. reply ... I don’t think I said any of those things? Sorry, I interpreted "decompiled or reversed" as insecure. I'm curious why there's a problem if the frontend code can be reversed? Or another way to ask this is, how is that any different from an open source app?
- AgentME 7y agoThe only case that obfuscating code from the user is useful for is DRM. That's not what end-to-end encryption is about. End-to-end encryption is about allowing two users to send messages to each other using keys of users that each user owns on their own device, so no server in the middle can eavesdrop. That use-case isn't impacted by each user being able to reverse-engineer the code they're running. It's probably better if the code they're running is open-source so they can possibly verify it or get someone else to verify it for them.