Earlier quoted context omitted.
Good point. Is there a better name for this that doesn't hint at said security claim?
Just "client side encryption", don't mention or even explicitly disavow "end-to-end" claims.
Nice, I like it. Thanks!
Tanker: End-to-End Encryption SDK for JavaScript
71–80 of 100 posts
Re: Tanker: End-to-End Encryption SDK for JavaScript
#72I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com…
[deleted]
Re: Tanker: End-to-End Encryption SDK for JavaScript
#73I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com…
You assume the client side code is served by the middleman. But it can also be a browser based "app" that is loaded from the hdd. Unfortunately Chrome et.al has taken a step away from this model and deprecated app manifest (? cant remember the proper name) in favour of the more convenient service worker that is able to push updates in the background. Serverless/offline web apps didnt really take off. Theres ChromeOS and FirefoxOS for feature phones. But "web apps" for desktop are currently nw.js/Electron apps. It would however be just fine to use the local browser and not ship an entire browser with the web app. Most browsers allow "chromeless" mode (without address bar etc). But there needs to be a more relaxed security mode when running code as an app. Because its almost useless now with CORS and some features requiring SSL which you cant have when loading from hhd.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#74Earlier quoted context omitted.
The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.
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.
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.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#75Earlier quoted context omitted.
Subresource integrity can help a bit. You still need to bootstrap from a trusted source though (eg a minimal index.html stored locally). And at that point, you really are back to figuring out a way to distribute a "known good" piece of software. https://developer.mozilla.org/en-US/docs/Web/Security/Subres... Ed: it might, for example be easier to email an attached minimal html file, than a 50mb electron app (multiply…
You would still have to combine SRI with a fairly strong CSP to avoid any code execution except SRI-covered stuff. It would be a good PoC I guess, but not practical yet for most people.
We're talking about a html file that's basically:
Re: Tanker: End-to-End Encryption SDK for JavaScript
#76E2E encryption in JS in browser will never be secure. In a client with shared threads and untrusted content on the page it will always be vulnerable to timing attacks. It's unrealistic to create a constant-time implementation in JavaScript.
For node/backend this is great but please don't use it on a public site.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#77Earlier quoted context omitted.
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.
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.
> 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?
Re: Tanker: End-to-End Encryption SDK for JavaScript
#78I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com…
There are two clear scenarios where this makes sense:
1. When the client code is content-addressed, and that content addressing is enforced by the browser e.g. https://ipfs.io/ipfs/Qmfgh... with browsers supporting dweb protocols natively as Firefox is working on
2. When the web ui is served over localhost from an app you've downloaded and can independently verify. This could be a local only app, or it could be a p2p app.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#79Earlier quoted context omitted.
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…
The only argument you can possibly make here is for Node. Any of the other examples can easily be decompiled or reversed.
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.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#80I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a tag on EveMail.com…
Prevention of passive monitoring by commonly installed SSL interception boxes in corporate environments. This is something I would consider if I was designing a app where users complain about their employers for example. Won't stop a state level agency but it will stop the average sysadmin dead.
Cloudflare is an extremely-common service that does SSL-interception on tons of websites.
If I hosted a website (with some kind of user-messaging functionality) on Cloudflare, and I trusted Cloudflare to not modify the data that went through them, but I was worried that they may be recording all the data that went through them, then using a javascript end-to-end encryption library would be perfect for my case.