11 ms·

Tanker: End-to-End Encryption SDK for JavaScript

140 points by TankerHQ 7y ago

TankerHQ 7y ago
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!
- dieblur 7y ago
  What algorithms? Pretty bare README for a cryptography project.
  - blastrock 7y ago
    Tanker developer here. We use libsodium as our underlying cryptographic library. It uses XChacha20/Poly1305 for symmetric encryption, Curve25519 for asymmetric encryption and signature, and Blake2 for hashing.
    - dieblur 7y ago
      Why would I use your library over the tried and true https://github.com/dchest/tweetnacl-js https://github.com/dchest/tweetnacl-js ?
      - blastrock 7y ago
        TweetNaCl is roughly equivalent to libsodium, on which Tanker builds. Tanker is easier to integrate into your app because it takes care of key sharing, multi-devices, user group managment, etc. These are all things you would have to handle by yourself using just a cryptographic library like TweetNaCl.
- mekane8 7y ago
  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?
  - TankerHQ 7y ago
    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.
    - ricardobeat 7y ago
      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?
      - t2riRXawYxLGGYb 7y ago
        This really does answer the question, spot on. The client side app does see the key(s) but it does not send them to the server. This is how E2E encryption works, browser or otherwise. I'm not sure specifically how Tanker is storing the client-side keys. Generally the client-side keys would be encrypted using an OS-level keychain.
        dmerej 7y ago
        Hi, other Tanker dev here. In the browser, we use IndexedDB (via dexie). Keys are encrypted using a secret that has to be provided when starting a Tanker session. On mobile we use an SQLCipher DB encrypted with the same secret.
CiPHPerCoder 7y ago
Usually 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/crypto/src/aead.js https://github.com/TankerHQ/sdk-js/blob/master/packages/cryp... Seems pretty OK to me.
the8472 7y ago
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 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.
- msy_ 7y ago
  Could it be done with a browser extension?
  - CiPHPerCoder 7y ago
    You'd think, but everyone I know that explored this option ended up just implementing desktop software instead (e.g. with Electron).
    - tptacek 7y ago
      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.
  - pjc50 7y ago
    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.
  - michaelchisari 7y ago
    Ideally, it would be something the browser supported internally (without external js or plugins) with very minimal javascript entrypoints to decode/encode.
dfabulich 7y ago
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 <script> tag on EveMail.com, because then they're trusting Eve to provide a legitimate encryption implementation, trusting Eve not to log their keystrokes in JS, etc. I can understand E2E js as a server-side library in Node (though I suspect it would be safer to run a battle-hardened library like GPG with node FFI). But, in client-side web code, how could this ever make sense?
- the8472 7y ago
  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.
  - skrebbel 7y ago
    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 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.
marknadal 7y ago
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 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?
- blastrock 7y ago
  > Is libsodium WASMed for the browser? 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.
- cvwright 7y ago
  > WebCrypto is pretty good, altho its API is horrid Agreed. > SEA is a nice wrapper for it ( https://gun.eco/docs/SEA https://gun.eco/docs/SEA ). Looks interesting. Thanks for sharing this.
hbbio 7y ago
For the record, we built a similar offering, cf. https://github.com/wallix/datapeps-sdk-js https://github.com/wallix/datapeps-sdk-js (in my previous life). 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.
instakill 7y ago
ELI5: this is an open source library. What is the pricing page on the Tanker website all about?
- tux3 7y ago
  Seems like it's free for open-source projects, so the pricing should apply to commercial users. Sort of similar to what Qt does.
  - detaro 7y ago
    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 to comply with, and selling support etc. It seems what they are selling is not the software, but services it can use to manage exchange between users etc.
    - tux3 7y ago
      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.
      - detaro 7y ago
        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.
- y96V89C668e7Q74 7y ago
  The client side code is open source. The server hosting aspect costs money. Open source is not the same as free.
alias_neo 7y ago
Your website and documentation is all a bit opaque. The title reads like a new encryption library for in the browser but in reality is an (advert for) encryption service, the SDK is open source because it requires your backend with its "Trustchain", the wording on the website is vague about how the Trustchain Private Key is "obtained". Regarding the service, my main issue is that with an open source SDK you're aiming at a certain type of people, developers, like many of us, but I see no mention of the algos used which immediately causes me to lose interest (between that and the sales/marketing heavy website). If you're really targeting developers I would suggest losing the marketing babble and get down to brass tacks. And finally, if the private key really is generated on your service, we can just pack up and go home. What it sounds like you have is a PKI infrastructure with open source SDK and "end-to-end" encryption of things, as much as end-to-end applies for keys/trust roots generated anywhere but locally. If any/all of this is wrong, please clarify.
- tux3 7y ago
  >And finally, if the private key really is generated on your service, we can just pack up and go home. Yeah, thankfully that key is generated client-side (in the browser) when you register. Seems pretty end-to-end to me. (And sure, you could always worry that the server will serve you malicious JS while you're registering to steal your client-side-generated key, but that would be pretty suicidal for any company, not a very realistic threat!)
  - alias_neo 7y ago
    Yeah it's sounds reasonable within those constraints given the clarification above.
- blastrock 7y ago
  > how the Trustchain Private Key is "obtained". The Trustchain private key is generated when you create a Trustchain. It is generated on your machine. You can try it and create a Trustchain yourself here: https://dashboard.tanker.io/ https://dashboard.tanker.io/ > And finally, if the private key really is generated on your service, we can just pack up and go home. It is not :) > What it sounds like you have is a PKI infrastructure with open source SDK and "end-to-end" encryption of things, as much as end-to-end applies for keys/trust roots generated anywhere but locally. That's pretty much it. The trust root is that Trustchain key, and Tanker never sees its private part. > Regarding the service, my main issue is that with an open source SDK you're aiming at a certain type of people, developers, like many of us, but I see no mention of the algos used which immediately causes me to lose interest (between that and the sales/marketing heavy website). If you're really targeting developers I would suggest losing the marketing babble and get down to brass tacks. I take note of this. The parts targeted at developers available at the moment are the documentation, the code examples, and the SDK sources. We will write and publish something that explains how it works under the hood.
nullwasamistake 7y ago
E2E 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.
- y96V89C668e7Q74 7y ago
  Genuine question - is this what you're referring to? Very curious. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-vila.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
  - nullwasamistake 7y ago
    Hadn't heard of it actually, but side channels have been an issue in browser security for a long time. Spectre caused a lot of changes in JS like disabling high precision clocks. But I'm afraid clock proxies are everywhere. The API surface is gigantic and all you need is a single call that reliably executes in constant time on the samr thread
_rlx_ 7y ago
https://docs.tanker.io/latest/guide/device-unlocking/#end-to-end_or_zero-trust https://docs.tanker.io/latest/guide/device-unlocking/#end-to... > If you want your app to be fully end-to-end, you can use the lower level > unlock mechanisms, which are all end-to-end compliant So if I want to use the SDK in a "fully" end-to-end secure way, I first need to implement by myself a secure way to transmit the user root secret (the unlock key) between the user's devices, and make sure this key is always accessible so that users don't loose access to their data. This doesn't seem like an easy task...
- blastrock 7y ago
  No, the unlock key is for the user to keep, and never be transmitted by anyone else than the user themselves. If you do the transmission, it's not end to end anymore. This option is only for users concerned about security, the other unlock methods are less strong but still provide security.
aytekin 7y ago
We have been supporting this feature on our web app for many years: https://www.jotform.com/encrypted-forms/ https://www.jotform.com/encrypted-forms/ Knowing only you have access to tha data is a good thing. For example, we are able to host our internal employee feedbacks and reviews on our own forms without worrying about a sysadmin or database admin having access to it. I understand the concerns about client side manipulation but that is hard to do without leaving a trail on our code commit history. Both system and product changes can only be done by code commits. You cannot protect systems with a single perfect security solution. You have to be paranoid and have many layers in your security model. This may not be the silver bullet, but this greatly enhances the security.

140 points by TankerHQ 7y ago

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!

dieblur 7y ago
What algorithms? Pretty bare README for a cryptography project.
- blastrock 7y ago
  Tanker developer here. We use libsodium as our underlying cryptographic library. It uses XChacha20/Poly1305 for symmetric encryption, Curve25519 for asymmetric encryption and signature, and Blake2 for hashing.
  - dieblur 7y ago
    Why would I use your library over the tried and true https://github.com/dchest/tweetnacl-js https://github.com/dchest/tweetnacl-js ?
    - blastrock 7y ago
      TweetNaCl is roughly equivalent to libsodium, on which Tanker builds. Tanker is easier to integrate into your app because it takes care of key sharing, multi-devices, user group managment, etc. These are all things you would have to handle by yourself using just a cryptographic library like TweetNaCl.
mekane8 7y ago
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?
- TankerHQ 7y ago
  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.
  - ricardobeat 7y ago
    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?
    - t2riRXawYxLGGYb 7y ago
      This really does answer the question, spot on. The client side app does see the key(s) but it does not send them to the server. This is how E2E encryption works, browser or otherwise. I'm not sure specifically how Tanker is storing the client-side keys. Generally the client-side keys would be encrypted using an OS-level keychain.
      - dmerej 7y ago
        Hi, other Tanker dev here. In the browser, we use IndexedDB (via dexie). Keys are encrypted using a secret that has to be provided when starting a Tanker session. On mobile we use an SQLCipher DB encrypted with the same secret.

CiPHPerCoder 7y ago

Usually 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/crypto/src/aead.js https://github.com/TankerHQ/sdk-js/blob/master/packages/cryp... Seems pretty OK to me.

the8472 7y ago

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

msy_ 7y ago
Could it be done with a browser extension?
- CiPHPerCoder 7y ago
  You'd think, but everyone I know that explored this option ended up just implementing desktop software instead (e.g. with Electron).
  - tptacek 7y ago
    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.
- pjc50 7y ago
  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.
- michaelchisari 7y ago
  Ideally, it would be something the browser supported internally (without external js or plugins) with very minimal javascript entrypoints to decode/encode.

dfabulich 7y ago

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 <script> tag on EveMail.com, because then they're trusting Eve to provide a legitimate encryption implementation, trusting Eve not to log their keystrokes in JS, etc. I can understand E2E js as a server-side library in Node (though I suspect it would be safer to run a battle-hardened library like GPG with node FFI). But, in client-side web code, how could this ever make sense?

the8472 7y ago
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.
- skrebbel 7y ago
  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 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.

marknadal 7y ago

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 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?

blastrock 7y ago
> Is libsodium WASMed for the browser? 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.
cvwright 7y ago
> WebCrypto is pretty good, altho its API is horrid Agreed. > SEA is a nice wrapper for it ( https://gun.eco/docs/SEA https://gun.eco/docs/SEA ). Looks interesting. Thanks for sharing this.

hbbio 7y ago

For the record, we built a similar offering, cf. https://github.com/wallix/datapeps-sdk-js https://github.com/wallix/datapeps-sdk-js (in my previous life). 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.

instakill 7y ago

ELI5: this is an open source library. What is the pricing page on the Tanker website all about?

tux3 7y ago
Seems like it's free for open-source projects, so the pricing should apply to commercial users. Sort of similar to what Qt does.
- detaro 7y ago
  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 to comply with, and selling support etc. It seems what they are selling is not the software, but services it can use to manage exchange between users etc.
  - tux3 7y ago
    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.
    - detaro 7y ago
      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.
y96V89C668e7Q74 7y ago
The client side code is open source. The server hosting aspect costs money. Open source is not the same as free.

alias_neo 7y ago

Your website and documentation is all a bit opaque. The title reads like a new encryption library for in the browser but in reality is an (advert for) encryption service, the SDK is open source because it requires your backend with its "Trustchain", the wording on the website is vague about how the Trustchain Private Key is "obtained". Regarding the service, my main issue is that with an open source SDK you're aiming at a certain type of people, developers, like many of us, but I see no mention of the algos used which immediately causes me to lose interest (between that and the sales/marketing heavy website). If you're really targeting developers I would suggest losing the marketing babble and get down to brass tacks. And finally, if the private key really is generated on your service, we can just pack up and go home. What it sounds like you have is a PKI infrastructure with open source SDK and "end-to-end" encryption of things, as much as end-to-end applies for keys/trust roots generated anywhere but locally. If any/all of this is wrong, please clarify.

tux3 7y ago
>And finally, if the private key really is generated on your service, we can just pack up and go home. Yeah, thankfully that key is generated client-side (in the browser) when you register. Seems pretty end-to-end to me. (And sure, you could always worry that the server will serve you malicious JS while you're registering to steal your client-side-generated key, but that would be pretty suicidal for any company, not a very realistic threat!)
- alias_neo 7y ago
  Yeah it's sounds reasonable within those constraints given the clarification above.
blastrock 7y ago
> how the Trustchain Private Key is "obtained". The Trustchain private key is generated when you create a Trustchain. It is generated on your machine. You can try it and create a Trustchain yourself here: https://dashboard.tanker.io/ https://dashboard.tanker.io/ > And finally, if the private key really is generated on your service, we can just pack up and go home. It is not :) > What it sounds like you have is a PKI infrastructure with open source SDK and "end-to-end" encryption of things, as much as end-to-end applies for keys/trust roots generated anywhere but locally. That's pretty much it. The trust root is that Trustchain key, and Tanker never sees its private part. > Regarding the service, my main issue is that with an open source SDK you're aiming at a certain type of people, developers, like many of us, but I see no mention of the algos used which immediately causes me to lose interest (between that and the sales/marketing heavy website). If you're really targeting developers I would suggest losing the marketing babble and get down to brass tacks. I take note of this. The parts targeted at developers available at the moment are the documentation, the code examples, and the SDK sources. We will write and publish something that explains how it works under the hood.

nullwasamistake 7y ago

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

y96V89C668e7Q74 7y ago
Genuine question - is this what you're referring to? Very curious. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-vila.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
- nullwasamistake 7y ago
  Hadn't heard of it actually, but side channels have been an issue in browser security for a long time. Spectre caused a lot of changes in JS like disabling high precision clocks. But I'm afraid clock proxies are everywhere. The API surface is gigantic and all you need is a single call that reliably executes in constant time on the samr thread

_rlx_ 7y ago

https://docs.tanker.io/latest/guide/device-unlocking/#end-to-end_or_zero-trust https://docs.tanker.io/latest/guide/device-unlocking/#end-to... > If you want your app to be fully end-to-end, you can use the lower level > unlock mechanisms, which are all end-to-end compliant So if I want to use the SDK in a "fully" end-to-end secure way, I first need to implement by myself a secure way to transmit the user root secret (the unlock key) between the user's devices, and make sure this key is always accessible so that users don't loose access to their data. This doesn't seem like an easy task...

blastrock 7y ago
No, the unlock key is for the user to keep, and never be transmitted by anyone else than the user themselves. If you do the transmission, it's not end to end anymore. This option is only for users concerned about security, the other unlock methods are less strong but still provide security.

aytekin 7y ago

We have been supporting this feature on our web app for many years: https://www.jotform.com/encrypted-forms/ https://www.jotform.com/encrypted-forms/ Knowing only you have access to tha data is a good thing. For example, we are able to host our internal employee feedbacks and reviews on our own forms without worrying about a sysadmin or database admin having access to it. I understand the concerns about client side manipulation but that is hard to do without leaving a trail on our code commit history. Both system and product changes can only be done by code commits. You cannot protect systems with a single perfect security solution. You have to be paranoid and have many layers in your security model. This may not be the silver bullet, but this greatly enhances the security.