Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tanker: End-to-End Encryption SDK for JavaScript

github.com

Post reply on HN
Print view View original

21–30 of 100 posts

Re: Tanker: End-to-End Encryption SDK for JavaScript

#21

Post by the8472 »

e12e wrote: post #13
the8472 wrote: post #4

The 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…

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.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#22

Post by tptacek »

CiPHPerCoder wrote: post #6
msy_ wrote: post #5

Earlier quoted context omitted.

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

Part of that is because by the time you're asking an ordinary user (not a super-opinionated "sophisticate" on HN) to install a Chrome extension, you're 95% of the way towards getting them to install a desktop application anyways, and that remaining 5% of effort is often worth the extra flexibility the Electron app gets you.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#23

Post by blastrock »

dfabulich wrote: post #16

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 are right, you'd still have to trust the webmail/chat provider if you want to chat securely. Tanker still protects against data leaks from the app servers in this case.

We also provide SDKs for Android and iOS. They protect against more threats as you can install an app you know the provenance and the app doesn't auto update like a website that you reload every time you open your browser. If you are concerned about security, you could even compile the apps yourself in this case.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#24

Post by jand »

dfabulich wrote: post #16

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…

> I keep asking, what is the threat model for end-to-end encryption in JS?

Even if there were no specific attack vector guarded by client side encryption, others reasons for JS-/client-side encryption may exists.

I could imagine some legal reasoning like 'The data was already encrypted when the client stored it on our servers, we had not knowledge of the illicit content.'.

For a share-hoster that alone might be reason enough to feel the need for JS-/client-side encryption.

Is that too far fetched?

Re: Tanker: End-to-End Encryption SDK for JavaScript

#25

Post by Townley »

dfabulich wrote: post #16

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…

It could be useful in a scenario where you trust the service provider to provide a legitimate encryption implementation.

If I trust Eve to provide an E2E service, in the same way I trust Whatsapp (not a given by any means), then an open source implementation of those tools lowers barriers to entry. That's a mixed bag in that it potentially enables bad security models, but overall I think access to tools is a good thing

Re: Tanker: End-to-End Encryption SDK for JavaScript

#26

Post by itake »

dfabulich wrote: post #16

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…

This could be used in React Native or electronjs.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#27

Post by panarky »

the8472 wrote: post #4

The 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…

Innovator - To help me ride my bike on dangerous mountain trails, I made a sturdy frame and fat, knobby tires.

HN - The bike is the wrong tool for transportation in mountains. For absolute safety you must only use a cable car or funicular.

Innovator - But cable cars and funiculars are impractical for the mountain trails I want to ride, and my current road race bike with weak frame and skinny tires is dangerous off-road.

HN - A sturdy frame and fat, knobby tires only provide the illusion of safety, which is worse than no safety at all. Never go to the mountains unless you're in a cable car or funicular.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#28

Post by eljimmy »

panarky wrote: post #27
the8472 wrote: post #4

The 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…

Innovator - To help me ride my bike on dangerous mountain trails, I made a sturdy frame and fat, knobby tires. HN - The bike is the wrong tool for transportation in mountains. For absolute safety you must only use a cable car or funicular. Innovator - But cable cars and funiculars are impractical for the mountain trails I want to ride, and my current road race bike with weak frame and skinny tires is dangerous off-ro…

Not a good analogy to compare tire sizes for mountain biking to information security in Javascript.

You should be comparing bicycle locks.

Re: Tanker: End-to-End Encryption SDK for JavaScript

#29

Post by jakelazaroff »

the8472 wrote: post #17
jakelazaroff wrote: post #7

Earlier quoted context omitted.

How is it any less trustworthy than a native app? It's perfectly possible to fingerprint any JavaScript that gets loaded.

In theory it's possible, sure. But in practice webapps are not set up for reproducible, auditable, signed builds with zero dynamic execution of 3rd-party code and making those signatures available in a standarized format. Plus browsers lack the tools to make this kind of fingerprinting effortless to verify for the user.

Sure, but how often do users do this in practice for any apps? I know I don't check the fingerprints for Signal or WhatsApp or iMessage on my phone.

And even if the actual binary I'm running is secure, plenty of apps that claim to provide E2E encryption don't give me any way to verify the key of the other user. How do I know that iMessage or Facebook Messenger aren't inserting their own key pairs me and the people I'm messaging?

Re: Tanker: End-to-End Encryption SDK for JavaScript

#30

Post by marknadal »

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?

Post reply on HN