Open Bug 1732669 Opened 3 years ago Updated 1 year ago

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

Categories

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

Thunderbird 91
enhancement

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: lars.stintzing, Unassigned)

Details

(Whiteboard: [Prio2023])

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

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

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.

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?

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.

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.

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

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.

It is on the list for TB115.

(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!

Whiteboard: [Prio2023]
You need to log in before you can comment on or make changes to this bug.