4 ms·

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you can verify the hash of code delivered from the server just as you can with desktop or mobile apps. All E2E encrypted apps will require some trust from the author except when they are open source and you can verify the hash. At a minimum, the E2E could be viewed as a best-attempt at security and would provide protection against information becoming exposed in the event of a database breach. EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Both the browser and App Store can distribute both closed and open source apps, and both closed and open source apps can securely implement E2E encryption. In both cases you placing trust in the author of the code, except in the case that it is both open source AND you verify the checksum, in which you can be reasonably secure that you know exactly what code is running.

tptacek 7y ago
This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.
- y96V89C668e7Q74 7y ago
  No because I'm also making the argument that the browser is not much less secure than the other JS platforms.
  - tptacek 7y ago
    That argument is also quite faulty, but I'm only engaging with the other argument you made.
    - y96V89C668e7Q74 7y ago
      Can you explain why it is faulty?
  - deleted 7y ago
    [deleted]
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 ago
  That 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 ago
    I 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 ago
  The 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.
nothrabannosir 7y ago
> EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Not exactly the same, and the difference is important. An iOS app is an iOS app is an iOS app: every user gets the same app. Malicious updates to bonafide releases cannot be targeted to specific users and will be distributed to everybody. Same for playstore. A browser effectively requests an update, directly, every single time the app is started.† Updates can be targeted very precisely, both to a time and a user. Circumventing this difference is not a detail, and eliding that when talking about browsers, honestly, implies regular use. Including the behaviour described above. † An exception is a trick using web workers and github which appeared on HN a while back. That was an actual novice use for JS crypto.

tptacek 7y ago

This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.

y96V89C668e7Q74 7y ago
No because I'm also making the argument that the browser is not much less secure than the other JS platforms.
- tptacek 7y ago
  That argument is also quite faulty, but I'm only engaging with the other argument you made.
  - y96V89C668e7Q74 7y ago
    Can you explain why it is faulty?
- deleted 7y ago
  [deleted]

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 ago
That 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 ago
  I 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 ago
The 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.

nothrabannosir 7y ago

> EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Not exactly the same, and the difference is important. An iOS app is an iOS app is an iOS app: every user gets the same app. Malicious updates to bonafide releases cannot be targeted to specific users and will be distributed to everybody. Same for playstore. A browser effectively requests an update, directly, every single time the app is started.† Updates can be targeted very precisely, both to a time and a user. Circumventing this difference is not a detail, and eliding that when talking about browsers, honestly, implies regular use. Including the behaviour described above. † An exception is a trick using web workers and github which appeared on HN a while back. That was an actual novice use for JS crypto.