Tanker: End-to-End Encryption SDK for JavaScript

Re:Tanker: End-to-End Encryption SDK for JavaScript by y96V89C668e7Q74 on Wednesday May 22, 2019 @12:55PM (#19983075)

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.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by tptacek on Wednesday May 22, 2019 @02:19PM (#19983921)

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

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by y96V89C668e7Q74 on Wednesday May 22, 2019 @02:45PM (#19984182)

No because I'm also making the argument that the browser is not much less secure than the other JS platforms.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by tptacek on Wednesday May 22, 2019 @02:47PM (#19984203)

That argument is also quite faulty, but I'm only engaging with the other argument you made.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by y96V89C668e7Q74 on Wednesday May 22, 2019 @02:51PM (#19984243)

Can you explain why it is faulty?

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by nothrabannosir on Wednesday May 22, 2019 @05:54PM (#19985971)

> 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.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by chrismeller on Wednesday May 22, 2019 @02:37PM (#19984104)

The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by AgentME on Wednesday May 22, 2019 @05:13PM (#19985576)

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.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by y96V89C668e7Q74 on Wednesday May 22, 2019 @02:44PM (#19984167)

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.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by chrismeller on Wednesday May 22, 2019 @04:06PM (#19984927)

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.

[ Parent | on HN ]

Re:Tanker: End-to-End Encryption SDK for JavaScript by y96V89C668e7Q74 on Wednesday May 22, 2019 @05:07PM (#19985507)

> 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?

[ Parent | on HN ]