Thunderbird 78, Enigmail and OpenPGP secure email

217 views
Skip to first unread message

Kai Engert

unread,
Oct 8, 2019, 3:20:25 AM10/8/19
to tb-pl...@mozilla.org
This message is related to today's announcement on the Thunderbird blog:
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/

Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
offering built-in support for S/MIME for many years, and will continue
to do so.

The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.

Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.

As a replacement, the Thunderbird team intends to develop integrated
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).

We are happy that Patrick Brunschwig, who has been developing and
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.

Many details need to be considered for this initiative.

Please have a look at the following article which describes the approach
we'd like to take:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

If you have feedback, please post it to this list.

This feature was originally requested in
https://bugzilla.mozilla.org/show_bug.cgi?id=22687

Kai
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning

Ludovic Hirlimann

unread,
Oct 8, 2019, 7:40:53 AM10/8/19
to Thunderbird planning (moderated), Kai Engert
On 10/8/19 9:20 AM, Kai Engert wrote:
> Please have a look at the following article which describes the approach
> we'd like to take:
> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>
> If you have feedback, please post it to this list.


Are you considering leveraging Pronto mail's PGP library (like bugzilla
did a year or so ago) ?

(it doesn't support all encryption protocols, has issues with big keys
(like mine was over 800kb with signatures).


Are we following
https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
gpg/pgp in thunderbird will follow the new standard and make the wot
more usable ?


Regarding S/Mime the issue I had with it was renewing certs and these
days Find a cert issuer - there's probably oportunities for TB to
partner with someone and get some €€€ throught a S/mime partnersip (eg
referal from tb - someone pays for a cert and Tb get's revenue from it).


Final note I'm very happy to get this email today - because the main
reason I use TB is that I can easily use pgp with it. Thanks Patrick
(and Hi ). Thanks kaie.


Ludo

--

https://www.hirlimann.net/Ludovic/carnet/

Patrick Cloke

unread,
Oct 8, 2019, 7:50:53 AM10/8/19
to tb-pl...@mozilla.org
Kai,

Awesome news! I think this is an important feature to bring to our users.

Will there be a migration path from users who are using Enigmail to
Thunderbird native PGP? I understand that not all options, etc. will
want to be supported, but having to not setup PGP again would be nice.

Looking forward to seeing this in Thunderbird!

--Patrick

Kai Engert

unread,
Oct 8, 2019, 7:51:46 AM10/8/19
to Ludovic Hirlimann, Thunderbird planning (moderated)
On 08.10.19 10:29, Ludovic Hirlimann wrote:
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?

Are you referring to https://github.com/ProtonMail/openpgpjs ?

That library is a potential candidate for a library that supports
OpenPGP message, its LGPL license could allow us to bundle it with
Thunderbird.

However, looking at the output of "npm-remote-ls openpgp", it has a
large set of dependencies.

In my understanding, if we decided to use OpenPGP.js we'd have to bundle
it together will all its dependencies. To keep those attack vectors
under control, we'd probably have to watch all those dependencies for
security issues, and publish an updated Thunderbird version for every
security incident related to any of those dependent libraries.

Also, bundling might not be acceptable for some downstream distributors,
like Debian, which distributes individual node packages. We'd have to
ensure our bundled OpenPGP.js works with the system module versions
available on downstream consumer system.

Because of the above, it seems preferable to use a C/C++ or Rust library
for OpenPGP message processing.


> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?

This article makes very critical statements about PGP in general, such
as not using PGP for encrypting email at all, which is obviously
contrary to our intention.

When you mention a new standard, can you please point out to which part
of the article you're reffering?

It's not yet clear if, or how, or how soon, we might support the Web Of
Trust.


> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).

It might be best to have a separate thread for discussing challenges
with S/MIME.

As a quick reply, I share the impression that the availability of
publicly trusted certificates for personal use with email security seems
to have decreased, especially when considering certificates available
for no cost. And Firefox has recently removed support for the HTML
keygen tag, which will make it more complicated to obtain such
certificates, as it will likely require the use of external command line
tools to create a key pair with the private key only being stored on the
user's own computer.

The use of S/MIME might be more appropriate for corporate or
organizational environments, while OpenPGP might be better suited for
communication between private users, because it doesn't require to
involve a third party CA to get started.

Kai

Kai Engert

unread,
Oct 8, 2019, 7:56:25 AM10/8/19
to Thunderbird planning (moderated), Patrick Cloke
On 08.10.19 13:50, Patrick Cloke wrote:
> Will there be a migration path from users who are using Enigmail to
> Thunderbird native PGP? I understand that not all options, etc. will
> want to be supported, but having to not setup PGP again would be nice.

Yes, at least for the keys the user already owns.

Kai

Patrick Cloke

unread,
Oct 8, 2019, 7:57:09 AM10/8/19
to Thunderbird planning (moderated)
On 10/8/19 7:56 AM, Kai Engert wrote:

> On 08.10.19 13:50, Patrick Cloke wrote:
>> Will there be a migration path from users who are using Enigmail to
>> Thunderbird native PGP? I understand that not all options, etc. will
>> want to be supported, but having to not setup PGP again would be nice.
> Yes, at least for the keys the user already owns.
>
> Kai

Glad to hear that! Thanks!

--Patrick

Ludovic Hirlimann

unread,
Oct 8, 2019, 7:59:59 AM10/8/19
to Kai Engert, Thunderbird planning (moderated)
On 10/8/19 1:51 PM, Kai Engert wrote:
Are we following
https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
gpg/pgp in thunderbird will follow the new standard and make the wot
more usable ?
This article makes very critical statements about PGP in general, such
as not using PGP for encrypting email at all, which is obviously
contrary to our intention.

When you mention a new standard, can you please point out to which part
of the article you're reffering?

And that's me forgetting that it was in an other article :

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f


Ludo

Ludovic Hirlimann

unread,
Oct 8, 2019, 8:02:35 AM10/8/19
to Kai Engert, Thunderbird planning (moderated)
On 10/8/19 1:51 PM, Kai Engert wrote:
> The use of S/MIME might be more appropriate for corporate or
> organizational environments, while OpenPGP might be better suited for
> communication between private users, because it doesn't require to
> involve a third party CA to get started.

Completely agree with that. But it's been a while since I've encountered
any S/mime message, or even an org managing a CA for that purpose the
last one I know of died in 2009.

I'm raising the issue , but I'm not proposing any soution, but is s/mime
support worth keeping ?



Ludo

Wiktor Kwapisiewicz

unread,
Oct 8, 2019, 8:11:41 AM10/8/19
to ka...@kuix.de, tb-pl...@mozilla.org
Hello,

> As a replacement, the Thunderbird team intends to develop integrated

> OpenPGP messaging for the next major version of Thunderbird, which will

> be released in summer 2020 (likely version 78).


That's great to hear! Given the number of people that use Thunderbird
daily providing built-in OpenPGP can tremendously lower the effort
needed to encrypt e-mails.

> Please have a look at the following article which describes the approach

> we'd like to take:

> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

The wiki page is very well written. If you don't mind I've got a few
minor comments:

> We intend to identify and use another existing library that provides support for creating and processing OpenPGP messages, and we will try to reuse parts of Enigmail that aren’t specific to GnuPG.

As far as I know there are two: OpenPGP.js, that is re-used by the
Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
provides a way to talk to GnuPG agent (for keys stored on smartcards).

[1]: https://addons.thunderbird.net/en-US/thunderbird/addon/autocrypt/

[2]: https://sequoia-pgp.org/

> It’s a controversial question whether email software should automatically use opportunistic encryption, or whether the user should be required to actively opt in, prior to using end-to-end email encryption.

The old OpenPGP e-mail header specified "preference" field [3].

[3]:
https://datatracker.ietf.org/doc/html/draft-josefsson-openpgp-mailnews-header-07#section-3.3

> Furthermore, starting to use OpenPGP comes with some responsibility for the future. Once a user distributes their own key to others, they’ve opened Pandora’s box. Others might discover the keys later and send encrypted email at any time in the future.

This can be (somehow) mitigated by using "Let's Encrypt approach". If we
assume a keyserver would be used then setting a short expiry on the user
key and then extending it every couple of months automatically (with no
user input) would provide a "dead man's switch" that'd render the key
unusable if the user stops using Thunderbird.

> For the initial version of Thunderbird with OpenPGP support, Thunderbird 78, we’ll not yet enable OpenPGP encryption for emails automatically. Instead, we’ll require that users opt in, prior to using it. However, it should be easy to opt in, and we might implement a smart user interface, that allows the user to discover the the availability of the OpenPGP messaging features, and offer interactive assistance that makes it easy to get started.

This could also be coupled with something like that "OpenPGP" header,
for example replying to a contact that indicated that they prefer
encrypted e-mail could trigger a bar similar to "forgotten attachment"
asking the user to generate OpenPGP keys.

Thanks for the work in this area!

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

Kai Engert

unread,
Oct 8, 2019, 8:49:31 AM10/8/19
to Ludovic Hirlimann, Thunderbird planning (moderated)
On 08.10.19 14:02, Ludovic Hirlimann wrote:
> but is s/mime support worth keeping ?

I wouldn't consider the barrier of entry to actively use it as a
sufficient reason to remove it.

Even if not using S/MIME actively, Thunderbird users can passively
benefit from S/MIME support, by being able to verify the digital
signature in emails. I frequently receive digitally signed S/MIME email
sent to me by banks, companies, insurances or the post office.

Also, I assume there are many corporate Thunderbird users who are still
happy that we support S/MIME.

Kai

Kai Engert

unread,
Oct 8, 2019, 8:56:15 AM10/8/19
to Ludovic Hirlimann, Thunderbird planning (moderated)
On 08.10.19 13:59, Ludovic Hirlimann wrote:
>>
>> When you mention a new standard, can you please point out to which part
>> of the article you're reffering?
>
> And that's me forgetting that it was in an other article :
> https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

That issue is mentioned in section "key sharing" of the wiki page:
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#Key_sharing

Kai Engert

unread,
Oct 8, 2019, 9:28:26 AM10/8/19
to Wiktor Kwapisiewicz, tb-pl...@mozilla.org
Hello Wiktor,

On 08.10.19 13:44, Wiktor Kwapisiewicz wrote:
>> We intend to identify and use another existing library that provides
>> support for creating and processing OpenPGP messages, and we will try
>> to reuse parts of Enigmail that aren’t specific to GnuPG.
>
> As far as I know there are two: OpenPGP.js, that is re-used by the
> Autocrypt extension [1] and Sequoia [2], that is native and AFAIK
> provides a way to talk to GnuPG agent (for keys stored on smartcards).

Thunderbird is distributed under the MPL 2.0 license.
The Sequoia PGP library code uses the GPL v3 license.

IANAL, but in my understanding it means that Thunderbird cannot bundle
the Sequoia library, and therefore it cannot be used.

Another potential option is the RNP [4] library, which depends on the
Botan [5] crypto library.

[4] https://www.rnpgp.com/software/rnp/
[5] https://botan.randombit.net/

Kai

neandr

unread,
Oct 8, 2019, 1:28:06 PM10/8/19
to Thunderbird planning (moderated)
No details about pEp. Do I miss a statement TB isn't going with pEp anymore?
AFAIK pEp is installed with Egnimail, so if Egnimail stops working with >68 which role will pEp play in the future for TB? 

-------- Ursprüngliche Nachricht --------
Von: Kai Engert <ka...@kuix.de>
Datum: 08.10.19 09:20 (GMT+01:00)
Betreff: Thunderbird 78, Enigmail and OpenPGP secure email

This message is related to today's announcement on the Thunderbird blog:
https://blog.mozilla.org/thunderbird/2019/10/thunderbird-enigmail-and-openpgp/

Two popular technologies exist that add support for end-to-end
encryption and digital signatures to email. Thunderbird has been
offering built-in support for S/MIME for many years, and will continue
to do so.

The Enigmail Add-on has made it possible to use Thunderbird with
external GnuPG software for OpenPGP messaging.

Because Thunderbird 78 will no longer support classic Add-ons, the
current Thunderbird 68.x branch (maintained until Fall 2020) will be the
last that can be used with Enigmail.

As a replacement, the Thunderbird team intends to develop integrated
OpenPGP messaging for the next major version of Thunderbird, which will
be released in summer 2020 (likely version 78).

We are happy that Patrick Brunschwig, who has been developing and
maintaining the Enigmail Add-on for many years, has offered to assist
the Thunderbird development team.

Many details need to be considered for this initiative.

Please have a look at the following article which describes the approach
we'd like to take:
  https://wiki.mozilla.org/Thunderbird:OpenPGP:2020

If you have feedback, please post it to this list.

This feature was originally requested in
  https://bugzilla.mozilla.org/show_bug.cgi?id=22687

Tanstaafl

unread,
Oct 8, 2019, 2:52:32 PM10/8/19
to Thunderbird planning (moderated), Ludovic Hirlimann, Kai Engert
My apologies, but I don't see the email this was replying to, or any
earlier in this thread...

My question is, is this the result of working with and integrating P=P,
which was discussed last year (and possibly early this year)?

Or is this entirely different?

If different, I would like to hear what happened,m because we were all
promised news on this work but nothing ever materialized, that I saw,
but maybe I missed it.

Thanks,

Charles

On Tue Oct 08 2019 04:29:32 GMT-0400 (Eastern Standard Time), Ludovic


Hirlimann <lud...@mozilla.com> wrote:
> On 10/8/19 9:20 AM, Kai Engert wrote:
>> Please have a look at the following article which describes the approach
>> we'd like to take:
>> https://wiki.mozilla.org/Thunderbird:OpenPGP:2020
>>
>> If you have feedback, please post it to this list.
>
>
> Are you considering leveraging Pronto mail's PGP library (like bugzilla
> did a year or so ago) ?
>
> (it doesn't support all encryption protocols, has issues with big keys
> (like mine was over 800kb with signatures).
>
>
> Are we following
> https://latacora.singles/2019/07/16/the-pgp-problem.html to make sure
> gpg/pgp in thunderbird will follow the new standard and make the wot
> more usable ?
>
>
> Regarding S/Mime the issue I had with it was renewing certs and these
> days Find a cert issuer - there's probably oportunities for TB to
> partner with someone and get some €€€ throught a S/mime partnersip (eg
> referal from tb - someone pays for a cert and Tb get's revenue from it).
>
>
> Final note I'm very happy to get this email today - because the main
> reason I use TB is that I can easily use pgp with it. Thanks Patrick
> (and Hi ). Thanks kaie.
>
>
> Ludo
>

_______________________________________________

Phillip Hallam-Baker

unread,
Oct 8, 2019, 2:53:11 PM10/8/19
to Thunderbird planning (moderated)
TLDR; If any of you here will be at the Singapore IETF, we need to talk.


S/MIME and OpenPGP both have userbases of roughly 3 million registered keys and probably about a million actual active users.

These userbases are distinct because the validation processes for one do not work for the other. OpenPGP is a better approach to authenticate Alice, S/MIME is the better way to authenticate Bob's Bank.

The reason almost nobody is using S/MIME on Thunderbird today is that obtaining and installing a certificate is utterly awful. It took me 15 minutes to complete and I have 25 years experience. Those who do are probably working in the federal government or its principal contractors.


I have been looking at ways to get the Internet to use end-to-end secure email and my conclusion was that it is a BetaMax vs VHS issue, both camps are completely locked in and neither is ever going to budge. So if we want to support end-to-end secure, the only long term strategy to achieve that is to do what ended the BetaMax/VHS battle and move to DVD.

If this is going to work, we really need to bring those legacy user communities along with us. So to move to something better we have to first fix S/MIME and OpenPGP. And that means fixing the way keys are registered and the way they are managed across devices.

I have a proposal to do exactly that. It is called the Mathematical Mesh and if my proposal was accepted, the IETF will be discussing forming a working group on it at the Singapore IETF this November.

The Mesh makes configuring the email client really easy whether the user has one device for email or ten. It allows the use of any trust model including the OpenPGP and S/MIMe models. It also supports configuration of any application with cryptography.  

I am currently finishing production of some videos that will introduce the Mesh. Naturally, the Mesh is open at every level as I explain in the second video. But it is not limited to end to end secure email and the question you might want to ask is whether this is a slippery slope you want to go down carefully or on skis.


Right now, the only way to have an end to end secure conversation is to find out if the other party uses keybase, Signal, Telegram, etc. log into the one they use and chat.

What if Thunderbird was also an end-to-end secure chat client and it wasn't limited to a single service provider?

What if the same end-to-end secure protocol that supported synchronous messaging also supported asynchronous (i.e. mail)?

The Mesh is not the only proposal that has been made in this space but it is the first that makes use of 'meta-cryptography' which is a bit of marketecture for some techniques invented in the 1990s that have not been used in commercial cryptography to date.


Magnus Melin

unread,
Oct 8, 2019, 5:45:59 PM10/8/19
to tb-pl...@mozilla.org

There has been no real developments on the Thunderbird - pEp front. The status of those discussions is still at the same stage they were some years ago: we're still awaiting an initial alpha prototype that can be evaluated, and after that further discussions would be had. (Re the prototype, we've been told, pEp in Enigmail is not it.)

The pEp mode of Enigmail will not be included in the Thunderbird OpenPGP integration. AFAIK pEp has abandoned using Enigmail as the delivery mechanism for their technology and are working some kind of alternative pEp integration for Thunderbird.

 -Magnus

Magnus Melin

unread,
Oct 8, 2019, 5:49:19 PM10/8/19
to tb-pl...@mozilla.org
This is a different initiative.

See my other tb-planning post from a few minutes ago for current status
of Thunderbird and pEp.

 -Magnus

Ludovic Hirlimann

unread,
Oct 9, 2019, 3:19:17 AM10/9/19
to Phillip Hallam-Baker, Thunderbird planning (moderated)
On 10/8/19 8:28 PM, Phillip Hallam-Baker wrote:
TLDR; If any of you here will be at the Singapore IETF, we need to talk.


I know mozillamessaging never did. and this raises another question : Is Thunderbird represented in any internet standard orgs ?


Ludo

Kai Engert

unread,
Oct 9, 2019, 11:13:49 AM10/9/19
to Thunderbird planning (moderated), Phillip Hallam-Baker
Hello Phillip,

interesting ideas, but we might not be able to spend much with new
research ideas at this time. The Thunderbird release timing is rather
fixed, we'll need to ship a polished and production quality Beta release
by May next year. I'm afraid the limited development resources that we
have available in the security feature area might be fully consumed by
the migration from Enigmail to internal OpenPGP support.

On 08.10.19 20:28, Phillip Hallam-Baker wrote:
> What if Thunderbird was also an end-to-end secure chat client and it
> wasn't limited to a single service provider?

FYI, it already is. We support XMPP/Jabber and some others, and we're
also close to shipping OTR, but we aren't yet ready to announce it.
Hopefully in a few weeks we'll do a call for testing.

Kai Engert

unread,
Oct 9, 2019, 12:55:51 PM10/9/19
to Thunderbird planning (moderated), Ludovic Hirlimann, Phillip Hallam-Baker
Physically participating at IETF meetings is time and resource
intensive. Paying for flight, hotel, the expensive IETF meeting fee, and
probably not being able to get other work done for about a week, three
times a year, seems like a significant investment to me. If one
implements technology, but doesn't actively define new standards, how
can such participation be justified?

Ben Bucksch

unread,
Oct 9, 2019, 1:08:57 PM10/9/19
to tb-pl...@mozilla.org

This is fantastic! Thanks for getting PGP included, and for getting Patrick Brunschwig on board. He’s a great guy and very competent developer. I would like to thank Patrick for his awesome work over all the years!

Security-wise, I am also happy to read the following: “To promote secure communication, Thunderbird 78 will encourage the user to perform ownership confirmation of keys used by correspondents, [and] notify the user if the correspondent’s keys change unexpectedly”

These 2 things are crucial for secure communication. If the key is not validated, somebody could be sitting in the middle. Even more important is the key change notification. Without that, somebody could get into the middle, read all messages, and the user would not notice.

This is missing in most “secure messaging” applications with so-called “crypto”, and without this key change notification, there is no trusted communication possible. Thank you that you took attention to such details.

Ben Bucksch

unread,
Oct 9, 2019, 1:20:20 PM10/9/19
to tb-pl...@mozilla.org
https://wiki.mozilla.org/Thunderbird:OpenPGP:2020#No_opportunistic_encryption

Thank you for your wise position on this. I'm glad to see that we have
crypto competence on board, with you and Patrick Brunschwig.

I completely agree with what you wrote there. It is the right choice,
given the current circumstances.


Here is a potential problem:

> For users who prefer to avoid unencrypted email completely, we might
> offer an advanced configuration, that could require all outgoing email
> to be encrypted, either using any available key, or by requiring the
> use of confirmed keys, only.


I am concerned by such an option. If some advanced or security-conscious
Thunderbird users would enable this, find keys for me, and I would not
be able to read my own mail.

You mention exactly my reason later:

> Once a user distributes their own key to others, they’ve opened
> Pandora’s box. Others might discover the keys later and send encrypted

> email at any time in the future. If the key has been lost, either
> because the computer broke and no backups of they are available, or
> because the user forgot the passphrase that was used to protect the
> key, the incoming encrypted email cannot be read. Also, if the key has
> been lost, the archive of encrypted email that’s still available on
> your mail server can no longer be read either.

I am in that position. I have multiple keys on key servers, because I
sign software. However, I read mail on multiple email clients. Mostly
Thunderbird, but also on Android (where TB doesn't exist). I do not wish
to put the valuable PGP keys that I use to sign software on my cell
phone just to read mail.

There's even a worse situation: An attacker might create a PGP key for
the victim (a normal unsuspecting user that never used Thunderbird nor
GPG), put it on a key server, and Thunderbird users would fetch the key,
encrypt mail to the victim, and the victim would not be able to read her
own mail anymore. So, such opportunistic encryption creates new attack
scenarios, comparable to a DoS (Denial of service) attack, but it would
be in the design and permanent. At least for such senders that enable
such a Thunderbird feature. That's why such a feature is problematic.

Ben Bucksch

unread,
Oct 9, 2019, 1:22:09 PM10/9/19
to tb-pl...@mozilla.org
On 08.10.19 14:02, Ludovic Hirlimann wrote:
> is s/mime support worth keeping ?

I also think that S/MIME is inherently broken, but multiple large
organizations, esp. governments, are actively using it, in Thunderbird.

Wiktor Kwapisiewicz

unread,
Oct 9, 2019, 2:37:32 PM10/9/19
to Kai Engert, Thunderbird planning (moderated)
Hi Kai,

On 09.10.2019 17:13, Kai Engert wrote:
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.

Is there a rationale somewhere why OTR was selected? (for example
multiprotocol support?)

As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.

Source:
https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29

(see also comments about OMEMO on that page).

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

John Bieling

unread,
Oct 9, 2019, 2:37:47 PM10/9/19
to tb-pl...@mozilla.org
There is an approach to put the S/MIME cert into a DNS record secured by
DNSSEC which I think solves the trust issue. There is/was even an addon

https://addons.thunderbird.net/addon/great-dane-smime/

I use S/MIME and I would be sad if it got removed from Thunderbird.

Why do we always have that discussion to remove stuff from thunderbird?

S/MIME is a standard, isn't it?


John

> On 08.10.19 14:02, Ludovic Hirlimann wrote:
>> is s/mime support worth keeping ?
>

Patrick Cloke

unread,
Oct 9, 2019, 3:58:24 PM10/9/19
to tb-pl...@mozilla.org
On 10/9/19 2:10 PM, Wiktor Kwapisiewicz wrote:

> Hi Kai,
>
> On 09.10.2019 17:13, Kai Engert wrote:
>> FYI, it already is. We support XMPP/Jabber and some others, and we're
>> also close to shipping OTR, but we aren't yet ready to announce it.
>> Hopefully in a few weeks we'll do a call for testing.
>
> Is there a rationale somewhere why OTR was selected? (for example
> multiprotocol support?)
>
> As far as I know OTR has been largely replaced by OMEMO in XMPP/Jabber.
>
> Source:
> https://wiki.xmpp.org/web/XMPP_E2E_Security#OTR_.28Off-the-record_Messaging.29
>
>
> (see also comments about OMEMO on that page).
>
Hey Wiktor,

OTR is cross protocol, which fits nicely into what Thunderbird supports.

It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP (i.e. how many users exist that support different
end-to-end encryption technologies). The major downside, in my
understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.

There's a bug [1] about implementing OMEMO for anyone who is interested!

--Patrick

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1237416

ba

unread,
Oct 10, 2019, 5:22:16 AM10/10/19
to Thunderbird planning (moderated)
On Oct 8, 2019, at 7:13 PM, neandr <nea...@gmx.de> wrote:

No details about pEp. Do I miss a statement TB isn't going with pEp anymore?
AFAIK pEp is installed with Egnimail, so if Egnimail stops working with >68 which role will pEp play in the future for TB? 


Thanks for the question. pEp is one option in Enigmail as you rightly say. pEp will ensure that no pEp users will be stranded, and pEp will have a solution for them in the near term that will offer the full pEp convenience and functionality. We, with a dedicated team, have actually started working on a pEp solution as soon as we heard that Enigmail was no longer planning a version for TB78. 

pEp has offered integration to TB and even TB branded mobile apps, but that discussion did not proceed further as TB wants to see a finished product first. 
It is built on the same basis of pEp functionality as the Enigmail/pEp plug-in, but with a different UI as the manual steps of Enigmail PGP are no longer needed. It will also be a lot faster and will allow automatic key sync across multiple personal devices. 

Regards,

Berna Alp, p≡p Foundation
https://pep.foundation




Phillip Hallam-Baker

unread,
Oct 10, 2019, 5:59:16 AM10/10/19
to Kai Engert, Thunderbird planning (moderated)
What would help me enormously is if there was a documented API that allows the Mesh tool to configure Thunderbird from the command line. Then I can write a (short) shell script that pulls the mail config out of the Mesh (its a JSON document containing the inbound, outbound service config, the private keys and the certificates).



Will

unread,
Oct 10, 2019, 6:06:05 AM10/10/19
to tb-pl...@mozilla.org
On 09/10/19 17:13, Kai Engert wrote:
> On 08.10.19 20:28, Phillip Hallam-Baker wrote:
>> What if Thunderbird was also an end-to-end secure chat client and it
>> wasn't limited to a single service provider?
> FYI, it already is. We support XMPP/Jabber and some others, and we're
> also close to shipping OTR, but we aren't yet ready to announce it.
> Hopefully in a few weeks we'll do a call for testing.

With the issues we have experienced around a half baked new API and all
the other issues related to add ons, we'd like to know why TB is
spending presumably a lot of resources on chat client encryption?

TB is an email client right?

Why don't you concentrate on getting that bit right first?

There are mountains of unfixed bugs, APIs that are a mess, add ons that
we can't get to work and could do with help, and you are messing around
with chats and OTR?

Exactly what is the direction of travel for TB? Replace email with chat?
You are so late to that party.................

We don't need it - we already have a good chat system, with OTR if we
want it, and a pile of other functionality. Quite simply there are
already much better systems out there.

Chat in TB is just a waste of CPU and coding cycles IMHO. Beyond a
cursory look we have never used it. I'd rather see it dumped completely.

Obviously this has all been discussed behind closed doors? Why isn't the
community consulted about this sort of thing, or is it paying clients only?

<shakeshead>

Phillip Hallam-Baker

unread,
Oct 10, 2019, 4:03:59 PM10/10/19
to Thunderbird planning (moderated)
The focus of any open source project is invariably what people are prepared to work on.

Magnus Melin

unread,
Oct 10, 2019, 6:32:24 PM10/10/19
to tb-pl...@mozilla.org
On 10-10-2019 13:04, Will wrote:
> we'd like to know why TB is
> spending presumably a lot of resources on chat client encryption?

Thunderbird is committed to ensuring free and private communications.
Not only for chat but email too, which the OpenPGP announcement would
have you know. I think in the larger view of things, ensuring
distributed end-to-end encryption systems for communication are easily
obtainable is very important for freedom of speech and other fundamental
rights.

 -Magnus

Óvári

unread,
Oct 11, 2019, 6:24:57 AM10/11/19
to Thunderbird planning (moderated), Magnus Melin, ja...@gnu.org, Jami, Ryan Sipes
Hi,

Please integrate Jami into Thunderbird.

https://jami.net

Jami works on all platforms that Thunderbird works on. Jami also works on other platforms where Thunderbird doesn't like iPhone and Android.

Jami would also enable a SIP client to be available from within Thunderbird so Address Book contacts could be called.

What do you think?

Thank you

Óvári

Will

unread,
Oct 11, 2019, 6:24:59 AM10/11/19
to tb-pl...@mozilla.org
On 10/10/19 15:10, Phillip Hallam-Baker wrote:
The focus of any open source project is invariably what people are prepared to work on.

Ahh. So we need a CV to comment?

With any OS project we are involved in (several), if we can't code, we help in support, or documentation, and if nothing else pay.

We are talking about core TB code here. The very base that everyone needs. The bit I guess most TB devs should probably be most focussed on because like - that is the core product??

It isn't our fault if the developers we have asked to help us have told us they don't want to because the code is missing features they require or it is so spaghetti like they don't want to waste their time and ours, or they can't see the point as it will all have to be rewritten again in 5 minutes.

Hey ho, Seems there are plenty of others who feel the same way.

I'll leave them to continue the fight as we will undoubtedly get banned for being out of order or somesuch.

Patrick Cloke

unread,
Oct 11, 2019, 8:12:13 AM10/11/19
to Thunderbird planning (moderated)

Wiktor,

On 10/11/19 7:23 AM, Wiktor Kwapisiewicz wrote:

On 09.10.2019 21:58, Patrick Cloke wrote:
It is unfortunately hard to get a clear picture of what is worth
implementing for XMPP

XSF publishes Compliance Suites every year that group features that they consider "worth implementing". See for example:
https://xmpp.org/extensions/xep-0412.html

There are also tests run by companies that invest in XMPP heavily:
https://compliance.conversations.im/tests/
I hadn't seen this exact compliance test site before. Thanks! I think it is only half the picture though. If a server implements an XEP, but no clients do, then it is not necessarily worth implementing. (There's also the aspect of trying to understand what clients are popular, I haven't looked into this for XMPP in a very long time though.)
(i.e. how many users exist that support different end-to-end encryption technologies).

That's not the impression I got from XSF mailing lists. There are three groups of E2E technologies within XMPP: legacy (OTR and old OpenPGP), recommended (OMEMO and new OMEMO) and there is also MLS that some XSF council members believe will replace OMEMO long-term but the spec is not ready.

Currently OMEMO is widely implemented, see: https://omemo.top/
I should probably join the XSF mailing list... the thing missing from that site is some understanding of how popular each of those clients are. (What percentage of the user population supports it, not what percentage of clients do.) Anyway, I'm not against supporting OMEMO, but supporting OTR was a good baseline since it helps all the protocols implemented in Thunderbird, and a bunch of the work had already been done a few years ago. Kai and Alex finished integrating it.
OTR, as the wiki page indicates, is used in either legacy clients where multiprotocol support is necessary. (There is also OTRv4 in development supported by one client that showcases it: https://coy.im ).
I've seen the OTRv4 stuff, a bit, but haven't been plugged into whether clients really plan to implement it or not. My understanding is that it is very incompatible with OTRv3, which is unfortunate from a technical standpoint.
The major downside, in my understanding, is that OTR does not support multi-user chats. I'm sure
there are some others, but OTR seemed like a good place to start.

There's a bug [1] about implementing OMEMO for anyone who is interested!

Thanks for the reference!

No problem. I think it'd be good to have multiple options here. Hopefully the other users you're talking to have at least one that overlaps! I'm unsure how hard it would be to incorporate OMEMO, but I'd be willing to help guide someone who is interested.

Last thing I'll say is that if there are specific XMPP features that are missing from Thunderbird please start by filing a bug (probably a bug per XEP / feature). Unfortunately most of my use of XMPP is via GTalk [1] which has a pretty terrible feature set.

--Patrick

[1] Yes, it still works.

Tanstaafl

unread,
Oct 11, 2019, 7:47:46 PM10/11/19
to tb-pl...@mozilla.org
On 10/10/2019, 6:32:13 PM, Magnus Melin <mkmelin...@iki.fi> wrote:
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other fundamental
> rights.

That sounds all well and good, but TB is, first and foremost, an EMail
client, not a Chat client, and that should take a -very high- priority.

Once the email code is rewritten and all major/known bugs squashed, then
and only then should PAID resources (volunteers are of course always
welcome to work on whatever they want) be focused on chat and other
extraneous features.

If PAID resources are being used for Chat and other non-email type work,
then I question the validity of such decisions.

Will

unread,
Oct 11, 2019, 7:47:53 PM10/11/19
to tb-pl...@mozilla.org
On 11/10/19 00:32, Magnus Melin wrote:
> On 10-10-2019 13:04, Will wrote:
>> we'd like to know why TB is
>> spending presumably a lot of resources on chat client encryption?
>
> Thunderbird is committed to ensuring free and private communications.
> Not only for chat but email too, which the OpenPGP announcement would
> have you know. I think in the larger view of things, ensuring
> distributed end-to-end encryption systems for communication are easily
> obtainable is very important for freedom of speech and other
> fundamental rights.
>

We have whole heartedly supported moves to more secure comms for a long
time, and fully support the reasons for it.

We're not sure what relevance OpenPGP has to chat systems - that is just
conflating things. We understand the moves with OpenPGP for email.

However, there is a suggestion you are adding OTR to Thunderbird which
suggests you are trying to make it more a chat client and we just can't
see the logic behind that, especially when there are so many issues in
the basic email and calendar client itself.

Trying to compete in an already crowded *chat* market where you are up
against some seriously big players seems odd. We don't need TB for that
- there are much better solutions out there that fulfil your aspirations.

Why not just have hooks to use other systems, be that Signal or
whatever? Let the add on devs decide what they want to plug in.

TB are probably concerned that ultimately (in the long term) chat is
going to make email, and therefore TB, redundant. That really needs an
open conversation in itself.

Wiktor Kwapisiewicz

unread,
Oct 11, 2019, 7:48:14 PM10/11/19
to Patrick Cloke, Thunderbird planning (moderated)
Hi Patrick,

On 09.10.2019 21:58, Patrick Cloke wrote:
> It is unfortunately hard to get a clear picture of what is worth
> implementing for XMPP

XSF publishes Compliance Suites every year that group features that they
consider "worth implementing". See for example:
https://xmpp.org/extensions/xep-0412.html

There are also tests run by companies that invest in XMPP heavily:
https://compliance.conversations.im/tests/

> (i.e. how many users exist that support different
> end-to-end encryption technologies).

That's not the impression I got from XSF mailing lists. There are three
groups of E2E technologies within XMPP: legacy (OTR and old OpenPGP),
recommended (OMEMO and new OMEMO) and there is also MLS that some XSF
council members believe will replace OMEMO long-term but the spec is not
ready.

Currently OMEMO is widely implemented, see: https://omemo.top/

OTR, as the wiki page indicates, is used in either legacy clients where
multiprotocol support is necessary. (There is also OTRv4 in development
supported by one client that showcases it: https://coy.im ).

> The major downside, in my
> understanding, is that OTR does not support multi-user chats. I'm sure
> there are some others, but OTR seemed like a good place to start.
>
> There's a bug [1] about implementing OMEMO for anyone who is interested!

Thanks for the reference!

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

Magnus Melin

unread,
Oct 12, 2019, 3:11:33 PM10/12/19
to tb-pl...@mozilla.org
On 11-10-2019 15:17, Will wrote:
> However, there is a suggestion you are adding OTR to Thunderbird which
> suggests you are trying to make it more a chat client and we just can't
> see the logic behind that,

Thunderbird already has chat, and many other features not directly
"mail" too. Adding OTR support is just picking a fairly low hanging
fruit that Thunderbird can use to differentiate itself to others with.

We've also learnt that for organizational usage, the chat component is
important.

> TB are probably concerned that ultimately (in the long term) chat is
> going to make email, and therefore TB, redundant.

I don't see any concern there. Mail and chat are used for totally
different things.

 -Magnus

Ryan Sipes

unread,
Oct 14, 2019, 5:29:19 AM10/14/19
to tb-pl...@mozilla.org

Hey Tanstaafl,

The percentage of time and resources spent on chat probably matches up with the userbase that we have for chat. We have many large enterprises and a few governments using XMPP right now with Thunderbird.

If they represent 1% of our userbase, that probably tracks with the time spent on this feature - if even, I'd say the time spent is actually a fraction of a fraction of a percent of donations. And those enterprises and governments, as far as I can tell, are a good source of donations.

Also, the entire Thunderbird team uses chat in order to stay in touch and collaborate. Improving chat means helping the core team communicate more effectively, and if we can secure our chat with each other that's even better.

This comes across as "I don't use that feature, therefore it is a waste." - which I think is a flawed way to think about what to work on. I've had a couple of enterprises reach out to share they've made reasonably sizable, often recurring donations, and share what they use. Are their donations not worth anything?

Ryan Sipes
Community and Business Development Manager
Thunderbird

Wiktor Kwapisiewicz

unread,
Oct 14, 2019, 8:13:00 AM10/14/19
to Patrick Cloke, Thunderbird planning (moderated)
Hi Patrick,

On 11.10.2019 14:12, Patrick Cloke wrote:
> I hadn't seen this exact compliance test site before. Thanks! I think it
> is only half the picture though. If a server implements an XEP, but no
> clients do, then it is not necessarily worth implementing. (There's also
> the aspect of trying to understand what clients are popular, I haven't
> looked into this for XMPP in a very long time though.)

Agreed. Additionally XMPP has a lot of unmaintained clients that are
still in use so it's not really possible to cover all cases. On the
other hand there is a high convergence of XEPs supported if one
considers modern clients (such as https://conversations.im/ or
https://dino.im/ ).

> I should probably join the XSF mailing list... the thing missing from
> that site is some understanding of how popular each of those clients
> are. (What percentage of the user population supports it, not what
> percentage of clients do.)

I'm not sure if it's possible to get "percentage of user population" in
a federated protocol such as XMPP.

> Anyway, I'm not against supporting OMEMO, but
> supporting OTR was a good baseline since it helps all the protocols
> implemented in Thunderbird, and a bunch of the work had already been
> done a few years ago. Kai and Alex finished integrating it.

Sure, there is no harm doing that I guess and if it works with all
protocols that's a big plus. I just wanted to mention OMEMO as observing
a small circle of federated protocols is my hobby :)

> Last thing I'll say is that if there are specific XMPP features that are
> missing from Thunderbird please start by filing a bug
> <https://bugzilla.mozilla.org/enter_bug.cgi?product=Chat+Core&component=XMPP>
> (probably a bug per XEP / feature). Unfortunately most of my use of XMPP
> is via GTalk [1] which has a pretty terrible feature set.

Oh yes. I know XMPP from early ages and also used GTalk heavily when it
was popular but the protocols and feature sets varied so drastically
that it seems like two different protocols.

If you have time and would like to see XMPP I'd suggest installing
https://conversations.im and trying it out. It does have end-to-end
encryption enabled by default and looks and feels like any kind of
modern chat application.

Wiktor Kwapisiewicz

unread,
Oct 14, 2019, 9:28:51 AM10/14/19
to Kai Engert, tb-pl...@mozilla.org
Hi Kai,

I noticed the following change on the Wiki:

> Will OpenPGP cards be supported for private key storage ?

>

> Probably not, because we don't use the GnuPG software that's usually required to access OpenPGP smartcards.


I think it's worth mentioning that there is a way to access smartcards
through GnuPG's JSON interface (native messaging). That's what
Mailvelope uses and it's just a browser extension.

Some details are available here:
https://github.com/mailvelope/mailvelope/wiki/Mailvelope-GnuPG-integration

Of course I wouldn't consider this a top priority (Mailvelope added
support for that just recently) but certainly interesting for some
people that prefer not to store their private keys in software.

Tanstaafl

unread,
Oct 15, 2019, 7:47:16 AM10/15/19
to tb-pl...@mozilla.org
Hi Ryan,

Actually, your explanation completely resolves any concern I may have
had - and I certainly didn't mean to come across as saying "I don't use
that feature, therefore it is a waste."

My comment was concerned with the fact that TB is, again, first and
foremost, an EMail client, not a Chat client. I don't think anyone would
disagree with that.

But if these details had been included in the OP, I wouldn't have said a
thing, because I have no problem at all with what you described.

Anyway, thanks for taking the time to respond and clear that up, and
again, thanks for your and everyone's hard work keeping TB the best
EMail client available.

Charles

On 10/14/2019, 5:29:10 AM, Ryan Sipes <ry...@thunderbird.net> wrote:
> Hey Tanstaafl,
>
> The percentage of time and resources spent on chat probably matches up
> with the userbase that we have for chat. We have many large enterprises
> and a few governments using XMPP right now with Thunderbird.
>
> If they represent 1% of our userbase, that probably tracks with the time
> spent on this feature - if even, I'd say the time spent is actually a
> fraction of a fraction of a percent of donations. And those enterprises
> and governments, as far as I can tell, are a good source of donations.
>
> Also, the entire Thunderbird team uses chat in order to stay in touch
> and collaborate. Improving chat means helping the core team communicate
> more effectively, and if we can secure our chat with each other that's
> even better.
>
> This comes across as "I don't use that feature, therefore it is a
> waste." - which I think is a flawed way to think about what to work on.
> I've had a couple of enterprises reach out to share they've made
> reasonably sizable, often recurring donations, and share what they use.
> Are their donations not worth anything?
>
> Ryan Sipes
> Community and Business Development Manager
> Thunderbird <https://thunderbird.net>

Will

unread,
Oct 15, 2019, 7:47:20 AM10/15/19
to tb-pl...@mozilla.org
On 14/10/19 11:29, Ryan Sipes wrote:
>
> This comes across as "I don't use that feature, therefore it is a
> waste." - which I think is a flawed way to think about what to work
> on. I've had a couple of enterprises reach out to share they've made
> reasonably sizable, often recurring donations, and share what they
> use. Are their donations not worth anything?
>

We're more like

"We don't use that feature because there are much better, more secure
products out there that are kicking email into touch, and if the time
spent on messing around with chat had been spent on email and trying to
make PGP easier then maybe we wouldn't be faced with the extinction of
email because chat is just so much easier"

If you really want to do chat just build yourself a working API that
integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
stuff.  Why bother with OTR when you can integrate their stuff which
already has end to end encryption?

Email is stuck in its ways. We hate the word 'disruption' but email is
going the same way as fax. Can't change it. Engineer around it.

Millennials and Generation Z barely look at email beyond using an
account to setup their phones. They are the future.

A few advantages of chat off the top of the head.

Instant comms
Read receipts, and you don't even need Exchange
Any type of attachment (admin permitting) and easy handling
End to end security via SSL, and many have end to end encryption built
in too
Easy voice messaging
Bots.....
Most are accessible via web clients so are platform independent, and
just as easily accessible via mobile with either a browser or app.
Integrated messaging into things like CRMs - just message your clients
direct from your CRM to their whatsapp or FB messenger (yuck)  or
whatever etc AND vice versa
Integrated into web sites - customers can contact you direct off you
site and send attachments etc. Saves a lot of issues with emails.
Federates systems where different systems can talk to one another

Like it or not, that is the direction of travel. YMMV.

Where TB sits in the middle of that we really don't know. But the recent
misery that TB upgrades has caused us has just made us look a whole lot
harder at how we get rid of email entirely.

We expect we can continue with TB at the current version for a couple of
years by which time we think chat will be almost ubiquitous and email
will barely be required.

Onwards and upwards.

Magnus Melin

unread,
Oct 15, 2019, 8:12:02 AM10/15/19
to tb-pl...@mozilla.org
On 14-10-2019 23:02, Will wrote:
> If you really want to do chat just build yourself a working API that
> integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
> stuff.  Why bother with OTR when you can integrate their stuff which
> already has end to end encryption?

None of those are open systems. AND, regarding end to end encryption,
for the ones that even claim to support it we can only take their word
that there aren't back doors. In reality, with a centralized system
you're not safe against a powerful attacker.

Thunderbird wants to enable *distributed*, open, end-to-end encrypted
communications. There are not too many common solutions for that.

> Email is stuck in its ways. We hate the word 'disruption' but email is
> going the same way as fax. Can't change it. Engineer around it.
>
> Millennials and Generation Z barely look at email beyond using an
> account to setup their phones. They are the future.

Email usage is just going up:
https://99firms.com/blog/how-many-email-users-are-there/

Regardless of that, for any business use case, I'm sure your contacts
will be pleased to have you message them work conversations (other than
casual) through social networks. [irony, if you didn't catch that already]

 -Magnus

Patrick Cloke

unread,
Oct 15, 2019, 11:00:44 AM10/15/19
to Wiktor Kwapisiewicz, Thunderbird planning (moderated)
Hi Wiktor,

On 10/14/19 5:07 AM, Wiktor Kwapisiewicz wrote:
> Hi Patrick,
>
> On 11.10.2019 14:12, Patrick Cloke wrote:
>> I hadn't seen this exact compliance test site before. Thanks! I think
>> it is only half the picture though. If a server implements an XEP,
>> but no clients do, then it is not necessarily worth implementing.
>> (There's also the aspect of trying to understand what clients are
>> popular, I haven't looked into this for XMPP in a very long time
>> though.)
> Agreed. Additionally XMPP has a lot of unmaintained clients that are
> still in use so it's not really possible to cover all cases. On the
> other hand there is a high convergence of XEPs supported if one
> considers modern clients (such as https://conversations.im/ or
> https://dino.im/ ).
Definitely true! Thanks for a couple suggestions of more modern clients.
>> I should probably join the XSF mailing list... the thing missing from
>> that site is some understanding of how popular each of those clients
>> are. (What percentage of the user population supports it, not what
>> percentage of clients do.)
> I'm not sure if it's possible to get "percentage of user population"
> in a federated protocol such as XMPP.
This can be tough, yeah, but I've definitely seen numbers for e-mail
before and done a little research on this for IRC. Anyway, your point is
valid. My counterargument really comes down to: with limited resources
you need to be selective in what is implemented.
>> Anyway, I'm not against supporting OMEMO, but supporting OTR was a
>> good baseline since it helps all the protocols implemented in
>> Thunderbird, and a bunch of the work had already been done a few
>> years ago. Kai and Alex finished integrating it.
> Sure, there is no harm doing that I guess and if it works with all
> protocols that's a big plus. I just wanted to mention OMEMO as
> observing a small circle of federated protocols is my hobby :)

Thanks for bringing it up! I'd be interested in any other observations
you might have.

--Patrick

Mihovil Stanić

unread,
Oct 16, 2019, 8:08:41 AM10/16/19
to tb-pl...@mozilla.org

15.10.2019 u 14:11, Magnus Melin je napisao/la:
> On 14-10-2019 23:02, Will wrote:
>> If you really want to do chat just build yourself a working API that
>> integrates Signal, Whatsapp (yuck) Facebook messenger & all that other
>> stuff.  Why bother with OTR when you can integrate their stuff which
>> already has end to end encryption?
>
> None of those are open systems. AND, regarding end to end encryption,
> for the ones that even claim to support it we can only take their word
> that there aren't back doors. In reality, with a centralized system
> you're not safe against a powerful attacker.
>
> Thunderbird wants to enable *distributed*, open, end-to-end encrypted
> communications. There are not too many common solutions for that.
>

Actually, Signal is open. And if it's true, Whatsapp is build based on
Signal technology, but since no one can verify it...

Wiktor Kwapisiewicz

unread,
Oct 16, 2019, 8:22:01 AM10/16/19
to Mihovil Stanić, Thunderbird planning (moderated)
Hi Mihovil,

On 16.10.2019 07:45, Mihovil Stanić wrote:
>>
>> Thunderbird wants to enable *distributed*, open, end-to-end encrypted
>> communications. There are not too many common solutions for that.
>>
> Actually, Signal is open. And if it's true, Whatsapp is build based on
> Signal technology, but since no one can verify it...

Signal is open-source but is not distributed. Additionally Moxie is
against other clients connecting to their servers (see [0]). For me
Signal is not really an "open communications" platform but I guess this
is subjective.


[0]:
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165

For the record parts of Signal (libsignal) are re-used in other systems
such as XMPP's OMEMO.

Kind regards,
Wiktor

--
https://metacode.biz/@wiktor

Will

unread,
Oct 20, 2019, 12:15:04 PM10/20/19
to tb-pl...@mozilla.org
On 15/10/19 14:11, Magnus Melin wrote:
>
>> Email is stuck in its ways. We hate the word 'disruption' but email is
>> going the same way as fax. Can't change it. Engineer around it.
>>
>> Millennials and Generation Z barely look at email beyond using an
>> account to setup their phones. They are the future.
>
> Email usage is just going up:
> https://99firms.com/blog/how-many-email-users-are-there/
>

Ahh, lies, damn lies, and statistics?

We said they use an email address to "register" their devices, and then
don't use it again... 'users' and 'usage' are two different things.

Equally, where are the comparative stats between email usage and chat/IM
usage??? You might have seen a meteoric rise in IM over the last 10
years. Email has not had that. Well, apart from the amount of junk sent.

There are any number of reports online showing you the rise in IM. That
is at the expense of email.

From our own systems something like 70% of all mail that hits our server
is junk - and some days it is much higher than that. People are sick of it.

Junk on most IM platforms currently is minimal, and non existent on
internal systems.

But you know all this and that is why you have tried to integrate chat
into TB, contradicting yourself and your stats quoted above.

It really is a shame that there has not been a wider and more open
discussion about it.

https://matrix.org/faq  ??


> Regardless of that, for any business use case, I'm sure your contacts
> will be pleased to have you message them work conversations (other
> than casual) through social networks. [irony, if you didn't catch that
> already]
>

Actually you are making assumptions here, and you know the adage about
that don't you?

This is client driven. They are the people that pay the bills. If they
want, then we have to provide. Whether we like it, or not (personally I
hate it and avoid it in private, but... clients)

More and more of the big companies like M$ etc try to block it unless it
originates from another equally big provider. So you are forced more and
more to use email systems (M$, Gmail et al) that are not under your
control and where mail can be read my the providers (or at least meta
data) for advertising purposes. And you are worrying about IM?

Yup. Where we can we push them to use better more secure systems, and we
are pretty careful about what we do, and how we do it. GDPR and all that.

But, they are the clients and we have bills to pay. You cut your cloth
accordingly.


==============

"Oh, that was easy," says Man, and for an encore goes on to prove that
black is white and gets himself killed on the next zebra crossing.”

:-)

Phillip Hallam-Baker

unread,
Oct 20, 2019, 5:36:33 PM10/20/19
to Thunderbird planning (moderated)
Comparing chat to email is probably missing the real trends.

Email usage hit 100% of Internet users in 1980 and has stayed there. There is therefore no growth possible.

The growth in the use of messaging is almost certainly at the expense of SMS and telephone both of which are in decline.
Reply all
Reply to author
Forward
0 new messages