What does the end-to-end encryption (E2EE) feature for chat do?
Related info: Looking for details on how to set this up? Please see How do I set up off-the-record (OTR) end-to-end encryption (E2EE) for my chat boxes?
End-to-end encryption (E2EE) means that only the two parties (ends) participating in a chat can read the messages. No one else (including LibraryH3lp support personnel) can read the messages because the messages are encrypted. The specific cryptographic protocol used to encrypt chat messages is Off the Record Messaging (OTR).
As a further proof against man-in-the-middle (MITM) eavesdropping, operators answering chats in the webclient for staffing can optionally provide the private key from a Digital Signature Algorithm (DSA) key pair so that the guest's chat box (which has the matching public key fingerprint) can confirm that the answering operator is authorized to communicate with the guest.
Wait. Aren't chats encrypted by default?
Yes. Even without setting up E2EE, guest chat boxes use HTTPS by default and the operator's webclient for staffing always uses HTTPS. With HTTPS, chat messages are encrypted in transit over the network. However unlike with E2EE chats, these chat transcripts can also be read by authenticated users that have appropriate permissions in Chat History while a chat is active, and also after a chat has ended if transcript storage has been enabled. Chat transcript retention provides the ability for later access and can be useful for things like training, data assessment/analysis, and personnel review.
Even though this OTR chat is active, its transcript cannot be seen in Chat History.
If my chats are already encrypted, why would I want to set up E2EE/OTR?
Actually we anticipate that most customers will not set up E2EE/OTR, since messages are encrypted in transit via HTTPS and the ability for later transcript review is an important part of quality assurance, assessment, and training for many organizations.
However customers in countries with very strong data privacy regulations or any customer with stringent privacy requirements might be interested in E2EE. For example, if E2EE is configured, then there is no way for LibraryH3lp support staff to access chat transcripts, and that can be an important feature.
Generally how does it work?
The guest does not have to do anything special to initiate an OTR chat. Your local administrator sets up OTR ahead of time as part of the chat skin used for the chat box. When the guest sends a message to begin a chat, they'll see a brief "Connecting..." indicator which indicates the start of the OTR negotiation process which happens automatically and behind the scenes between the two ends of the conversation (the guest and the answering chat operator).
When the chat goes out to the operator(s) in the webclient, the operators see a note that the chat is OTR and, instead of plainly seeing the guest's initial message(s), the operator(s) must first claim the chat by clicking a button. Only after an operator claims the chat, will the operator actually see the guest's message(s). The operator can close the chat window if the operator does not want to claim the chat, leaving it open for another receiving operator to claim.
The chat operator cannot see the guest's messages until the operator claims the chat. Alternatively the operator can close the chat window, leaving the chat available for another receiving operator to claim.
How do transfers work? That brings in another person.
In the case of
transfers or continued chats (the operator previously chatting with the guest is now unavailable for some reason), the operator who receives the transfer or continued chat will not have immediate access to any of the previous messages for the chat. In such cases, the operator can click a button to request that the guest send them the previous messages. If the guest permits the request, then the operator will be sent the previous messages. If the guest declines, then the operator has to do without the prior messages.
Left: chat operator's view of an accepted transfer. Right: guest's view of permission to share prior messages with receiving operator.
What else is there to be aware of?
Because only the guest and the answering operator can read the messages, chat module features such as
email transcript and
tag for follow-up will not work since in each of these cases there is no unencrypted transcript available for third-parties such as email recipients. And even if chat transcript storage is enabled on the queue, the transcript of an OTR chat will not be available because that transcript is encrypted.
However, the answering operator will have two other chat management options available for use at their discretion -- copy transcript and download transcript. Either or both of these options can be used since that answering operator has access to the unencrypted messages locally within the browser.
The answering chat operator can copy the chat transcript to the clipboard or download it to a file, at their discretion. The email transcript button is disabled. Chats can be tagged with categories but there is no tag-for-followup option since it would involve emailing the transcript.
Does this work in all web browsers?
E2EE/OTR does not work with Internet Explorer 11 because that web browser does not have sufficient cryptography support to negotiate the encryption. We are not aware of any modern web browsers that are not supported.
Is E2EE/OTR available with the SMS add-on?
No. E2EE/OTR is only available for web-based chats. E2EE/OTR is not available for SMS (texting) chats.
Does E2EE/OTR work if my chat operators use Pidgin?
Yes, but only if the chat operators have the
Off-the-Record messaging plugin enabled, and only if you staff with one operator at a time (see "important note" below). A Pidgin operator WITHOUT the OTR plugin cannot chat successfully with a guest using an OTR-enabled chat box skin. Pidgin operators cannot import the generated private key and must use the pidgin plugin's default OTR negotiation.
Pidgin operators that have enabled the OTR plugin can still chat with guests that are not using OTR-enabled chat box skins.
Important note: Pidgin's OTR plugin will "auto-claim" chats from guests when the Pidgin operator receives them. This is fine if the Pidgin operator is the only one staffing chat, but when a multi-operator workflow is in use, this is not ideal. For example, if you have other operators using the webclient, the Pidgin user will always initially "auto-claim" the chats. If you will have more than one operator simultaneously staffing an E2EE-enabled chat service with Pidgin, one of them will auto-claim the chat first.
Can I provide my own DSA keys/fingerprints?
Yes! When setting up E2EE for your chat skins, you'll use the "Provide my own public key" button where you can upload the public key fingerprint you've generated. The corresponding private key is never shared with LibraryH3lp and needs to be distributed to operators securely.
FAQ URL:
