1732669 - The encryption status (PGP/S-MIME/unencrypted) should be added to the ComposeDetails of the WebExtension API.

Status: RESOLVED FIXED

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Description

[lars.stintzing]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

I am working on an Add-On that implements some security and privacy-enhancements, including checking the encryption-status before sending an email.

Actual results:

As of today, there is no way to get the encryption status while composing/sending an email. Therefore, it is not possible, to create an Add-On that issues warnings based on the encryption status.

Expected results:

The encryption status (PGP/S-MIME/unencrypted) should be added to the ComposeDetails of the WebExtension API ( https://webextension-api.thunderbird.net/en/91/compose.html#composedetails ).

Comment 1

[Alexander Bergmann]

I also think the encryption status as well as the properties "encrypt" and "sign" should be accessible by MailExtensions. An add-on should be allowed to get and set these properties via ComposeDetails, e.g. in the functions getComposeDetails(), setComposeDetails(), beginNew(), beginReply(), beginForward().

Comment 2

[John Bieling (:TbSync)]

I need help here to shape out the information which are to be made available. I guess it would be a new "encryption" member of the ComposeDetails like so:

encryption : {
  technology: "smime" or "pgp" or "disabled"
  sign: bool
  encrypt: bool
  pgpOptions : {
   encryptSubject: bool,
   attachPuplicKey: bool
  }
}

Are there special smimeOptions? Setting an unsupported technology must throw, so we probably also need supportedTechnologies in there in order to see what technology can be used.

It would help me a lot, if you already have an Experiment implementation (or could try to work on one), which I could use for this patch.

Comment 3

[John Bieling (:TbSync)]

This is the last missing piece (see bug 1749196 Comment #9). Any feedback from the encryption experts, from the developers who will be using this API regarding Comment #2?

Comment 4

[lars.stintzing]

Sorry, I lost track of this issue. I'm no encryption expert, but one thing I'd really like to do would be to add an opportunistic encryption option (like the 21 years old idea here: https://bugzilla.mozilla.org/show_bug.cgi?id=135636 ).

Just getting the encryption status in a read-only-way would we enough to at least add a warning, but being able to set the status would be even better to get the most out of the encryption option.

The addition to the composeDetails you proposed looks very good to me, but like I said, I'm no expert and have only worked with PGP and not with SMIME.

I think an Experiment implementation can't be provided because the required functions are not exported. I was able to get the encryption keys for the recipients addresses via an Experiment API but didn't manage to get or set the encryption status.

Comment 5

[jschoett]

In our company we would also need this API to enable/disable encryption! I would like to have all internal e-mails automatically PGP-encrypted but no external recipients have PGP. So either our employees have to explicitly enable encryption for all internal mails or they have to disable encryption for all external mails.

A solution would be an add-on similar to Correct Identity that can toggle encryption based on rules. I would adapt this add-on but there is no API for that yet.

Comment 6

[Teal Dulcet [:tdulcet] (TB Council)]

(In reply to John Bieling (:TbSync) from comment #2)

I need help here to shape out the information which are to be made available. I guess it would be a new "encryption" member of the ComposeDetails

For an add-on I would like to develop, it would be useful to also have this information in the messages.MessageHeader object.

Are there special smimeOptions?

For both S/MIME and PGP/MIME, the existing webRequest.SecurityInfo and webRequest.CertificateInfo objects show the type of information that would be needed. While many of the TLS related properties in the former obviously would not apply, the CertificateInfo object should be an exact fit for S/MIME certificates.

Comment 7

[Ken Bass]

There really needs to be a way for an extension to enable/disable encryption. The basic functionally needed is to be able to manipulate the S/MIME 'Digitally Sign' and 'Encrypt' menu options.

The use case is for extensions that want to enable/disable encryption based on criteria such as looking up the recipient in an address book or enabling it on a per domain level.

There was a plugin that provided this ability https://addons.thunderbird.net/en-us/thunderbird/addon/security-settings-from-addr/
However it stopped working with the Webextension update.

Comment 8

[John Bieling (:TbSync)]

It is on the list for TB115.

Comment 9

[lars.stintzing]

(In reply to John Bieling (:TbSync) from comment #8)

It is on the list for TB115.

Thanks, I'm still planing on adding that to my Add-On!

Comment 10

[John Bieling (:TbSync)]

Attachment: Bug 1732669 - Expose encryption settings in ComposeDetails and add compose.getEncryptionStatus(). r=kaie,mkmelin

This is adding methods to get and modify the encryprtion settings of a
given compose window. The patch duplicates checkRecipientCerts() and
checkRecipientKeys() from MsgComposeCommands.js, because they are
currently not accessible from the outside. The implementation is
however changed to be fully based on Promises.

Comment 11

[John Bieling (:TbSync)]

Try with artifacts:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=d94ec298e0622b3e84b48404eb2cb8fe140662b0

Comment 12

[John Bieling (:TbSync)]

I would like to ask for your help to test this in a real world environment. The patch adds a browser.compose.getEncryptionStatus(<tabId>), which returns information about the encryption status of that compose tab:

{
  "pgp": {
    "supportsEncryption": true,
    "supportsSigning": true,
    "unsupportedRecipients": [
      "[e-mail]"
    ]
  },
  "smime": {
    "supportsEncryption": false,
    "supportsSigning": false,
    "unsupportedRecipients": []
  }
}

That means the current identity fully supports PGP, but not S/MIME. However, there is no key for recipient [e-mail] (which is in one of the recipient fields), and encryption will fail.

The ComposeDetails type now has a selectedEncryptionTechnology member:

  "selectedEncryptionTechnology": {
    "type": "pgp",
    "encryptBody": false,
    "encryptSubject": false,
    "signMessage": false
  }

This is the current encryption setting of the composer. Updating the composer with

  "selectedEncryptionTechnology": {
    "type": "smime",
    "encryptBody": false,
    "signMessage": false
  }

Will fail, because the identity does not support S/MIME (as returned by browser.compose.getEncryptionStatus(<tabId>));

The try run in the previous comment has build artifacts, which you can download, so you could run a version of TB 128 Daily with this functionality.

Linux 64bit: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Rwo4cbZ_SuWBetgsHTUykw/runs/0/artifacts/public/build/target.tar.bz2
Windows 64bit: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ZdCtzG--RuaGRq_EkWONrw/runs/0/artifacts/public/build/target.zip

Feedback is appreciated. Thanks for your help.

Comment 13

[Kai Engert [:KaiE:]]

(In reply to lars.stintzing from comment #4)

Sorry, I lost track of this issue. I'm no encryption expert, but one thing I'd really like to do would be to add an opportunistic encryption option (like the 21 years old idea here: https://bugzilla.mozilla.org/show_bug.cgi?id=135636 ).

Note that bug 135636 was fixed one year ago, and is available in the TB 115.x release.

To clarify, bug 135636 isn't exactly "opportunistic" encryption.
It doesn't encrypt simply because a correspondent key can be found.
The implementation still requires that someone has approved/accepted the correspondent's certificate (which is the user themselves for OpenPGP, or a trusted S/MIME CA).

Comment 14

[Kai Engert [:KaiE:]]

John, I suspect the enhancement can be implemented in a simpler way.

For querying, it should be sufficient to query the values of the global variables of the composer window that track the current state.

The state of those flags state what the users wants to do.

The functions you have looked at, have another purpose. They check whether the user's wish (encrypt) is possible or not, and update the UI with warnings and notifications (if necessary), and block sending of the message (if necessary, until the problem is resolved by the user).

So, for obtaining the status, it should be sufficient to query the attributes like:

• gSendEncrypted
• gSendSigned
  etc.

If you want to offer the ability to toggle encryption/signing on or off, I suggest that you call the existing functions, that are also called when the user triggers the respective choice in the UI. Look at

• toggleEncryptMessage()
• toggleGlobalSignMessage()

Comment 15

[John Bieling (:TbSync)]

After a longer discussion with Kai, we will not ship browser.compose.getEncryptionStatus() for Thunderbird 128 ESR initially. This patch will be reduced to just being able to get/set the ComposeDetails and enable/disable/modify the encryption settings.

There are security concerns, that a function I have created (partially duplicated) may produce a false-negative: It may report that encryption is not possible, while it actually is. The add-on could then use that information to disable encryption.

This will be tackled after the release of Thunderbird 128 ESR in Bug 1898722.

Comment 16

[John Bieling (:TbSync)]

Attachment: Bug 1732669 - Expose encryption settings in ComposeDetails. r=kaie,mkmelin

This is adding methods to get and modify the encryption settings of a
given compose window.

Comment 17

[John Bieling (:TbSync)]

Attachment: Bug 1732669 - Expose encryption capabilities in the MailIdentity. r=kaie

In order to find an identity which supports encryption, we are exposing
the encryption capabilities. This is a read-only property and cannot be
changed by extensions.

Depends on D211558

Comment 18

[Phabricator Automation]

Comment on attachment 9404252 [details]
Bug 1732669 - Expose encryption capabilities in the MailIdentity. r=kaie

Revision D211823 was moved to bug 1899285. Setting attachment 9404252 [details] to obsolete.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/cbd2334ce115
Expose encryption settings in ComposeDetails. r=kaie