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

41–50 of 100 posts

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

#41

Post by detaro »

tux3 wrote: post #39
detaro wrote: post #38

Earlier quoted context omitted.

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…

There's a server component that's not on Tanker's Github, so commercial users probably can't start using the SDK without telling anyone.

They can legally use the SDK under the open source terms without paying if they find a way of using it without Tanker's servers. For the server access, they need to pay, thus that's what they're selling.

In contrast Qt is selling licenses to the code, not access to a hosted service.

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

#42

Post by TankerHQ »

mekane8 wrote: post #31
TankerHQ wrote: post #2

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!

Can you describe (briefly, in plain english) how it is able to securely encrypt on the client side? i.e. how does it hide its secret key from prying eyes?

The keys are generated client-side, and encryption is done client-side, the encrypted data is then sent to the app. On sharing, the key is encrypted for the recipient and sent to them through the Tanker server. Neither Tanker nor the app can see the clear data or keys.

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

#43

Post by penagwin »

eljimmy wrote: post #28
panarky wrote: post #27

Earlier quoted context omitted.

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.

cough it doesn't really matter cough

Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size!

HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.

Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information security. While bike locks could certainly work for the analogy as well they just weren't the choice we decided to go with.

HN - Your analogy falls apart with edge cases X, Y and Z', bike locks have been used for analogies since.....

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

#44

Post by cvwright »

marknadal wrote: post #30

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?

> WebCrypto is pretty good, altho its API is horrid

Agreed.

> SEA is a nice wrapper for it ( https://gun.eco/docs/SEA ).

Looks interesting. Thanks for sharing this.

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

#45

Post by osrec »

penagwin wrote: post #43
eljimmy wrote: post #28

Earlier quoted context omitted.

Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.

cough it doesn't really matter cough Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size! HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks. Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information secu…

Reminds me of a recent discussion I had on HN! https://news.ycombinator.com/item?id=19873055

This particular response really made me chuckle: https://news.ycombinator.com/item?id=19873801

My analogy related to SQL, but we ended up talking about the complexities of physics...

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

#46

Post by ricardobeat »

TankerHQ wrote: post #42
mekane8 wrote: post #31

Earlier quoted context omitted.

Can you describe (briefly, in plain english) how it is able to securely encrypt on the client side? i.e. how does it hide its secret key from prying eyes?

The keys are generated client-side, and encryption is done client-side, the encrypted data is then sent to the app. On sharing, the key is encrypted for the recipient and sent to them through the Tanker server. Neither Tanker nor the app can see the clear data or keys.

This doesn’t answer the question. How come the app cannot see the keys? What about the key used to encrypt the client side key?

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

#47

Post by the8472 »

skrebbel wrote: post #35
the8472 wrote: post #18

Earlier quoted context omitted.

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.

It might be great as an alternative to a "we store all data encrypted, pinky promise!" type of model, where eg you encrypt all messages on the backend before storing it in the DB, to reduce the potential impact of breaches, rogue employees, etc. 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 eve…

I think one issue is that for anyone with a cryptography/information security background "e2e encryption" evokes a very strong security claim where you treat the whole service provider as potential eavesdropper against which the protocol protects you, only conditional on mathematical proofs.

Carving out a much more complicated boundary around various kinds of lapses on the other hand muddies the water. It can still make sense, but it is difficult to convey that clearly. More than a pinky promise, less than certifiable security.

Also I would claim that black hat hackers could very well get into your production system and just inject some JS that exfiltrates cryptographic keys from users. It's blunt and far more easily caught than a targeted attack, but it can still possible and thus the system would fall short of that threat model.

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

#48

Post by malvosenior »

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…

More like:

Innovator - My fuse is blown so I'll replace it with a copper tube to get it to work.

HN - That's a bad idea, it's a fire hazard and you're putting yourself at risk.

Innovator - HN is full of no fun pendants.

--

It's in-browser JS encryption we're talking about. You should not trust it for many, many reasons.

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

#49

Post by kevin_thibedeau »

penagwin wrote: post #43
eljimmy wrote: post #28

Earlier quoted context omitted.

Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks.

cough it doesn't really matter cough Innovator - To help communicate with other HN readers, I created an analogy about mountain bikes and their tire size! HN - Not a good analogy to compare tire sizes for mountain biking to information security in Javascript. You should be comparing bicycle locks. Innovator - My analogy still makes sense though? Consider my physical safety to be roughly equivalent to information secu…

What color is the bike? I suggest camo for added security.

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

#50

Post by panarky »

malvosenior wrote: post #48
panarky wrote: post #27

Earlier quoted context omitted.

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…

More like: Innovator - My fuse is blown so I'll replace it with a copper tube to get it to work. HN - That's a bad idea, it's a fire hazard and you're putting yourself at risk. Innovator - HN is full of no fun pendants. -- It's in-browser JS encryption we're talking about. You should not trust it for many, many reasons.

You're not a real pedant until you can spell it correctly.

(Who says we're not fun?)

Post reply on HN