Tanker: End-to-End Encryption SDK for JavaScript
1–10 of 100 posts
Re: Tanker: End-to-End Encryption SDK for JavaScript
#2Tanker 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!
Re: Tanker: End-to-End Encryption SDK for JavaScript
#3Usually the first thing I check in a project like this when it ends up on HN or Reddit is their symmetric cryptography features. Not because of any particularly scientific reason, but because it's a good heuristic on whether or not it's worth the time and energy to look at the rest of the code.
Tanker's looks like this:
https://github.com/TankerHQ/sdk-js/blob/master/packages/cryp...
Seems pretty OK to me.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#4The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here.
You can't TOFU in-browser JS, you can't trust audits and if any 3rd-party code is loaded into the environment you can't trust the entire origin.
The browser is the wrong tool for the job here.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#5The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
Could it be done with a browser extension?
Re: Tanker: End-to-End Encryption SDK for JavaScript
#6The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
Could it be done with a browser extension?
You'd think, but everyone I know that explored this option ended up just implementing desktop software instead (e.g. with Electron).
Re: Tanker: End-to-End Encryption SDK for JavaScript
#7The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
How is it any less trustworthy than a native app? It's perfectly possible to fingerprint any JavaScript that gets loaded.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#8The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
> The issue with client-side, in-browser encryption is that you cannot audit or trust the software.
I agree. A few months ago I experimented on ways [1] to automate side-channel verification of JS bundles (and other built assets) while linking them to the sources.
It's based on trusting both the public CI/CD server (to reproducibly build the sources as they are obtained from the repository) and the public repository provider (to serve everyone the same sources), which in a FOSS environment is a given (if services like GitHub and Travis are in the threat model, there's not much to be done). It was a PoC/WIP, but it seems there might be a use case for side-channel verification.
The threat models for this kind of "mistrust" in built assets (assuming traceability and transparency) would be:
- Any kind of MitM (proxy/cache/load balancer) in the path of the assets
- Hosting provider being compromised (unlikely but still a probability)
- Malicious external content being injected at runtime (XSS, CDN)
I'm surely missing more, and I'd love to discuss at lengths about what others may have setup to do side-channel verification (ie: when even TLS and/or the CA chain of trust can't be trusted).
Re: Tanker: End-to-End Encryption SDK for JavaScript
#9The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
Right now, sure.
That doesn't mean there are reasons to do client side crypto in the browser.
Finally, who is to say the web won't get TOFU someday.
I'm not even sure you can't do it today using service-workers.
Re: Tanker: End-to-End Encryption SDK for JavaScript
#10The issue with client-side, in-browser encryption is that you cannot audit or trust the software. Without fingerprinting/certification of the entire javascript-source the server could serve a manipulated source code that exfiltrates data, targeted only at specific users, i.e. not the auditors. Think NSLs or sufficiently crafty industrial espionage. CSPs do not save you here. You can't TOFU in-browser JS, you can't tr…
Could it be done with a browser extension?
You need the opposite of an extension, because in-browser crypto is incompatible with having any other "untrusted" extension. What you need is something with a reduced but secure feature set.