31–40 of 100 posts
Tanker is an open-source client SDK that can be embedded in any application. Encrypt data, share it between users, create groups, etc. The SDK handles key exchanges, cryptographic operations, and identity verification for you. Also available for iOS and Android!
Is libsodium WASMed for the browser? WebCrypto is pretty good, altho its API is horrid, SEA is a nice wrapper for it ( https://gun.eco/docs/SEA ). It would be nice if Tanker exposed the cryptography operations, so it could be a more re-usable library. Is this possible?
It is not WASMed yet, but we are working on it.
> It would be nice if Tanker exposed the cryptography operations, so it could be a more re-usable library. Is this possible?
Tanker is more of a high-level library. It focuses on the ease of use, and tries to be hard to misuse, so it does the key handling and uses fixed algorithms.
We started the implementation after the Snowden revelations, tied to a web messaging platform called PEPS but after the sale of the company we realized that most of the value lied in the E2EE SDK itself, and not the messaging app.
We got there as many prospects were interested in the encryption part, but did not want yet another messaging platform.
I am still unsure about the market for this (disclaimer: I am no longer at Wallix, so I am not involved anymore with DataPeps although I created it). It was a tough sale, even as a part of an existing company with hundreds of customers. Many people felt the need for privacy, but were not ready to implement a new product or to involve developers to modify an existing product.
I do feel though that there is a need for a truly, non-profit, open source solution that handles E2EE. It would be highly beneficial for the whole developer ecosystem.
The DataPeps SDK (MIT license) is a good start. The accompanying service is currently proprietary.
I 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 can either see it as weak, best-effort security against accidental data leaks and such. Or you can follow the mega model where the hoster wants to protect itself from legal demands of monitoring user uploads that stop short of demanding encryption backdoors. It is a fairly weak and narrow security model. Nothing that should be used if you need serious security against powerful attackers.
I kind of like it for that, to be honest. There's a difference between trusting the good intentions of a company as a whole, and the good intentions and flawless skill of every single employee of it and it's subcontractors.
I wonder if there's something about this approach that I'm missing.
Ask HN: wouldn't you prefer that your data is browser-JS e2e encrypted than server-encrypted or not encrypted at all? In the context of "this is a web app. There's no mobile app or desktop app".
I'm specifically talking about the (rather common?) case in which your threat model does contain morally misguided employees, black hat hackers and stupid mistakes, but not nation state level adversaries.
ELI5: this is an open source library. What is the pricing page on the Tanker website all about?
I 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…
ELI5: this is an open source library. What is the pricing page on the Tanker website all about?
Seems like it's free for open-source projects, so the pricing should apply to commercial users. Sort of similar to what Qt does.
It seems what they are selling is not the software, but services it can use to manage exchange between users etc.
Earlier quoted context omitted.
Seems like it's free for open-source projects, so the pricing should apply to commercial users. Sort of similar to what Qt does.
If it is under Apache 2 license as the repo claims, very few commercial projects are going to have an issue with using it under the open-source terms. You can't say "this is open-source under license X, but you can't use it commercially!" (well, you can, but you are creating your own license that's not compatible with open source projects either). Qt solves this by being under license(s) not all commercial users want…
I 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…
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.